Atlas Kubernetes Operator（AKO）は、MongoDB Atlasでフェデレーティッド認証を構成するためのサポートを、AtlasFederatedAuth カスタム リソースを使用して提供します。
フェデレーティッド認証を使用すると、IdP（IdP）を使用してシステム間でユーザー認証情報をリンクできます。これは 2 つの主要な目的を果たします。
Atlas UIへのユーザー アクセスを管理します（リソースの表示、作成、構成の権限を制限します）。
Atlas クラスター（人間とアプリケーション）へのアクセスを認証および承認します。
AtlasFederatedAuth カスタム リソースを使用して両方の機能を同時に構成できます。
注意
Atlas Kubernetes Operator は、Atlas での IdP の作成ではなく、Atlas 組織内の既存の IdP の構成をサポートします。このリソースをACO で使用する前に、この手順を完了する必要があります。
「 IdP の管理 」でUIアクセス用の SAML IdP を作成する方法を学びます。
ワークフォース（OIDC）のクラスターアクセス用 IdP を作成する方法については、「外部 IdP アプリケーションの構成」を参照してください。
アプリケーションやワークロード（OAuth 2.0）のクラスターアクセス用IdPを作成する方法については、外部 IdP を準備するを参照してください。
Atlas UI Access (SAML)
Atlas アクセス（またはUIアクセス）により、組織の所有者は、Microsoft Entra IDやGoogle WorkspaceなどのIdPのロールに基づいて、認証時に組織内のユーザーに Atlas のロールを自動的に付与できます。
注意
フェデレーティッド IdP が有効になっている場合、Atlas は他のすべての認証方法を無効にします。
UIアクセス IdP を作成し、組織に関連付けたら、Atlas Kubernetes Operatorを使用して構成できます。
この例では、次の処理を行います。
指定されたシークレットにリンクされた組織のフェデレーティッド認証を有効にします。
承認されたドメインとして
my-org-domain.comを追加します。組織のドメイン制限を有効にします。
SSOのデバッグを無効にします。
認証後のユーザーに
Organization Memberロールを付与します。組織の
Organization Ownerロールをマッピングし、org-adminという名前のIdPグループにロール マッピングを適用します。dev-projectという名前の組織内のプロジェクトのOrganization Project Creator} ロールとProject Ownerロールをマッピングし、dev-teamという名前のIdPグループにロール マッピングを適用します。
注意
spec.roleMappings.roleAssignmentsパラメーターには、現在の組織内の少なくとも 1 つの組織ロールまたは組織内のプロジェクトを含める必要があります。
例:
cat <<EOF | kubectl apply -f - apiVersion: atlas.mongodb.com/v1 kind: AtlasFederatedAuth metadata: name: atlas-default-federated-auth namespace: mongodb-atlas-system spec: enabled: true connectionSecretRef: name: my-org-secret namespace: mongodb-atlas-system domainAllowList: - my-org-domain.com domainRestrictionEnabled: true ssoDebugEnabled: false postAuthRoleGrants: - ORG_MEMBER roleMappings: - externalGroupName: org-admin roleAssignments: - role: ORG_OWNER - externalGroupName: dev-team roleAssignments: - role: ORG_GROUP_CREATOR - projectName: dev-project role: GROUP_OWNER EOF
AtlasFederatedAuthリソースの構成に関する追加情報は AtlasFederatedAuth カスタム リソースにあります。
Atlas クラスターアクセス（OIDC/OAuth 2.0）
クラスターアクセスを使用すると、組織の所有者は ID プロバイダー（OIDC または OAuth2.0 を使用）を使用して、 IdP のロールに基づいて Atlas のデータベースクラスターへのデータアクセスを提供できます。この機能は、アクセスが人間のユーザーに付与されるか、アプリケーションに付与されるかによってさらに区別されます。
ワークロードはアプリケーションのワークロードです。 OAuth 2.0 を使用して、Azureのサービスプリンシパルや Google Cloud のサービスアカウントなどのプログラムによる ID 経由での外部アプリケーションの認証を許可します。
従業員はユーザーのものです。 OIDC を使用して、 Microsoft Entra IDや Okta などの外部 IdP を介してデータベースへの認証と承認を許可します。
ACO 経由で Atlas クラスター アクセスを有効にするには、AtlasFederatedAuthリソースの dataAccessIdentityProviderIdsフィールドにIdP IDを追加します。
apiVersion: atlas.mongodb.com/v1 kind: AtlasFederatedAuth metadata: name: atlas-default-federated-auth namespace: mongodb-atlas-system spec: enabled: true dataAccessIdentityProviders: - 32b6e34b3d91647abb20e7b8 - 42d8v92k5a34184rnv93f0c1 connectionSecretRef: name: my-org-secret namespace: mongodb-atlas-system
AtlasFederatedAuthリソースの構成に関する追加情報は AtlasFederatedAuth カスタム リソースにあります。
この認証、組織内での IdP の使用が有効になり、 を構成し、 フィールドに適切なIDと名前を設定することで、 AtlasDatabaseUser でこの IdPoidcAuthType を使用してクラスターusername アクセスを許可できるようになりました。
oidcAuthTypeUSER従業員アクセスの場合は、databaseNameフィールドをadminに、usernameフィールドを に、 フィールドを<Atlas IdP ID>/IdP Usernameに設定します。ワークロード アクセス の場合は、
oidcAuthTypeフィールドをIDP_GROUPに、databaseNameフィールドを$externalに、usernameフィールドを<Atlas IdP ID>/IdP Group Nameに設定します。
apiVersion: atlas.mongodb.com/v1 kind: AtlasDatabaseUser metadata: name: my-workload-user namespace: mongodb-atlas-system spec: databaseName: $external roles: - roleName: "readWrite" databaseName: "my-database" projectRef: name: my-project username: idp-id-in-atlas/my-idp-group-name oidcAuthType: IDP_GROUP
apiVersion: atlas.mongodb.com/v1 kind: AtlasDatabaseUser metadata: name: my-workforce-user namespace: mongodb-atlas-system spec: databaseName: admin roles: - roleName: "readWrite" databaseName: "my-database" projectRef: name: my-project username: idp-id-in-atlas/my-idp-user-name oidcAuthType: USER
AtlasDatabaseUserリソースの構成に関する追加情報は AtlasDatabaseUser カスタム リソースにあります。