Configurar la identidad y la seguridad

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En esta página, se describe cómo habilitar la autenticación de OpenID Connect (OIDC) en clústeres de usuario, cómo configurar el control de acceso basado en funciones (RBAC) y cómo usar el inicio de sesión único (SSO) de Google para la autenticación. Para obtener más información sobre la autenticación con OIDC, consulta Administración de identidades con OIDC en clústeres de Anthos en equipos físicos.

Habilita la autenticación de OIDC en clústeres de usuarios

La autenticación de OIDC se puede habilitar durante la creación del clúster de usuario o en un clúster de usuario existente. La condición previa para configurar la autenticación de OIDC es que los perfiles de identidad que se aplicarán al clúster ya existan. Consulta Crea perfiles de identidad.

Configura perfiles de identidad durante la creación del clúster

Consulta Crea clústeres de usuario a través de la IU del Centro de administración para obtener instrucciones sobre cómo crear clústeres de usuario. En la página de configuración del clúster para crear un clúster de usuario, selecciona los perfiles de identidad de la lista desplegable Configuración de AIS. Estos perfiles de identidad se aplicarán al clúster de usuario.

Configura perfiles de identidad en un clúster de usuario existente

1. Ve a la página Identidad y acceso.

   

2. Haz clic en Aplicar perfiles a clústeres.

   

3. Selecciona los perfiles de identidad que deseas aplicar de la lista desplegable Perfiles.

4. Selecciona los clústeres a los que deseas aplicar los perfiles de identidad de la lista desplegable Clústeres.

Visualiza los perfiles de identidad aplicados al clúster de usuario

Los perfiles de identidad que se aplican al clúster de usuario se pueden ver en la página Identidad y acceso.

Selecciona la pestaña Clúster, busca el clúster de usuario que deseas ver y haz clic en Ver detalles de configuración para ese clúster de usuario.

Descarga el archivo de configuración de acceso del clúster de usuario

En la página desplegable Ver detalles de la configuración, haz clic en Descargar configuración de acceso.

Especifica la configuración de OIDC del archivo

Crea un archivo que contenga lo siguiente: Guarda este archivo como user-cluster-oidc-config.yaml:

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos isolated mode, so
      # a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

Reemplaza lo siguiente:

• CONFIGURATION_NAME: El nombre de la configuración de OIDC que deseas crear.
• CLIENT_ID: Es el ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de OpenID.
• CLIENT_SECRET: El secreto de la aplicación cliente.
• EXTRA_PARAMS: Parámetros de clave-valor adicionales (separados por comas) que se enviarán al proveedor de OpenID.
• ISSUER_URI: La URL a la que se envían las solicitudes de autorización para tu OpenID.
• SCOPES: Son permisos adicionales (separados por comas) que se envían al proveedor de OpenID.
• USER_CLAIM: Es la reclamación de JWT que se debe usar como nombre de usuario. Puedes elegir otras reclamaciones, como el correo electrónico o el nombre, según el proveedor de OpenID. Sin embargo, las reclamaciones que no sean de correo electrónico tienen el prefijo de la URL de la entidad emisora para evitar conflictos de nombres.
• GROUPS_CLAIM: Es el nombre de la reclamación en el token de ID de OIDC que contiene la información del grupo del usuario.
• CERT_AUTHORITY_DATA: Es el certificado opcional con codificación PEM codificada en base64 para el proveedor de OIDC. Si no es necesario, quítalo. Para crear la string, codifica el certificado, incluidos los encabezados, en base64. Incluye la string resultante en certificateAuthorityData como una sola línea.

Después de editar el archivo con la configuración deseada, ejecuta el siguiente comando:

kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

Reemplaza lo siguiente:

• USER_CLUSTER_KUBECONFIG: Ruta de acceso al archivo Kubeconfig del clúster de usuario.
• OIDC_CONFIG: Ruta de acceso al archivo de configuración que creaste.

Configura el RBAC en el clúster de usuarios

En esta sección, se muestra un ejemplo de cómo configurar RBAC para otorgar acceso a espacios de nombres individuales. Para obtener información más detallada, consulta la documentación de RBAC de Kubernetes.

Supongamos que hay dos espacios de nombres, workload-a y workload-b. El objetivo es hacer que los recursos en el espacio de nombres workload-a puedan leerse y escribirse por el usuario [e-mail] y workload-b puedan leerse por el usuario [e-mail]. [e-mail] no puede acceder a workload-b y [e-mail] no puede acceder a workload-a.

Crea los espacios de nombres en el clúster del usuario:

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

Para limitar el acceso a cada espacio de nombres, se debe definir el permiso de cada espacio de nombres. En Kubernetes, esto se puede hacer mediante la creación de una función.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

Los verbs definidos para foo-full-access definen todas las acciones que esta función puede realizar en el espacio de nombres.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

Para b-read-access, los verbos definidos solo permiten que la función consulte los recursos.

