OIDC によるクライアント認証の保護

Kubernetes Operator は、認証メカニズムとして OpenID Connect（OIDC）をサポートしています。OIDC認証を構成すると、クライアントアプリケーションはJSON web token（JSON web token）をMongoDBリソースに提示します。 MongoDB は、構成された OIDC IdP（IdP）に対してJSON web token を検証し、トークン内のクレームを使用してユーザーの ID と、オプションでロールマッピング用のグループメンバーシップを決定します。

このガイドでは、 Kubernetes Operator を使用してMongoDB配置に接続するクライアントアプリケーションに対して OIDC認証を構成する方法について説明します。

注意

Kubernetesクラスターで OIDC を使用してMongoDBのスタンドアロンインスタンスを保護することはできません。

Considerations

OIDC認証を有効にする場合は、次の点を考慮してください。

ID プロバイダー: 既存の構成された OIDC IdP（IdP）が必要です。Kubernetes Operator は IdP 自体を管理しません。
認証: Kubernetes Operator は、OIDC 経由で認証（ID の検証）を構成します。認可（権限の付与）は、 MongoDBカスタムリソース内のMongoDBロールに OIDC クレームをマッピングすることで処理されます。
フェデレーション: MongoDB はWorkload Identity Federation（マシン間認証用）と Workforce IdP（人間ユーザー認証用）の両方をサポートします。
TLS 暗号化: セキュリティを強化するために、 TLS 暗号化レプリカセットまたは TLS 暗号化シャーシャーディングされたクラスターを配置することを強くお勧めします。IdPとの OIDC 通信は HTTPS によって保護されていますが、 MongoDBリソースで TLS を有効にすると、クライアントアプリケーションとデータベース間の接続が暗号化されます。これにより、OIDC トークンやその他すべてのデータベーストラフィックがネットワークの攻撃から保護されます。

一般的な前提条件

MongoDB配置の OIDC認証を構成する前に、次のタスクを完了してください。

MongoDB Enterpriseデータベースリソースを必ず配置します。MongoDB Community データベースは OIDC認証をサポートしていません。
レプリカセットを配置するか、OpenID Connect で保護するクライアント認証を持つシャーディングされたクラスターを配置します。

OIDC 構成の詳細

フィールド	タイプと必要性	説明	例
`spec.security.authentication.modes`	文字列の配列必須	有効にする認証メカニズムの配列。OIDC認証を有効にするには「OIDC」を含める必要があります。	`["SCRAM", "OIDC"]`
`spec.security.authentication.oidcProviderConfigs.configurationName`	string。必須	このプロバイダー構成の一意の論理名。この名前は、ロールをマッピングするときに使用されます。	`"example-provider"`
`spec.security.authentication.oidcProviderConfigs.issuerURI`	string。必須	OIDC プロバイダーの検出エンドポイントの URI 。	`"https://dev-12345.provider.com"`
`spec.security.authentication.oidcProviderConfigs.clientId`	string。必須	OIDC プロバイダーに登録されたアプリケーションのクライアントID 。	`"0oa1b2c3d4e5f6g7h8"`
`spec.security.authentication.oidcProviderConfigs.audience`	string。必須	JSON web token のオーディエンスクレーム。これは、 IdP によって発行されたトークンのオーディエンスと一致する必要があります。	`"api://default"`
`spec.security.authentication.oidcProviderConfigs.userClaim`	string。任意	MongoDB がユーザー名として使用するJSON web token クレーム。デフォルトは `sub` です。	`"sub"`
`spec.security.authentication.oidcProviderConfigs.groupsClaim`	string。任意	ユーザーのグループメンバーシップを含むJSON web token クレーム。 `authorizationType` が `GroupMembership` の場合は必須です。	`"groups"`
`spec.security.authentication.oidcProviderConfigs.authorizationMethod`	string。必須	フェデレーションメソッド。`WorkloadIdentityFederation` または `WorkforceIdentityFederation` になります。	`"WorkforceIdentityFederation"`
`spec.security.authentication.oidcProviderConfigs.authorizationType`	string。必須	認可モデル。`UserID` または `GroupMembership` になります。	`"GroupMembership"`
`spec.security.authentication.oidcProviderConfigs.requestedScopes`	文字列の配列任意	OIDC プロバイダーにリクエストする追加のスコープのリスト。	`["openid", "profile", "groups"]`

OIDC 認証モデルの理解

