Configurer l'identité et la sécurité à l'aide d'OIDC

Cette page est destinée aux opérateurs d'infrastructure.

Cette page explique comment activer l'authentification auprès du centre de gestion Anthos via le choix d'OpenID Connect (fournisseur OIDC). OIDC est une couche d'authentification basée sur OAuth 2.0 qui spécifie une API HTTP RESTful, et utilise JSON comme format de données.

OIDC vous permet d'utiliser votre fournisseur d'identité existant pour gérer l'authentification des utilisateurs et des groupes. OIDC vous permet de gérer l'accès à un cluster en utilisant les procédures standards de votre organisation pour créer, activer et désactiver des comptes.

Avant de commencer

Avant de configurer OIDC, vous avez besoin des éléments suivants :

Nom de domaine utilisé pour accéder au centre de gestion, fourni par l'opérateur d'infrastructure, par exemple : anthos.example.com.
Un fournisseur OIDC tel que Microsoft Active Directory Federation Services (ADFS), Google SSO ou Keycloak. Le cluster et votre navigateur doivent pouvoir se connecter au fournisseur OIDC. Le fournisseur OIDC n'a pas besoin de se reconnecter directement au cluster. Si vous ne possédez pas de fournisseur OIDC, consultez la section S'authentifier avec Keycloak pour en installer un. Keycloak est fourni à des fins de démonstration seulement et n'est pas recommandé pour un environnement de production.

Créer des profils d'identité

Les profils d'identité contiennent la configuration requise pour utiliser un fournisseur d'identité pour l'authentification. Les étapes suivantes permettent de créer un profil d'identité :

Dans la console du centre de gestion, ouvrez le menu Identité et accès.
Dans l'onglet Identité, cliquez sur Configurer Anthos Identity Service (OIDC).
Dans le champ Profile Name (Nom du profil), attribuez un nom convivial au profil. Il s'agit du nom sous lequel le profil est référencé.
Saisissez l'URL du fournisseur OIDC, l'ID client et le code secret du client de votre fournisseur OIDC.
Définissez le champ Revendication de Nom d'utilisateur. La revendication du nom d'utilisateur est la revendication du jeton OIDC qui contient le nom d'utilisateur. Par exemple, si la revendication de nom d'utilisateur est email, les utilisateurs sont identifiés par le champ utilisateur du jeton OIDC.

