Esta página se ha traducido con Cloud Translation API.

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

En este documento se describe cómo pueden configurar los administradores de clústeres o los operadores de aplicaciones los clústeres de Kubernetes para que admitan la autenticación de un proveedor de protocolo ligero de acceso a directorios (LDAP) de terceros, como ID de Microsoft Entra o Google LDAP. Para obtener más información, consulta el artículo Acerca de la autenticación con identidades de terceros.

Limitaciones

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

Antes de empezar

Install the Google Cloud CLI.
Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.
Para inicializar gcloud CLI, ejecuta el siguiente comando:
```
gcloud init
```
Después de inicializar gcloud CLI, actualízala e instala los componentes necesarios:
```
gcloud components update
gcloud components install kubectl
```
Asegúrate de que el administrador de tu plataforma te ha proporcionado toda la información que necesitas sobre el proveedor. Para obtener más información, consulta Configurar proveedores de LDAP para autenticar clústeres.

Durante la configuración, es posible que tengas que consultar la documentación de tu servidor LDAP. En las siguientes guías para administradores se explica cómo configurar algunos proveedores de LDAP populares, así como dónde encontrar la información que necesitas para iniciar sesión en el servidor LDAP y configurar tus clústeres:

Rellenar 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 obtener los detalles de los usuarios. La autenticación LDAP admite los siguientes mecanismos:

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

Tú o el administrador de tu plataforma deberíais tener esta información sobre vuestro proveedor después de seguir los pasos que se indican en el artículo Configurar proveedores de LDAP para autenticar clústeres. Para que el clúster pueda acceder a la información de inicio de sesión del servidor LDAP, debes crear un secreto de Kubernetes que contenga los detalles de inicio de sesión de LDAP. En los siguientes ejemplos se muestra cómo configurar secretos para ambos tipos de autenticación. En los ejemplos se muestra cómo se aplica el secreto al espacio de nombres anthos-identity-service.

Este es un ejemplo de 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 has elegido para este secreto. Sustituye los valores de nombre de usuario y contraseña por los que has obtenido 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 configuración de un secreto de 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 ...

Sustituye SERVICE_ACCOUNT_SECRET_NAME por el nombre que has elegido para este secreto. Sustituye los valores de la clave y el certificado TLS por los valores codificados de la clave y el certificado que has obtenido en el paso anterior.

En los ejemplos se muestra cómo se aplica el secreto al espacio de nombres anthos-identity-service. De forma predeterminada, los componentes del sistema tienen permiso para leer secretos en este espacio de nombres. Para usar otro espacio de nombres, cambia los metadatos del secreto y, a continuación, añade una nueva política de RBAC para conceder permiso de lectura de secretos en ese espacio de nombres a la default ServiceAccount del espacio de nombres anthos-identity-service, como se indica a continuación:

---
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
---

Configurar el clúster

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

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 secreto que has creado y aplicado en el paso anterior, que permite que el clúster se autentique en el servidor LDAP.

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

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

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

A continuación se muestra el formato de 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 añadir varias configuraciones de proveedor de identidades 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 correcta. En el siguiente ejemplo de ClientConfig se definen 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 LDAP de ClientConfig

En la siguiente tabla se describen los campos del objeto ClientConfig ldap. Los campos que debes añadir dependen de los tokens de tu proveedor de identidades y de cómo haya configurado el proveedor el administrador de tu plataforma.

Campo	Obligatorio	Descripción	Formato
name	yes	Nombre para identificar esta configuración de LDAP	cadena
host	yes	Nombre de host o dirección IP del servidor LDAP. El puerto es opcional y, si no se especifica, se usará el 389 de forma predeterminada. Por ejemplo, `ldap.server.example.com` o `10.10.10.10:389`.	cadena
certificateAuthorityData	Obligatorio para determinados tipos de conexión LDAP	Contiene un certificado de autoridad de certificación con formato PEM y codificado en Base64 para el servidor LDAP. Solo se debe proporcionar para las conexiones `ldaps` y `startTLS`.	cadena
connectionType	yes	Tipo de conexión LDAP que se debe usar al conectarse al servidor LDAP. El valor predeterminado es `startTLS`. El modo `insecure` solo debe usarse para el desarrollo, ya que toda la comunicación con el servidor será en texto sin formato.	cadena
serviceAccountSecret
name	yes	Nombre del secreto de Kubernetes que almacena las credenciales de la cuenta de servicio LDAP.	cadena
espacio de nombres	yes	Espacio de nombres del secreto de Kubernetes que almacena las credenciales de la cuenta de servicio de LDAP.	cadena
tipo	yes	Define el formato del secreto de la cuenta de servicio para admitir diferentes tipos de secretos. Si has especificado `basic-auth` en la configuración de Secret, debe ser `basic`. De lo contrario, debe ser `tls`. Si no se especifica, se asigna el valor `basic` de forma predeterminada.	cadena
usuario
baseDN	yes	Ubicación del subárbol en el directorio LDAP en el que se buscarán las entradas de usuario.	cadena
filtrar	no	Filtro opcional que se aplica al buscar el usuario. Se puede usar para restringir aún más las cuentas de usuario que pueden iniciar sesión. Si no se especifica, se asigna el valor `(objectClass=User)` de forma predeterminada.	cadena
identifierAttribute	no	Determina qué atributo se debe usar como identidad del usuario una vez que se haya autenticado. Este campo es distinto del campo loginAttribute para permitir que los usuarios inicien sesión con un nombre de usuario, pero que su identificador real sea una dirección de correo o un nombre completo (DN). Por ejemplo, si se asigna el valor `sAMAccountName` a loginAttribute y el valor `userPrincipalName` a identifierAttribute, un usuario podrá iniciar sesión como `bsmith`, pero las políticas de RBAC reales del usuario se escribirán como `bsmith@example.com`. Se recomienda usar `userPrincipalName`, ya que será único para cada usuario. Si no se especifica, el valor predeterminado es `userPrincipalName`.	cadena
loginAttribute	no	Nombre del atributo que coincide con el nombre de usuario introducido. Se usa para buscar el usuario en la base de datos LDAP, por ejemplo, `(<LoginAttribute>=<username>)`, y se combina con el campo de filtro opcional. El valor predeterminado es `userPrincipalName`.	cadena
Grupo (campo opcional)
baseDN	yes	Ubicación del subárbol en el directorio LDAP en el que se buscarán las entradas de grupo.	cadena
filtrar	no	Filtro opcional que se usa al buscar los grupos a los que pertenece un usuario. Se puede usar para que solo se incluyan determinados grupos y, de esta forma, reducir el número de grupos devueltos por usuario. El valor predeterminado es `(objectClass=Group)`.	cadena
identifierAttribute	no	Nombre identificativo de cada grupo al que pertenece un usuario. Por ejemplo, si se define como `distinguishedName`, los RBACs y otras expectativas de grupo deben escribirse como DNs completos. Si no se especifica, el valor predeterminado es `distinguishedName`.	cadena

Siguientes pasos

Una vez que se haya aplicado la configuración, configura el acceso de los usuarios de proveedores externos a los clústeres.

Configurar clústeres miembros de la flota para la autenticación LDAP Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.