Configurar la autenticación OIDC de múltiples clústeres

Considerations

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

• Proveedores de identidad: Debe tener un proveedor de identidad (IdP) de OIDC preexistente y configurado. El operador de Kubernetes no administra el IdP.

• Autorización: El operador de Kubernetes configura la autenticación (verificación de identidad) mediante OIDC. La autorización (otorgación de permisos) se gestiona asignando notificaciones de OIDC a roles de MongoDB dentro del recurso personalizado de MongoDB.

• Federación: MongoDB admite tanto la federación de identidad de carga de trabajo (para la autenticación de máquina a máquina) como la federación de identidad de fuerza de trabajo (para la autenticación de usuarios humanos).

• Cifrado TLS: Para mejorar la seguridad, se recomienda implementar un conjunto de réplicas o un clúster fragmentado cifrados con TLS. Si bien la comunicación de OIDC con su proveedor de identidad está protegida mediante HTTPS, al habilitar TLS en su recurso MongoDB se cifra la conexión entre la aplicación cliente y la base de datos. Esto protege el token de OIDC y el resto del tráfico de la base de datos de las amenazas de red.

Requisitos generales

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

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

• Implemente el conjunto de réplicas o implemente el clúster fragmentado cuya autenticación de cliente desea proteger 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, debe otorgar permisos. El método que utilice para hacerlo dependerá del authorizationType seleccionado.

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

Configura la autenticación de cliente OIDC para un set de réplicas multi-Kubernetes-clúster

Siga estos pasos para configurar OIDC para un conjunto de réplicas. Para ver más ejemplos, consulte Autenticación segura de clientes con OIDC.

apiVersion: mongodb.com/v1
kind: MongoDBMultiCluster
metadata:
  name: my-multi-cluster-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"
  clusterSpecList:
    - clusterName: ${MDB_CLUSTER_1_FULL_NAME}
      members: 3
    - clusterName: ${MDB_CLUSTER_2_FULL_NAME}
      members: 2
    - clusterName: ${MDB_CLUSTER_3_FULL_NAME}
      members: 3

Solución de problemas de OIDC

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

  • Reclamaciones principales: Asegúrese de que las iss reclamaciones (emisor) y aud (audiencia) del token coincidan exactamente con la configuración de su proveedor OIDC. Compruebe que el token no esté caducadoexp (reclamación).

  • 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 nombre de usuario para la autenticación de ID de usuario: El MongoDBUser nombre de usuario debe tener el mismo formato <configurationName>/<userClaimValue> que. El debe <configurationName> coincidir con el nombre del proveedor de OIDC en su MongoDB recurso.

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

• Verifique la asignación de roles degrupo para la autenticación de membresía de grupo: asegúrese de que el rol definido en la sección del recurso MongoDB spec.security.roles tenga el formato correcto <configurationName>/<groupName> como, donde <groupName> coincida exactamente con un grupo en del groupsClaim JWT.

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

• Verificar la referencia del recurso MongoDBUser: para UserID la autorización, asegúrese de que el spec.mongodbResourceRef.name en el MongoDBUser recurso apunte correctamente al nombre de su MongoDB implementación.