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

Configura el servicio de identidad de GKE con LDAP

Este documento es para administradores de clústeres o para operadores de aplicaciones que configuran GKE Identity Service en sus clústeres. Se indica cómo configurar GKE Identity Service en los clústeres con tu proveedor de Protocolo ligero de acceso a directorios (LDAP), incluido Microsoft Active Directory. Se supone que tú o el administrador de la plataforma ya tienen detalles de acceso para el proveedor de LDAP mediante las instrucciones en Configura un proveedor de LDAP para GKE Identity Service.

Para obtener más información sobre cómo funciona GKE Identity Service y otras opciones de configuración, consulta la descripción general. Si quieres obtener información para acceder a un clúster con este servicio como desarrollador u otro usuario del clúster, consulta Accede a clústeres con GKE Identity Service.

En la actualidad, el servicio de identidad de GKE con LDAP solo se puede usar con GKE en VMware (clústeres de usuario) y GKE en Bare Metal.

Antes de comenzar

Asegúrate de tener instaladas las siguientes herramientas de línea de comandos:
- La versión más reciente de Google Cloud CLI, que incluye gcloud, la herramienta de línea de comandos para interactuar con Google Cloud. Si necesitas instalar Google Cloud CLI, consulta la Guía de instalación.
- kubectl para ejecutar comandos en clústeres de Kubernetes. Si necesitas instalar kubectl, consulta la guía de instalación.
Si usas Cloud Shell como entorno de shell para interactuar con Google Cloud, estas herramientas están instaladas.
Asegúrate de haber inicializado la CLI de gcloud para usarla en tu proyecto.

A lo largo de esta configuración, es posible que debas consultar la documentación de tu servidor de 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

GKE Identity Service necesita un secreto de cuenta de servicio para autenticarse en el servidor LDAP y recuperar detalles del usuario. Existen dos tipos de cuentas de servicio permitidas en la autenticación LDAP, la autenticación básica (con un nombre de usuario y contraseña para autenticarse en el servidor) o el certificado de cliente (con 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 un proveedor de LDAP para GKE Identity Service.

Para que la información de acceso del servidor LDAP esté disponible para GKE Identity Service, debes crear un recurso Secret de Kubernetes con los detalles de acceso de Configura un proveedor de LDAP para GKE Identity Service.

En los siguientes ejemplos, se muestra cómo configurar Secrets para ambos tipos de cuentas de servicio. 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 autenticación básica de Secret:

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

En él, SERVICE_ACCOUNT_SECRET_NAME es 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, que es nuestro enfoque recomendado. Esto se debe a que, de forma predeterminada, GKE Identity Service tiene permiso para leer Secrets en anthos-identity-service. Si deseas usar otro espacio de nombres, cambia los metadatos en el Secret y, luego, agrega una nueva política de RBAC para otorgar permiso a GKE Identity Service para leer los Secrets en ese espacio de nombres 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

El servicio de identidad de GKE usa un tipo de recurso personalizado (CRD) especial de Kubernetes para configurar los clústeres llamados ClientConfig, con campos de información sobre el proveedor de identidad y los parámetros que necesita para mostrar información del usuario. La configuración de ClientConfig también incluye el nombre y el espacio de nombres del Secret que creaste y aplicaste en la sección anterior, lo que permite que GKE Identity Service se autentique en el servidor de LDAP.

Para aplicar la configuración a tu clúster, edita el objeto predeterminado de KRM del tipo clientconfig en el espacio de nombres kube-public:

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

En él, USER_CLUSTER_KUBECONFIG es la ruta de acceso del 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:

authentication:
  - name: NAME_STRING
    ldap:
      host: HOST_NAME
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      connectionType: CONNECTION_TYPE
      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

En la siguiente tabla, se describen los campos de la CRD de ClientConfig:

Campo	Requeridos	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 a los clústeres con GKE Identity Service.