Cette page s'adresse aux administrateurs de plates-formes.
Cette page explique comment activer l'authentification OIDC (OpenID Connect) sur les clusters d'utilisateur et comment configurer le contrôle des accès basé sur les rôles (RBAC). Pour en savoir plus sur l'authentification avec OIDC, consultez la page Gestion des identités avec OIDC dans les clusters Anthos sur solution Bare Metal.
Activer l'authentification OIDC sur les clusters d'utilisateur
L'authentification OIDC peut être activée lors de la création du cluster d'utilisateur ou sur un cluster d'utilisateur existant. Pour configurer l'authentification OIDC, vous devez disposer des profils d'identité à appliquer au cluster. Consultez la page Créer des profils d'identité.
Définir un ou plusieurs profils d'identité lors de la création du cluster
Consultez la page Créer des clusters d'utilisateur pour savoir comment créer des clusters d'utilisateur avec la console Anthos Management Center. Sur la page Configuration du cluster pour créer un cluster d'utilisateur, sélectionnez les profils d'identité dans la liste déroulante Configurations AIS. Ces profils d'identité seront appliqués au cluster d'utilisateur.
Définir des profils d'identité sur un cluster d'utilisateur existant
Accédez à la page Identité et accès.
Cliquez sur Appliquer des profils aux clusters.
Sélectionnez les profils d'identité à appliquer dans la liste déroulante Profils.
Sélectionnez les clusters auxquels appliquer les profils d'identité dans la liste déroulante Clusters.
Afficher les profils d'identité appliqués au cluster d'utilisateur
Vous pouvez afficher les profils d'identité appliqués au cluster d'utilisateur à partir de la page Identité et accès.
Sélectionnez l'onglet Cluster, recherchez le cluster d'utilisateur à afficher, puis cliquez sur Afficher la configuration pour ce cluster d'utilisateur.
Télécharger le fichier de configuration de connexion du cluster d'utilisateur
Sur la page déroulante Afficher la configuration, cliquez sur Télécharger la configuration de connexion.
Spécifier la configuration OIDC à partir du fichier
Créez un fichier contenant les éléments suivants. Enregistrez ce fichier sous le nom 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 running in
# disconnected 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
Remplacez les éléments suivants :
- CONFIGURATION_NAME : Nom de la configuration OIDC à créer.
- CLIENT_ID : ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID.
- CLIENT_SECRET : code secret de l'application cliente.
- EXTRA_PARAMS : paramètres supplémentaires de clé-valeur (séparés par une virgule) à envoyer au fournisseur OpenID.
- ISSUER_URI : URL à laquelle les requêtes d'autorisation sont envoyées à votre OpenID.
- SCOPES : champs d'application supplémentaires (séparés par une virgule) à envoyer au fournisseur OpenID.
- USER_CLAIM : revendication JWT à utiliser comme nom d'utilisateur. Vous pouvez choisir d'autres revendications, telles que l'e-mail ou le nom, en fonction du fournisseur OpenID. Toutefois, les revendications autres que l'e-mail sont précédées de l'URL de l'émetteur pour éviter les conflits de noms.
- GROUPS_CLAIM : nom de la revendication dans le jeton d'ID OIDC qui contient les informations du groupe de l'utilisateur.
- CERT_AUTHORITY_DATA : certificat facultatif encodé au format PEM encodé en base64 pour le fournisseur OIDC. Supprimez-le si nécessaire. Pour créer la chaîne, encodez le certificat, y compris les en-têtes, en base64. Incluez la chaîne obtenue dans certificateAuthorityData en tant que ligne unique.
Après avoir modifié le fichier avec la configuration souhaitée, exécutez la commande suivante :
kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
--type=merge --patch "$(cat OIDC_CONFIG)"
Remplacez les éléments suivants :
- USER_CLUSTER_KUBECONFIG : chemin d'accès au fichier Kubeconfig du cluster d'utilisateur.
- OIDC_CONFIG : chemin d'accès au fichier de configuration que vous avez créé.
Configurer RBAC sur le cluster d'utilisateur
Cette section donne un exemple de configuration de RBAC pour accorder l'accès à des espaces de noms individuels. Pour plus d'informations, reportez-vous à la documentation de Kubernetes RBAC.
Supposons deux espaces de noms : workload-a
et workload-b
. L'objectif est de rendre les ressources de l'espace de noms workload-a
lisibles et modifiables par l'utilisateur alice@example.com et workload-b
lisibles par l'utilisateur bob@example.com.
alice@example.com ne peut pas accéder à workload-b
et bob@example.com ne peut pas accéder à workload-a
.
Créez les espaces de noms dans le cluster d'utilisateur :
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b
Pour limiter l'accès à chaque espace de noms, vous devez définir l'autorisation d'accès à chacun. Dans Kubernetes, vous pouvez créer un objet "Role".
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
Le verbs
défini pour foo-full-access
détermine toutes les actions que ce rôle est autorisé à effectuer dans l'espace de noms.
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
Pour b-read-access
, les verbes définis autorisent le rôle à uniquement interroger les ressources.
Pour que les utilisateurs obtiennent des autorisations, les objets "RoleBinding" doivent être créés. Les objets "RoleBinding" peuvent inclure des utilisateurs individuels ou des groupes. Cet exemple présente des utilisateurs individuels.
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
L'objet "RoleBinding" ci-dessus (a-full-access-users
) accorde à l'utilisateur alice@example.com les autorisations définies par le rôle a-full-access
. Cela signifie que l'utilisateur alice@example.com est capable de lire et d'écrire dans des ressources de l'espace de noms 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
Cet objet RoleBinding (b-read-access-users
) accorde à l'utilisateur bob@example.com les autorisations définies dans le rôle b-read-access
. Par conséquent, l'utilisateur bob@example.com ne bénéficie que d'un accès en lecture sur les ressources de l'espace de noms workload-b
.
Se connecter avec le fournisseur OIDC
En tant qu'administrateur du cluster d'utilisateur, faites en sorte que tous les utilisateurs du cluster utilisent le fichier de configuration de connexion pour se connecter : Consultez la section Télécharger le fichier de configuration des connexions au cluster d'utilisateur pour obtenir la configuration de connexion à partir du centre de gestion Anthos. Vous pouvez également créer le fichier de configuration de connexion en exécutant la commande suivante :
actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
--output=USER_CLUSTER_NAME-actl-auth-login-config.yaml
Distribuez le fichier USER_CLUSTER_NAME-actl-auth-login-config.yaml
aux utilisateurs du cluster d'utilisateur.
Authentifiez-vous auprès du fournisseur OIDC et suivez les instructions de la ligne de commande :
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"
Remplacez USER_CLUSTER_NAME
par le nom du cluster d'utilisateur, comme indiqué dans la Console d'administration.
--kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig
est le nom du fichier Kubconfig de sortie.
Remplacez CONFIGURATION_NAME
par le nom du profil d'identité avec lequel vous authentifier. Ouvrez USER_CLUSTER_NAME-actl-auth-login-config.yaml
pour afficher les noms de profil.
Utilisez la nouvelle interface Kubeconfig avec kubectl
comme suit :
kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A