Se usó la API de Cloud Translation para traducir esta página.

Configura clústeres miembros de la flota para la autenticación con LDAP

En este documento, se describe cómo los administradores de clústeres o los operadores de aplicaciones pueden configurar clústeres de Kubernetes para admitir la autenticación de un proveedor externo de Lightweight Directory Access Protocol (LDAP), como Microsoft Entra ID o Google LDAP. Para obtener más información, consulta Acerca de la autenticación con identidades de terceros.

Limitaciones

Debes usar un tipo de clúster que admita LDAP.

Antes de comenzar

Install the Google Cloud CLI.
Si usas un proveedor de identidad externo (IdP), primero debes acceder a la gcloud CLI con tu identidad federada.
Para inicializar gcloud CLI, ejecuta el siguiente comando:
```
gcloud init
```
Después de inicializar gcloud CLI, actualízala y, luego, instala los componentes necesarios:
```
gcloud components update
gcloud components install kubectl
```
Asegúrate de que el administrador de tu plataforma te haya proporcionado toda la información del proveedor que necesitas. Para obtener más información, consulta Configura proveedores de LDAP para la autenticación en clústeres.

A lo largo de esta configuración, es posible que debas consultar la documentación de tu servidor LDAP. En las siguientes guías de administrador, se explica la configuración de algunos proveedores de LDAP populares, incluido dónde encontrar la información que necesitas para acceder al servidor LDAP y configurar tus clústeres:

Propaga el secreto de la cuenta de servicio de LDAP

Tu clúster necesita un secreto de cuenta de servicio para autenticarse en el servidor LDAP y recuperar detalles del usuario. La autenticación LDAP admite los siguientes mecanismos:

Autenticación básica, en la que usas un nombre de usuario y una contraseña
Autenticación con certificado de cliente, en la que se usa una clave privada y un certificado de cliente

Tú o el administrador de la plataforma deben tener esta información sobre tu proveedor de Configura proveedores de LDAP para la autenticación en clústeres. Para que la información de acceso del servidor LDAP esté disponible para el clúster, debes crear un Secret de Kubernetes que tenga los detalles de acceso de LDAP. En los siguientes ejemplos, se muestra cómo configurar Secrets para ambos tipos de autenticación. En los ejemplos, se muestra el Secret que se aplica al espacio de nombres anthos-identity-service.

Este es un ejemplo de una configuración de Secret de autenticación básica:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: "anthos-identity-service"
type: kubernetes.io/basic-auth     # Make sure the type is correct
data:
  username: USERNAME  # Use a base64-encoded username
  password: PASSWORD  # Use a base64-encoded password

donde SERVICE_ACCOUNT_SECRET_NAME es el nombre que elegiste para este Secret. Reemplaza los valores de nombre de usuario y contraseña por el nombre de usuario y la contraseña que obtuviste en el paso anterior. USERNAME es un nombre de usuario codificado en base64 PASSWORD es una contraseña codificada en base64

Este es un ejemplo de una configuración de Secret del certificado de cliente:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: anthos-identity-service
type: kubernetes.io/tls            # Make sure the type is correct
data:
  # the data is abbreviated in this example
  tls.crt: |
       MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

Reemplaza SERVICE_ACCOUNT_SECRET_NAME por el nombre que elegiste para este Secret. Reemplaza el certificado TLS y los valores de clave por el certificado codificado y los valores de clave que obtuviste en el paso anterior.

En los ejemplos, se muestra el Secret que se aplica al espacio de nombres anthos-identity-service. De forma predeterminada, los componentes del sistema tienen permiso para leer Secrets en este espacio de nombres. Para usar otro espacio de nombres, cambia los metadatos en el Secret y, luego, agrega una nueva política de RBAC para otorgar permiso de lectura de Secrets en ese espacio de nombres a la ServiceAccount default en el espacio de nombres anthos-identity-service, de la siguiente manera:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: NAMESPACE
  name: ais-secret-reader-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ais-secret-reader-role-binding
  namespace: NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ais-secret-reader-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: anthos-identity-service
---

Configura el clúster

Para configurar la autenticación en un clúster con LDAP, agrega la siguiente información a un recurso personalizado de Kubernetes llamado ClientConfig:

Es información sobre el proveedor de identidad y los parámetros que necesita para devolver información del usuario.
El nombre y el espacio de nombres del Secret que creaste y aplicaste en el paso anterior, lo que permite que el clúster se autentique en el servidor de LDAP.

Para configurar tu clúster, edita el ClientConfig default en el espacio de nombres kube-public:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster. Si hay varios contextos en kubeconfig, se usa el contexto actual. Es posible que debas restablecer el contexto actual en el clúster correcto antes de ejecutar el comando.

A continuación, se muestra el formato para la configuración de ClientConfig:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    ldap:
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      connectionType: CONNECTION_TYPE
      host: HOST_NAME
      serviceAccountSecret:
        name: SERVICE_ACCOUNT_SECRET_NAME
        namespace: NAMESPACE
        type: SECRET_FORMAT
      user:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE
        loginAttribute: LOGIN_ATTRIBUTE
      group:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE

