Esta página está destinada a los administradores de la plataforma.
En esta página, se describe cómo habilitar la autenticación de OpenID Connect (OIDC) en clústeres de usuario y configurar el control de acceso basado en funciones (RBAC). 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 para obtener instrucciones sobre cómo crear clústeres de usuario con la consola del centro de administración de Anthos. 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
Ve a la página Identidad y acceso.
Haz clic en Aplicar perfiles a clústeres.
Selecciona los perfiles de identidad que deseas aplicar de la lista desplegable Perfiles.
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 private 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 alice@example.com y workload-b puedan leerse por el usuario bob@example.com. alice@example.com no puede acceder a workload-b y bob@example.com 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: prefix-alice@example.com # 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 alice@example.com los permisos definidos en la función a-full-access. Esto significa que el usuario alice@example.com 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: bob@example.com # 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 bob@example.com los permisos definidos en la función b-read-access. Como resultado, el usuario bob@example.com solo puede leer los recursos del espacio de nombres workload-b.
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 del centro de administración 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_NAME-actl-auth-login-config.yaml
Distribuye USER_CLUSTER_NAME-actl-auth-login-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_NAME-actl-auth-login-config.yaml \
--cluster=USER_CLUSTER_NAME --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig \
--preferred-auth="CONFIGURATION_NAME"
Reemplaza USER_CLUSTER_NAME por el nombre del clúster de usuario, como se muestra en la Consola del administrador.
--kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig es el nombre del archivo de salida Kubeconfig.
Reemplaza CONFIGURATION_NAME por el nombre del perfil de identidad con el cual autenticar. Abre USER_CLUSTER_NAME-actl-auth-login-config.yaml para ver los nombres de los perfiles.
Usa la nueva Kubeconfig con kubectl de la siguiente manera:
kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A