Para que los usuarios obtengan permisos, se deben crear RoleBindings. Las RoleBinding pueden incluir usuarios individuales y grupos. En este ejemplo, se muestran usuarios individuales.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: [e-mail] # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

La RoleBinding anterior (a-full-access-users) otorga al usuario [e-mail] los permisos definidos en la función a-full-access. Esto significa que el usuario [e-mail] puede leer y escribir los recursos en el espacio de nombres workload-a.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: [e-mail] # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

Esta RoleBinding (b-read-access-users) otorga al usuario [e-mail] los permisos definidos en la función b-read-access. Como resultado, el usuario [e-mail] solo puede leer los recursos del espacio de nombres workload-b.

Nota: En producción, recomendamos que vincules funciones a grupos en lugar de usuarios individuales. Consulta a tu proveedor de OIDC sobre cómo exponer grupos.

Accede con el proveedor de OIDC

Como administrador del clúster de usuarios, obtén el archivo de configuración de acceso que usarán todos los usuarios del clúster de usuarios para acceder. Consulta Descarga el archivo de configuración de acceso del clúster de usuario para obtener la configuración de acceso de la IU del Centro de administración del modo privado de Anthos. Como alternativa, puedes ejecutar el siguiente comando para crear el archivo de configuración de acceso:

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=user-cluster-anthos-config.yaml

Distribuye user-cluster-anthos-config.yaml a los usuarios del clúster de usuarios.

Autentica con el proveedor de OIDC y sigue las instrucciones en la línea de comandos:

actl auth login --login-config=user-cluster-anthos-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./user-cluster-oidc-kubeconfig

Reemplaza USER_CLUSTER_NAME por el nombre del clúster de usuario, como se muestra en la Consola del administrador. --kubeconfig=user-cluster-oidc-kubeconfig es el nombre del archivo de salida Kubeconfig.

Advertencia: El resultado de Kubeconfig (user-cluster-oidc-kubeconfig anterior) contiene las credenciales del usuario y no debe compartirse.

Usa la nueva Kubeconfig con kubectl de la siguiente manera:

kubectl --kubeconfig=./user-cluster-oidc-kubeconfig get pods -A

Autentica con el SSO de Google

Ten en cuenta que el SSO de Google no está disponible cuando se usa el modo aislado y que esta sección es solo para una demostración. Si quieres usar el SSO de Google, tanto el clúster como los navegadores deben poder comunicarse con los servidores de SSO de Google. Los servidores de SSO de Google no necesitan comunicarse con los clústeres de usuarios.

1. Accede a Google Cloud Console y selecciona un proyecto válido.
2. Accede a la sección “API y servicios > Pantalla de consentimiento de OAuth”
3. Crea una nueva pantalla de consentimiento de OAuth. Por lo general, esta información se muestra a los usuarios.
   1. Establece la página principal de la aplicación en la URL del administrador.
4. En la sección API y Servicios > Credenciales, haz lo siguiente:
   1. Haz clic en Crear credenciales.
   2. Crea un ID de cliente de OAuth nuevo.
   3. Configura el tipo de aplicación como aplicación web.
   4. Elige un nombre relevante
   5. Para los orígenes de JavaScript, configura https://anthos.example.com (que indica que https://anthos.example.com es el nombre de tu dominio para el Centro de administración)
   6. Para los URI de redireccionamiento autorizados, configura lo siguiente:
      • https://anthos.example.com/_gcp_anthos_oidc_callback
      • http://localhost:9879/callback
5. Copia el ClientID y el secreto del cliente en la configuración de AdminUI
6. Establece la URL del proveedor de OIDC en https://accounts.google.com
7. Establece Username Claim en email y Scopes en openid email.
8. Establece parámetros adicionales en prompt=consent,access_type=offline. De lo contrario, no podrás acceder con el servidor de la API de Kubernetes.
9. Agrega una lista inicial de correos electrónicos de usuarios (separados por comas) para que se te otorguen permisos de administrador de la plataforma.
10. Haga clic en Save.

Registros de auditoría

La auditoría de Kubernetes está habilitada para el modo privado de Anthos, lo que proporciona el enfoque a fin de verificar el acceso y las acciones administrativas en la plataforma.

Actualmente, el registro de auditoría no se puede personalizar para parámetros como el tiempo de retención, la frecuencia de actualización o el tamaño del fragmento. El nivel de auditoría es Metadata, que registra metadatos de la solicitud (usuario solicitante, marca de tiempo, recurso, verbo), pero no el cuerpo de la solicitud o respuesta.

Nota: Se exportan los registros de auditoría de k8s del clúster de administrador y de usuario.

El registro de auditoría está habilitado en el modo privado de Anthos de forma predeterminada. Consulta Registro y supervisión para obtener pasos detallados sobre cómo acceder a los registros de auditoría.

Nota: Por el momento, esta no es una ubicación segura para almacenar registros de auditoría. Las personas con los permisos k8s suficientes (p. ej., IO) pueden borrar o manipular registros de auditoría.