MongoDBの OIDC 構成は、 フェデレーションメソッド と 認証タイプ の 2 つの重要な概念を組み合わせたものです。

フェデレーションメソッド（`authorizationMethod`）

この設定は、認証される ID のタイプについてMongoDB に指示します。

WorkforceIdentityFederation: これは 人間のユーザー に使用します。このメソッドは、 IdP 経由で認証する開発者、アナリスト、または管理者など、システムにログインするユーザーを対象としています。
WorkloadIdentityFederation: アプリケーションまたはサービス（マシン間通信）に使用します。このメソッドは、マイクロサービス、バッチするジョブ、データベースに接続する必要があるオートメーションスクリプトなど、人間以外の ID に対するものです。

認証タイプ（`authorizationType`）

この設定は、ユーザーまたはサービスが認証された後にMongoDB が権限を付与する方法を定義します。

GroupMembership: これは、最も一般的でスケーラブルなアプローチです。このタイプでは、 MongoDB はJSON web token（groupsClaim で定義）の特定のクレームを使用します。このクレームにはユーザーが属するグループのリストが含まれます。次に、これらのグループ名をMongoDBロールにマッピングします。groupsClaim を設定する必要があります。
UserID: このタイプでは、 MongoDB はユーザーを一意に識別するクレームを使用します（userClaim によって定義され、デフォルトは sub）。次に、この特定の個々のユーザーID をMongoDBUser にマッピングします（MongoDBUser を別途作成する必要があります）。これはより粒度が高く、グループを使用せずに単一のユーザーまたは特定のサービス ID に権限を付与するのに便利です。

OIDC のロールと権限の管理

OIDC プロバイダーを構成したら、権限を付与する必要があります。これに使用する方法は、選択した authorizationType によって異なります。

メソッド 1: Groupメンバーシップのロールマッピング

authorizationType: GroupMembership を使用する場合は、 MongoDBリソース内の spec.security.roles 配列にロールマッピングを追加して権限を付与します。ロールフィールドの形式は <configurationName>/<groupNameFromToken> である必要があります。

roles:
 - role: "idp-human-users/app-devs" # Maps the "app-devs" group from the IdP
   db: "admin"
   roles:
     - role: "readWrite"
       db: "app-data"

メソッド 2: ユーザー ID のユーザー作成

authorizationType: UserID を使用する場合は、権限を付与するために別の MongoDBUserリソースを作成する必要があります。

詳しくは、OIDC/OAuth による認証と認可 2.0 を参照してください。

レプリカセットの OIDC クライアント認証の構成

レプリカセットの OIDC を構成するには、次の手順に従います。

Kubernetes Operatorレプリカセットの定義ファイルを取得します。

既存のレプリカセット定義ファイルがある場合は、それを開きます。それ以外の場合は、以下の動作例全体をコピーできます。

OIDC認証設定を追加します。

定義ファイルで、spec.security セクションを変更します。ユースケースに基づいて、次の例から 1 つ以上を選択します。oidcProviderConfigs 配列で複数のプロバイダー構成を組み合わせることができます。

例 A: グループメンバーシップを持つワークフォースフェデレーション

これを使用して、 IdP のグループメンバーシップに基づいて人間ユーザーを認証します。これは、ユーザーのチームを管理するための最も一般的なモデルです。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-replicaset
spec:
  type: ReplicaSet
  members: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        - configurationName: "idp-human-users"
          issuerURI: "https://<your-idp-domain>"
          clientId: "<your-client-id>"
          audience: "api://default"
          groupsClaim: "groups"
          authorizationMethod: "WorkforceIdentityFederation"
          authorizationType: "GroupMembership"
    roles:
      - role: "idp-human-users/app-devs"
        db: "admin"
        roles:
          - role: "readWrite"
            db: "app-data"

例 B: ユーザー ID を使用したワークロードフェデレーション

これを使用して、特定の ID でアプリケーションまたはサービスを認証します。これはサービスアカウントに最適です。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-replicaset
spec:
  type: ReplicaSet
  members: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        - configurationName: "billing-service-auth"
          issuerURI: "https://<your-idp-uri>"
          clientId: "<billing-service-client-id>"
          audience: "mongodb-api"
          userClaim: "sub"
          authorizationMethod: "WorkloadIdentityFederation"
          authorizationType: "UserID"

注意

注: この ID の権限を付与するには、MongoDBUserリソースも作成する必要があります。そのリソース内のユーザー名を billing-service-auth/<user-subject-from-jwt> に設定する必要があります。