Lorsque vous définissez cette revendication, assurez-vous qu'elle existe dans les champs d'application demandés.
Définissez le champ Username Prefix (Préfixe de nom d'utilisateur). Le préfixe du nom d'utilisateur permet de distinguer les utilisateurs de différents fournisseurs d'identité. Le préfixe utilisateur doit également être inclus lors de l'attribution d'autorisations RBAC aux utilisateurs.

Par exemple, si la revendication de nom d'utilisateur est email et que le préfixe utilisateur est prefix-, les utilisateurs sont identifiés comme suit : prefix-sally@example.com. L'utilisateur est sally@example.com, et le préfixe prefix- est ajouté en tant que préfixe à l'utilisateur pour distinguer les différents fournisseurs d'identité.

Remarque : Étant donné qu'Anthos en mode déconnecté n'insère pas de séparateur entre le préfixe et le nom d'utilisateur, insérez un séparateur tel que - à la fin du préfixe pour améliorer la lisibilité. Sinon, prefix et sally@example.com sont identifiés comme prefixsally@example.com.
Définissez le champ "Revendication de groupes". Avec Anthos en mode déconnecté, la valeur par défaut est groups. Pour en savoir plus sur la liaison entre groupes et rôles, consultez la section Liaisons de rôles.
Définissez le champ Group Prefix (Préfixe de groupe). Le préfixe de groupe permet de distinguer les groupes de différents fournisseurs d'identité. Vous devez également inclure le préfixe de groupe lors de l'attribution d'autorisations RBAC aux groupes.

Par exemple, si la revendication de groupe est groups et que le préfixe de groupe est groupprefix-, les groupes sont identifiés comme suit : groupprefix-group. Le groupe est group et le préfixe groupprefix- est préfixé sur le groupe. Nous vous recommandons d'insérer un séparateur à la fin du préfixe, comme indiqué dans la section concernant la définition du préfixe de nom d'utilisateur à l'étape 6.
(Facultatif) Définissez le champ Champs d'application si les champs d'application ne sont pas openid email profile.

Les champs d'application sont les identifiants permettant de spécifier les droits d'accès à demander dans le jeton d'ID :
- openid est requis pour OIDC.
- profile inclut les revendications profile par défaut de l'utilisateur.
- email inclut généralement les revendications email et email_verified.
Si le fournisseur OIDC (tel que Google SSO) nécessite des paramètres supplémentaires, définissez le champ Paramètres supplémentaires.

Par exemple, le champ Paramètres supplémentaires peut être défini sur prompt=consent,access_type=offline pour afficher un écran d'autorisation à chaque fois avant de demander une autorisation pour les champs d'application d'accès.
Si la connexion HTTPS vers la page /.well-known/openid-configuration ou la page JWKS de votre fournisseur OIDC est sécurisée par un certificat non approuvé (par exemple, un certificat autosigné), vous devez renseigner le champ du certificat du fournisseur OIDC avec le certificat HTTPS utilisé par votre fournisseur OIDC.
- Encodez le certificat encodé en PEM du fournisseur OIDC dans base64. Pour créer la chaîne, encodez le certificat, y compris les en-têtes, en base64. Incluez la chaîne obtenue en tant que ligne unique.
- Exemple : LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==
- Pour obtenir un exemple de définition de ce champ, consultez la section S'authentifier avec Keycloak.
Cliquez sur Envoyer, puis revenez à l'onglet Identité et accès.
Enregistrez l'URL de rappel auprès du fournisseur OIDC.

Créez des profils d'identité supplémentaires en cliquant sur Ajouter dans l'onglet Profil d'identité.

Appliquer des profils d'identité au cluster d'administrateur

Les profils d'identité doivent être appliqués aux clusters après leur création.

Dans l'onglet Profil d'identité, cliquez sur Appliquer aux clusters.
Cliquez sur l'onglet Cluster d'administrateur. Dans la liste déroulante Profils, sélectionnez le nom du profil créé précédemment. Vous pouvez sélectionner plusieurs profils à appliquer au cluster.
Vérifiez le nom de domaine du profil. Il s'agit du nom de domaine mappé au profil du fournisseur d'identité. Les utilisateurs non authentifiés qui tentent d'accéder à des chemins d'accès au domaine sont invités à se connecter avec ce fournisseur d'identité. Ce nom de domaine est attribué par l'opérateur d'infrastructure.

Si plusieurs profils doivent être appliqués à la fois, un nom de domaine différent doit être attribué à chaque profil.

Pour en savoir plus sur la configuration d'un nom de domaine, consultez la section Configurer le nom de domaine pour accéder au Centre de gestion.
Saisissez un nom d'utilisateur initial auquel les droits d'accès administrateur de la plate-forme sont accordés (par exemple, alice@exemple.com,bob@exemple.com). Le nom d'utilisateur doit être précédé du préfixe utilisateur défini dans le profil. Par exemple, si le préfixe est prefix-, le nom d'utilisateur dans le champ Administrateur de la plate-forme initial doit ressembler à prefix-alice@example.com. Pour en savoir plus sur les administrateurs de plates-formes et l'autorisation, consultez la section Rôles d'autorisation.
Appliquez les paramètres et attendez quelques minutes que les configurations s'appliquent et que les services redémarrent.

Vous pouvez désormais accéder au centre de gestion avec votre nom de domaine. Si vous n'êtes pas connecté, vous êtes redirigé vers votre fournisseur OIDC pour vous connecter.

Configurer OIDC via l'API

Au lieu de configurer OIDC via le centre de gestion, vous pouvez également le faire via l'API. Pour configurer l'authentification OIDC, vous devez configurer l'objet ClientConfig CRD de votre cluster d'administrateur avec les détails d'authentification. Pour ce faire, créez un fichier contenant le contenu suivant (par exemple, admin-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

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=ADMIN_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

Remplacez les éléments suivants :

ADMIN_KUBECONFIG : chemin d'accès au fichier Kubeconfig du cluster d'administrateur.
OIDC_CONFIG : chemin d'accès au fichier de configuration que vous avez créé.

Les utilisateurs peuvent télécharger admin-actl-auth-login-config.yaml à partir de la page Identité et accès après la configuration d'OIDC.

Sur la page "Identité et accès", cliquez sur l'onglet Identité, puis sur l'onglet Cluster.
Recherchez le cluster nommé admin, puis cliquez sur Afficher les détails de la configuration.
Cliquez sur Télécharger la configuration de connexion pour télécharger la configuration qui est utilisée pour vous connecter avec l'identité du serveur d'API Kubernetes du cluster d'administrateur.

Important : Après avoir configuré OIDC, ${ADMIN_KUBECONFIG} ne doit être utilisé que dans les scénarios d'urgence. Demandez à tous les utilisateurs, y compris aux administrateurs, de se connecter à leur propre compte pour effectuer des opérations permettant de conserver les journaux d'audit avec les noms d'utilisateur, car ${ADMIN_KUBECONFIG} authentifie les utilisateurs en tant que cluster-admin anonymes dans le cluster d'administrateur.
Le fichier de sortie admin-actl-auth-login-config.yaml contient la configuration nécessaire aux utilisateurs pour s'authentifier avec le cluster d'administrateur. Partagez admin-actl-auth-login-config.yaml avec des utilisateurs de confiance qui ont besoin d'accéder au cluster.
Après avoir acquis admin-actl-auth-login-config.yaml, les utilisateurs peuvent se connecter à l'aide de la commande actl auth login. Lorsque les utilisateurs parviennent à se connecter par le biais d'un navigateur, un fichier kubeconfig est généré. Les utilisateurs peuvent utiliser ce nouveau fichier pour accéder au cluster en utilisant leurs identifiants centralisés :
```
# Where to store the new kubeconfig
export ADMIN_OIDC_KUBECONFIG=$(pwd)/admin-oidc-kubeconfig

actl auth login --login-config=admin-actl-auth-login-config.yaml --cluster=admin \
  --kubeconfig=${ADMIN_OIDC_KUBECONFIG} \
  --preferred-auth="CONFIGURATION_NAME"
```
Remplacez CONFIGURATION_NAME par le nom du profil d'identité avec lequel vous authentifier.
Les utilisateurs peuvent désormais utiliser ${ADMIN_OIDC_KUBECONFIG} pour accéder aux ressources du cluster d'administrateur, par exemple :
```
kubectl get pods -n anthos-management-center --kubeconfig=${ADMIN_OIDC_KUBECONFIG}
```
Important : Ne partagez pas ADMIN_OIDC_KUBECONFIG avec n'importe qui, car il contient des identifiants.
${ADMIN_OIDC_KUBECONFIG} peut également être utilisé pour authentifier les commandes CLI actl, par exemple :
```
actl platform management-center describe --kubeconfig=${ADMIN_OIDC_KUBECONFIG}
```

Réinitialiser la configuration de l'authentification

Si un administrateur de plate-forme perd l'accès au centre de gestion en raison d'une erreur dans les paramètres d'authentification, exécutez la commande suivante ci-dessous pour réinitialiser l'authentification OIDC à la configuration d'origine et obtenir la nouvelle URL d'accès au centre de gestion.

actl auth reset --kubeconfig=ADMIN_KUBECONFIG

# Get the new access URL to management center.
actl platform management-center describe --kubeconfig=ADMIN_KUBECONFIG

Étapes suivantes

Apprenez à configurer des rôles d'autorisation.