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 instalarkubectl
, 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.
- La versión más reciente de Google Cloud CLI, que incluye
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.