Configurar la autenticación OIDC de un solo clúster

Considerations

Al habilitar la autenticación OIDC, tenga en cuenta lo siguiente:

• Proveedores de identidad: Debes tener un proveedor de identidad OIDC (IdP) configurado previamente. El operador de Kubernetes no gestiona el proveedor de identidad en sí.

• Autorización: El Operador de Kubernetes configura la autenticación (verificación de identidad) a través de OIDC. La autorización (concesión de permisos) se gestiona mapeando los claims de OIDC a roles de MongoDB dentro del recurso personalizado de MongoDB.

• Federación: MongoDB admite tanto la federación de identidades de cargas de trabajo (para autenticación de máquina a máquina) como la federación de identidades del personal (para autenticación de usuarios).

• Cifrado TLS: Para mejorar la seguridad, se recomienda implementar un set de réplicas con cifrado TLS o un clúster con cifrado TLS. Aunque la comunicación OIDC con tu proveedor de identidad esté protegida mediante HTTPS, habilitar TLS en tu recurso de MongoDB cifra la conexión entre tu aplicación cliente y la base de datos. Esto protege el token OIDC y todo el tráfico de la base de datos de amenazas en la red.

Requisitos generales previos

Antes de configurar la autenticación OIDC para tus implementaciones de MongoDB, completa las siguientes tareas:

• Asegúrate de implementar el recurso de base de datos MongoDB Enterprise. Las bases de datos Community de MongoDB no admiten autenticación OIDC.

• Implementa el set de réplicas o implementa el clúster particionado cuya autenticación de cliente quieres asegurar con OpenID Connect.

Detalles de configuración de OIDC

Comprensión de los modelos de autorización de OIDC

La configuración de OIDC en MongoDB combina dos conceptos clave: el Método de federación y el Tipo de autorización.

Administración de roles y permisos de OIDC

Después de configurar un proveedor OIDC, debes conceder permisos. El método que utilices para hacer esto depende del authorizationType que hayas seleccionado.

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

Configurar autenticación de cliente OIDC para un set de réplicas

Siga estos pasos para configurar OIDC para un conjunto de réplicas.

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"

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"

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"

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

Configura la autenticación de cliente OIDC para un clúster fragmentado

Utiliza el siguiente ejemplo para configurar OIDC en un clúster fragmentado. Los principios y las opciones de configuración son idénticos a los de un set de réplicas.

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"

Solución de problemas de OIDC

• Validar manualmente el token JWT: utilice una herramienta para decodificar el token OIDC.

  • Afirmaciones principales: Asegúrese de que las afirmaciones iss (emisor) y aud (audiencia) en el token coincidan exactamente con la configuración de su proveedor OIDC. Compruebe que el token no haya expirado (afirmación exp).

  • Reclamaciones de usuario/grupo esperadas: verifique que las reclamaciones esperadas para la identidad de usuario ()userClaim y los gruposgroupsClaim () estén presentes en el token y contengan los valores correctos.

• Verificar el formato del usuario para la autenticación UserID: El nombre de usuario MongoDBUser debe estar en el formato exacto <configurationName>/<userClaimValue>. El <configurationName> debe coincidir con el nombre del proveedor de OIDC en tu recurso MongoDB.

• Confirmar que se usa la base de datos $external: Para la autorización de UserID, el recurso MongoDBUser debe especificar db: "$external". Los usuarios autenticados por una fuente externa siempre se resuelven a través de esta base de datos virtual.

• Verificar la mapeo de roles de grupo para GroupMembership Auth: Asegúrese de que el rol definido en la sección spec.security.roles del recurso de MongoDB esté formateado correctamente como <configurationName>/<groupName>, donde <groupName> coincida exactamente con un grupo en el groupsClaim de JWT.

• Validar los permisos del rol asignados: verifique que el rol de MongoDB asignado al usuario o grupo OIDC realmente otorgue los permisos necesarios (por ejemplo, readWrite en la base de datos correcta).

• Verifica la Referencia de Recursos MongoDBUser: Para la autorización UserID, asegúrate de que el spec.mongodbResourceRef.name en el recurso MongoDBUser apunte correctamente al nombre de tu implementación MongoDB.