Puedes agregar varias configuraciones de proveedores de identidad de OIDC, LDAP y SAML al mismo ClientConfig. El clúster intenta autenticarse con cada configuración en el orden en que se definen y se detiene después de la primera autenticación exitosa. El siguiente ejemplo de ClientConfig define varios proveedores de identidad en un orden específico:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - aws:
      region: us-west-2
    name: AWS Login
  - ldap:
  # Multiple lines are omitted here.
  - saml:
  # Multiple lines are omitted here.
  - azureAD:
  # Multiple lines are omitted here.
  - oidc:
    name: Okta OIDC
  # Multiple lines are omitted here.
  - oidc:
    name: Google OIDC
  # Multiple lines are omitted here.

Campos de LDAP de ClientConfig

En la siguiente tabla, se describen los campos del objeto de ClientConfig ldap. Los campos que debes agregar dependen de los tokens de tu proveedor de identidad y de cómo el administrador de la plataforma configuró el proveedor.

Campo	Obligatorio	Descripción	Formato
nombre	sí	Un nombre para identificar esta configuración de LDAP	string
host	sí	Nombre de host o dirección IP del servidor LDAP. El puerto es opcional y se establece de forma predeterminada en 389, si no se especifica. Por ejemplo, `ldap.server.example.com` o `10.10.10.10:389`.	string
certificateAuthorityData	Obligatorio para ciertos tipos de conexión LDAP	Contiene un certificado de autoridad certificadora con formato PEM y codificado en Base64 para el servidor LDAP. Solo se debe proporcionar para conexiones de `ldaps` y `startTLS`.	string
connectionType	sí	El tipo de conexión LDAP que se utilizará cuando se conecte al servidor LDAP. La configuración predeterminada es `startTLS`. El modo `insecure` solo debe usarse para el desarrollo, ya que toda la comunicación con el servidor se realizará en texto simple.	string
serviceAccountSecret
nombre	sí	El nombre del Secret de Kubernetes que almacena las credenciales de la cuenta de servicio de LDAP.	string
espacio de nombres	sí	El espacio de nombres del Secret de Kubernetes que almacena las credenciales para la cuenta de servicio de LDAP.	string
tipo	sí	Define el formato del Secret de la cuenta de servicio para admitir diferentes tipos de secretos. Si especificaste `basic-auth` en tu configuración de Secret, debería ser `basic`; de lo contrario, debería ser `tls`. Si no se especifica, `basic` se establece de forma predeterminada.	string
usuario
baseDN	sí	La ubicación del subárbol en el directorio LDAP para buscar entradas de usuario.	string
filtro	no	Filtro opcional que se debe aplicar cuando se busca el usuario. Esto se puede usar para restringir aún más las cuentas de usuario que tienen acceso. Si no se especifica, se establece de forma predeterminada como `(objectClass=User)`.	string
identifierAttribute	no	Determina qué atributo usar como identidad del usuario después de la autenticación. Esto es diferente del campo loginAttribute para permitir que los usuarios accedan con un nombre de usuario, pero que su identificador real sea una dirección de correo electrónico o un Nombre distinguido (DN) completo. Por ejemplo, configurar loginAttribute en `sAMAccountName` y identifierAttribute en `userPrincipalName` permitiría que un usuario acceda como `bsmith`, pero las políticas de RBAC reales del usuario se escribirían como `bsmith@example.com`. Se recomienda usar `userPrincipalName`, ya que será único para cada usuario. Si no se especifica, el valor predeterminado es `userPrincipalName`.	string
loginAttribute	no	El nombre del atributo que coincide con el nombre de usuario de entrada. Se usa para encontrar al usuario en la base de datos de LDAP, por ejemplo `(<LoginAttribute>=<username>)`, y se combina con el campo de filtro opcional. El valor predeterminado es `userPrincipalName`.	string
grupo (campo opcional)
baseDN	sí	La ubicación del subárbol en el directorio LDAP para buscar entradas de grupo.	string
filtro	no	El filtro opcional que se usará cuando se busquen grupos a los que pertenece un usuario. Esto se puede usar para hacer coincidir de manera explícita solo determinados grupos, a fin de reducir la cantidad de grupos que se muestran para cada usuario. La configuración predeterminada es `(objectClass=Group)`.	string
identifierAttribute	no	El nombre de identificación de cada grupo al que pertenece un usuario. Por ejemplo, si se configura como `distinguishedName`, los RBAC y otras expectativas del grupo deben escribirse como Nombres distinguidos completos. Si no se especifica, el valor predeterminado es `distinguishedName`.	string

Próximos pasos

Después de aplicar la configuración, continúa con la configuración del acceso de los usuarios desde proveedores externos a los clústeres.

Configura clústeres miembros de la flota para la autenticación con LDAP Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.