詳細については、OIDC 認証を使用したデータベースユーザーの管理を参照してください。

例C: ユーザー ID を使用したワークフォースフェデレーション

これを使用して、グループメンバーシップによってカバーされていない特定の人間ユーザーに一意の権限を付与します。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-replicaset
spec:
  type: ReplicaSet
  members: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        - configurationName: "idp-special-user"
          issuerURI: "https://<your-idp-domain>"
          clientId: "<your-client-id>"
          audience: "api://default"
          userClaim: "sub"
          authorizationMethod: "WorkforceIdentityFederation"
          authorizationType: "UserID"

注意

詳細については、OIDC 認証を使用したデータベースユーザーの管理を参照してください。

例 D: グループメンバーシップを持つワークロードフェデレーション

これを使用して、すべて同じ権限を必要とする関連サービスまたはアプリケーションのグループを認証します。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-replicaset
spec:
  type: ReplicaSet
  members: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        - configurationName: "reporting-services"
          issuerURI: "https://<your-idp-uri>"
          clientId: "<reporting-services-client-id>"
          audience: "mongodb-api"
          groupsClaim: "service-roles"
          authorizationMethod: "WorkloadIdentityFederation"
          authorizationType: "GroupMembership"
    roles:
      - role: "reporting-services/report-generators"
        db: "admin"
        roles:
          - role: "read"
            db: "sales-data"

構成を適用します。

kubectl apply -f <your-replica-set-file>.yaml

配置のステータスを追跡します。

kubectl get mdb <resource-name> -o yaml -w

シャードクラスタの OIDC クライアント認証の構成

次の例を使用して、シャーディングされたクラスターの OIDC を構成します。原則と構成オプションはレプリカセットと同じです。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-shardedcluster
spec:
  type: ShardedCluster
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        # Provider 1: For human users (Workforce/Group)
        - configurationName: "idp0-human-users"
          issuerURI: "https://<your-idp0-domain>"
          clientId: "<human-users-client-id>"
          audience: "api://default"
          groupsClaim: "groups"
          authorizationMethod: "WorkforceIdentityFederation"
          authorizationType: "GroupMembership"
        # Provider 2: For service accounts (Workload/UserID)
        - configurationName: "service-accounts"
          issuerURI: "https://<your-idp-uri>"
          clientId: "<services-client-id>"
          audience: "mongodb-api"
          userClaim: "sub"
          authorizationMethod: "WorkloadIdentityFederation"
          authorizationType: "UserID"
    roles:
      # Role mapping for the human user group
      - role: "idp0-human-users/db-admins"
        db: "admin"
        roles:
          - role: "readWriteAnyDatabase"
            db: "admin"

OIDC のトラブルシューティング

JSON web token トークンの手動検証: ツールを使用して OIDC トークンをデコードします。
- コアクレーム: トークン内の iss（発行者）と aud（オーディエンス）クレームが OIDC プロバイダーの構成と完全に一致していることを確認します。トークンが期限切れでないことを確認します（expクレーム）。
- 予想されるユーザーまたはグループのクレーム: ユーザー ID（userClaim）とグループ（groupsClaim）の予想されるクレームがトークンに存在し、正しい値が含まれていることを確認します。
ユーザー ID 認証のユーザー名形式を確認する: MongoDBUserユーザー名は正確な形式<configurationName>/<userClaimValue> である必要があります。<configurationName> は、MongoDBリソース内の OIDC プロバイダーの名前と一致する必要があります。
$external データベースが使用されていることを確認します。 UserID認可の場合、MongoDBUserリソースはdb: "$external" を指定する必要があります。外部ソースによって認証されたユーザーは、常にこの仮想データベースを通じて解決されます。
GroupMemembership 認証のグループロールマッピングを確認する: MongoDBリソースの spec.security.roles セクションで定義されているロールが <configurationName>/<groupName> として正しく形式設定されていることを確認します。ここでは、<groupName> はJSON web token の groupsClaim 内のグループと完全に一致します。
割り当てられたロール権限を検証します: OIDC ユーザーまたはグループに割り当てられたMongoDBロールが実際に必要な権限（例: 正しいデータベースの readWrite）を付与していることを確認します。
MongoDBUser リソース参照を確認します: UserID認可の場合、MongoDBUserリソース内の spec.mongodbResourceRef.name が MongoDB 配置の名前を正しく指していることを確認します。

注意