/ /

Atlas Access

Docs Home

Management

Atlas Kubernetes Operator

Atlas Access

Docs Home

Management

Atlas Kubernetes Operator

Atlas Access

Configure Federated Authentication Using the Atlas Kubernetes Operator

The Atlas Kubernetes Operator (AKO) provides support for configuring federated authentication in MongoDB Atlas using the AtlasFederatedAuth Custom Resource.

Federated authentication enables you to link user credentials across systems using an Identity Provider (IdP). It serves two core purposes:

Manage user access to the Atlas UI (restricting permissions for viewing, creating, and configuring resources).
Authenticate and authorize access to Atlas clusters (for human users and applications).

Both functionalities can be configured simultaneously through the AtlasFederatedAuth Custom Resource.

Note

Atlas Kubernetes Operator supports the configuration of existing IdPs in an Atlas Organization, not the creation of them in Atlas. You must complete this procedure before using this resource with AKO.

Learn how to create a SAML IdP for UI Access in Manage Identity Providers.
Learn how to create an IdP for cluster access for a workforce (OIDC) in Configure an External Identity Provider Application.
Learn how to create an IdP for cluster access for an application/workload (OAuth 2.0) in Prepare Your External Identity Provider.

Atlas UI Access (SAML)

Atlas access (or UI Access) allows Organization owners to automatically grant roles in Atlas to users in the organization once they authenticate, based on their roles in an IdP such as Microsoft Entra ID or Google Workspace.

Note

When a federated IdP is enabled, Atlas disables all other authentication methods.

Once you have created a UI Access IdP and associated it with your organization, you can configure it using the Atlas Kubernetes Operator.

This example does the following:

Enables federated authentication for the organization linked to the specified secret.
Adds my-org-domain.com as an approved domain.
Enables domain restriction for the organization.
Disables debugging for SSO.
Grants the Organization Member role to users after authenticating.
Maps the Organization Owner role for the organization and applies the role mapping to an IdP group named org-admin.
Maps the Organization Project Creator and Project Owner roles for a project in the organization named dev-project and applies the role mapping to an IdP group named dev-team.

Note

The spec.roleMappings.roleAssignments parameter must include at least one organization role within the current organization or the projects in the organization.

Example:

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

Additional information on configuring the AtlasFederatedAuth resource can be found in the AtlasFederatedAuth Custom Resource.

Atlas Cluster Access (OIDC/OAuth 2.0)

Cluster Access allows Organization owners to use identity providers (using OIDC or OAuth 2.0) to provide data access to a database cluster in Atlas based on roles in the IdP. This feature can be further distinguished by whether the access is being granted to a human user, or to an application:

Workload is for Applications; allowing external applications to authenticate via programmatic identities, such as Service Principals in Azure or Service Accounts in Google Cloud, using OAuth 2.0.
Workforce is for users; allowing authentication and authorization to the database via an external IdP, such as Microsoft Entra ID or Okta, using OIDC.

To enable Atlas Cluster Access via AKO, add the IdP ID to the dataAccessIdentityProviderIds field in the AtlasFederatedAuth resource.

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

Additional information on configuring the AtlasFederatedAuth resource can be found in the AtlasFederatedAuth Custom Resource.

The authentication enables the IdP for usage within the organization, and cluster access can now be granted using this IdP in the AtlasDatabaseUser, by configuring the oidcAuthType and setting the appropriate ID and name in the username field.

For Workforce access, set the oidcAuthType field to USER, the databaseName field to admin, and the username field to <Atlas IdP ID>/IdP Username.
For Workload access, set the oidcAuthType field to IDP_GROUP, the databaseName field to $external, and the username field to <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

Additional information on configuring the AtlasDatabaseUser resource can be found in the AtlasDatabaseUser Custom Resource.

Back

Encrypt Data

Teams