Configurar GKE Identity Service con LDAP

Este documento está dirigido a administradores de clústeres u operadores de aplicaciones que configuran GKE Identity Service en sus clústeres. En él se explica cómo configurar GKE Identity Service en tus clústeres con tu proveedor de protocolo ligero de acceso a directorios (LDAP) preferido, incluido Microsoft Active Directory. Se da por hecho que tú o el administrador de tu plataforma ya tenéis los detalles de inicio de sesión de vuestro proveedor de LDAP siguiendo las instrucciones de Configurar un proveedor de LDAP para GKE Identity Service. Para obtener más información sobre cómo funciona el servicio de identidad de GKE y otras opciones de configuración, consulta la descripción general. Para saber cómo acceder a un clúster con este servicio como desarrollador u otro usuario del clúster, consulta Acceder a clústeres con GKE Identity Service. GKE Identity Service con LDAP se puede usar con implementaciones de Google Distributed Cloud en VMware (clústeres de usuarios) y en bare metal únicamente.

Antes de empezar

1. Asegúrate de que tienes instaladas las siguientes herramientas de línea de comandos:
   • La versión más reciente de la CLI de Google Cloud, 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 ya están instaladas.
2. Asegúrate de haber inicializado gcloud CLI para usarlo con tu proyecto.

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:

• OpenLDAP
• Azure AD
• Microsoft Active Directory
• LDAP de Google

Rellenar 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 obtener los detalles del usuario. Hay dos tipos de cuentas de servicio permitidas en la autenticación LDAP: la autenticación básica (que usa un nombre de usuario y una contraseña para autenticarse en el servidor) o el certificado de cliente (que usa una clave privada 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 para configurar un proveedor LDAP para GKE Identity Service. Para que GKE Identity Service pueda acceder a la información de inicio de sesión del servidor LDAP, debes crear un recurso Secret de Kubernetes con los detalles de inicio de sesión de Configurar un proveedor LDAP para GKE Identity Service. En los siguientes ejemplos se muestra cómo configurar secretos para ambos tipos de cuentas de servicio. 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 hayas elegido para este secreto. Sustituye los valores de certificado y clave de TLS por los valores codificados que has obtenido en el paso anterior.

En los ejemplos se muestra el secreto aplicado al espacio de nombres anthos-identity-service, que es el método que recomendamos. Esto se debe a que, de forma predeterminada, GKE Identity Service tiene permiso para leer secretos en anthos-identity-service. Si quieres usar otro espacio de nombres, cambia los metadatos del secreto y, a continuación, añade una nueva política RBAC para conceder a GKE Identity Service permiso para leer secretos en ese espacio de nombres, tal 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

GKE Identity Service usa un tipo especial de recurso personalizado de Kubernetes (CRD) para configurar tus clústeres llamado ClientConfig, con campos para información sobre el proveedor de identidades y los parámetros que necesita para devolver información del usuario. La configuración de ClientConfig también incluye el nombre secreto y el espacio de nombres del secreto que has creado y aplicado en la sección anterior, lo que permite que GKE Identity Service se autentique en el servidor LDAP.

Para aplicar la configuración a tu clúster, edita el objeto predeterminado de KRM de tipo 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_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

Nota: GKE Identity Service te permite configurar varios proveedores de identidades OIDC, LDAP y SAML en un solo ClientConfig recurso personalizado (CRD) para la autenticación de clientes. GKE Identity Service intenta autenticarse con cada CRD en el orden en que se definen y se detiene después de la primera autenticación correcta.

Puedes configurar varios proveedores de identidades en tu ClientConfig según tus requisitos. De esta forma, se simplifica la gestión y se ofrece flexibilidad, ya que puedes configurar diversos métodos de autenticación en un recurso de configuración unificado. En el siguiente ejemplo ClientConfig se definen varios proveedores de identidad en el orden de precedencia de autenticación requerido.

  apiVersion: v1
  items:
  - apiVersion: authentication.gke.io/v2alpha1
    kind: ClientConfig
  ...
    spec:
      authentication:
      - aws:
          region: us-west-2
        name: AWS Login
      - ldap:
      ...
      - saml:
        ...
      - azureAD:
        ...
      - oidc:
        name: Okta OIDC
        ...
      -oidc:
        name: Google OIDC
        ...

En la siguiente tabla se describen los campos del CRD ClientConfig:

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 puerto 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 de 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. 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 control de acceso basado en roles (RBAC) reales del usuario se escribirán como [e-mail]. 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, continúa con la configuración del acceso de los usuarios a los clústeres con GKE Identity Service.