Découvrez comment configurer GKE pour utiliser un système OpenID Connect (OIDC) pour l'authentification auprès des clusters d'utilisateurs. Cet article explique comment configurer GKE sur AWS avec n'importe quel fournisseur OpenID.
Pour mettre à niveau un cluster qui utilise l'authentification OIDC vers Kubernetes 1.21, consultez la page Mettre à niveau vers la version 1.21.
Pour en savoir plus sur le flux d'authentification GKE sur AWS, consultez la page Authentification.
Présentation
GKE sur AWS est compatible avec OIDC en tant que mécanisme d'authentification pour interagir avec le serveur d'API Kubernetes d'un cluster d'utilisateur. OIDC vous permet de gérer l'accès aux clusters Kubernetes en utilisant les procédures standards de votre organisation pour créer, activer et désactiver des comptes utilisateur.
Avant de commencer
Dans cet article, nous partons du principe que vous connaissez les concepts d'authentification et les concepts OpenID suivants :
Google Cloud CLI doit être installé sur l'ordinateur local de chaque développeur.
Les systèmes sans interface graphique ne sont pas compatibles. Pour vous authentifier, vous devez ouvrir un navigateur sur l'ordinateur local exécutant gcloud CLI. Le navigateur vous invite ensuite à autoriser votre compte utilisateur.
Pour vous authentifier via Google Cloud Console, chaque cluster que vous souhaitez configurer pour l'authentification OIDC doit être enregistré auprès de Google Cloud.
Personas
Cette rubrique fait référence à trois personas :
Administrateur de l'organisation : cette personne choisit un fournisseur OpenID et enregistre les applications clientes auprès du fournisseur.
Administrateur de cluster : cette personne crée un ou plusieurs clusters d'utilisateur et crée des fichiers de configuration d'authentification pour les développeurs qui utilisent les clusters.
Développeur : cette personne exécute des charges de travail sur un ou plusieurs clusters et s'authentifie à l'aide d'OIDC.
Choisir un fournisseur OpenID
Cette section est destinée aux administrateurs de l'organisation.
Vous pouvez utiliser n'importe quel fournisseur OpenID de votre choix. Pour obtenir la liste des fournisseurs certifiés, consultez la page Certification OpenID.
Créer des URL de redirection
Cette section est destinée aux administrateurs de l'organisation.
Le fournisseur OpenID utilise des URL de redirection pour renvoyer des jetons d'ID. Vous devez créer des URL de redirection pour gcloud CLI et la console Google Cloud.
Définir l'URL de redirection de la CLI gcloud
Lorsque vous configurez votre fournisseur OpenID, spécifiez l'URL de redirection CLI comme suit : http://localhost:PORT/callback
.
Remplacez PORT par votre numéro de port supérieur à 1024.
Définir l'URL de redirection de la console Google Cloud
L'URL de redirection de la console Google Cloud est la suivante :
https://console.cloud.google.com/kubernetes/oidc
Lorsque vous configurez votre fournisseur OIDC, spécifiez https://console.cloud.google.com/kubernetes/oidc
comme l'une de vos URL de redirection.
Enregistrer vos applications clientes auprès du fournisseur OpenID
Cette section est destinée aux administrateurs de l'organisation.
Pour que vos développeurs puissent utiliser Google Cloud CLI ou la console Google Cloud avec votre fournisseur OpenID, vous devez enregistrer ces deux clients auprès du fournisseur OpenID. L'enregistrement comprend les étapes suivantes :
Découvrez l'URI d'émetteur de votre fournisseur. La console Google Cloud ou gcloud CLI envoie des requêtes d'authentification à cet URI.
Configurez votre fournisseur avec l'URL de redirection, y compris votre numéro de port, pour gcloud CLI.
Configurez votre fournisseur avec l'URL de redirection pour la console Google Cloud,
https://console.cloud.google.com/kubernetes/oidc
.Créez un seul ID client que votre fournisseur utilise pour identifier à la fois Google Cloud CLI et la console Google Cloud.
Créez un code secret client unique que gcloud CLI et la console Google Cloud utilisent pour s'authentifier auprès du fournisseur OpenID.
Créez un champ d'application personnalisé que gcloud CLI ou la console Google Cloud peut utiliser pour demander les groupes de sécurité de l'utilisateur.
Créez un nom de revendication personnalisé que le fournisseur utilisera pour renvoyer les groupes de sécurité de l'utilisateur.
Configurer le cluster
Cette section s'adresse aux administrateurs de cluster.
Pour configurer l'authentification OIDC, vous devez configurer la ressource AWSCluster de votre cluster d'utilisateur avec les détails d'authentification d'un cluster. Les détails d'AWSCluster permettent de configurer OIDC pour la console Google Cloud et le plug-in d'authentification pour GKE Enterprise. La configuration inclut les informations OIDC suivantes :
authentication: awsIAM: adminIdentityARNs: - AWS_IAM_ARN oidc: - certificateAuthorityData: CERTIFICATE_STRING clientID: CLIENT_ID clientSecret: CLIENT_SECRET extraParams: EXTRA_PARAMS groupsClaim: GROUPS_CLAIM groupPrefix: GROUP_PREFIX issuerURI: ISSUER_URI kubectlRedirectURI: KUBECTL_REDIRECT_URI scopes: SCOPES userClaim: USER_CLAIM userPrefix: USER_PREFIX
Champs d'authentification
Le tableau suivant décrit les champs de l'objet authentication.awsIAM.adminIdentityARNs
.
Champ | Obligatoire | Description | Format |
---|---|---|---|
adminIdentityARNs | Oui, si vous configurez OIDC. | Amazon Resource Name (ARN) des identités AWS IAM (utilisateurs ou rôles) ayant reçu l'accès administrateur au cluster par GKE sur AWS.
Exemple : arn:aws:iam::123456789012:group/Developers |
Chaîne |
Champ | Obligatoire | Description | Format |
---|---|---|---|
certificateAuthorityData | Non | Certificat encodé au format PEM encodé en base64 pour le fournisseur OIDC. 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. Exemple : certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT== |
Chaîne |
clientID | Oui | ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID. | Chaîne |
clientSecret | Non | Clé secrète partagée entre l'application cliente OIDC et le fournisseur OIDC. | Chaîne |
extraParams | Non |
Paramètres de clé-valeur supplémentaires à envoyer au fournisseur OpenID. Si vous autorisez un groupe, transmettez resource=token-groups-claim .
Si votre serveur d'autorisation vous demande l'autorisation, pour l'authentification avec Microsoft Azure et Okta, définissez |
Liste d'éléments séparés par une virgule |
groupsClaim | Non | Revendication JWT que le fournisseur utilise pour renvoyer vos groupes de sécurité. | Chaîne |
groupPrefix | Non | Préfixe ajouté aux revendications de groupe pour éviter les conflits avec les noms existants.
Par exemple, si vous avez deux groupes nommés foobar , ajoutez le préfixe gid- ; le groupe de résultats est gid-foobar . |
Chaîne |
issuerURI | Oui | URL où les requêtes d'autorisation sont envoyées à votre OpenID, telle que https://example.com/adfs . Le serveur de l'API Kubernetes utilise cette URL pour découvrir les clés publiques permettant de valider les jetons. L'URI doit utiliser le protocole HTTPS. |
Chaîne d'URL |
kubectlRedirectURI | Oui | L'URL de redirection que "kubectl" utilise pour l'autorisation. | Chaîne d'URL |
scopes | Oui | Niveaux d'accès supplémentaires à envoyer au fournisseur OpenID. Microsoft Azure et Okta nécessitent le niveau d'accès offline_access . |
Liste d'éléments séparés par une virgule |
userClaim | Non | 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. | Chaîne |
userPrefix | Non | Préfixe ajouté aux revendications de nom d'utilisateur pour éviter les conflits avec les noms existants. | Chaîne |
Exemple : autoriser des utilisateurs et des groupes
De nombreux fournisseurs codent les propriétés d'identification des utilisateurs, telles que les e-mails et les ID utilisateur, dans un jeton. Cependant, ces propriétés présentent des risques implicites pour les stratégies d'authentification :
- Les ID utilisateur peuvent compliquer la lecture et l'audit des stratégies.
- L'utilisation d'adresses e-mail peut créer à la fois un risque de disponibilité (si un utilisateur modifie son adresse e-mail principale) et un risque de sécurité (si un e-mail peut être réattribué).
Au lieu d'attribuer des ID utilisateur, nous recommandons des stratégies de groupe, qui peuvent être persistantes et plus faciles à contrôler.
Supposons que votre fournisseur crée des jetons d'identité qui incluent les champs suivants :
{ 'iss': 'https://server.example.com' 'sub': 'u98523-4509823' 'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp'] ... }
Avec ce format de jeton, vous devez remplir la spécification oidc
de votre fichier de configuration comme suit :
issuerURL: 'https://server.example.com' username: 'sub' usernamePrefix: 'uid-' group: 'groupList' groupPrefix: 'gid-' extraParams: 'resource=token-groups-claim' ...
Après avoir créé le cluster d'utilisateur, vous devez utiliser le contrôle d'accès basé sur les rôles Kubernetes (RBAC) pour accorder un accès privilégié aux utilisateurs authentifiés.
Dans l'exemple suivant, vous allez créer un objet ClusterRole
qui accorde à ses utilisateurs un accès en lecture seule aux secrets du cluster et qui créée une ressource ClusterRoleBinding
pour lier le rôle au groupe authentifié.
Définissez un
ClusterRole
. Copiez le fichier YAML suivant dans un fichier nommésecret-reader-role.yaml
.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-reader rules: - apiGroups: [""] # The resource type for which access is granted resources: ["secrets"] # The permissions granted by the ClusterRole verbs: ["get", "watch", "list"]
Définissez un élément
ClusterRoleBinding
. Copiez le fichier YAML suivant dans un fichier nommésecret-reader-admins.yaml
.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-secrets-admins subjects: # Allows anyone in the "us-east1-cluster-admins" group to # read Secrets in any namespace within this cluster. - kind: Group name: gid-us-east1-cluster-admins # Name is case sensitive apiGroup: rbac.authorization.k8s.io # Allows this specific user to read Secrets in any # namespace within this cluster - kind: User name: uid-u98523-4509823 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
Appliquez
secret-reader-role.yaml
etsecret-reader-admins.yaml
à votre cluster aveckubectl
.env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f secret-reader-role.yaml && \ kubectl apply -f secret-reader-admins.yaml
Les utilisateurs autorisés à accéder dans
read-secrets-admins
peuvent désormais lire les secrets de votre cluster.
Créer une configuration de connexion
Cette section s'adresse aux administrateurs de cluster.
Après avoir créé un cluster d'utilisateur, vous devez générer un fichier de configuration pour le cluster à l'aide de gcloud anthos create-login-config
.
À partir de votre répertoire
anthos-aws
, utilisezanthos-gke
pour basculer vers le contexte de votre cluster d'utilisateur.cd anthos-aws env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Remplacez CLUSTER_NAME par le nom de votre cluster d'utilisateur.Créez la configuration à l'aide de la commande
gcloud anthos
.gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
Remplacez usercluster-kubeconfig par le chemin d'accès au fichier
kubeconfig
de votre cluster d'utilisateur. Sous Linux et macOS, ce fichier est par défaut situé à l'adresse~/.kube/config
.
Cette commande génère un fichier (kubectl-anthos-config.yaml
) contenant les informations de configuration que vos développeurs utiliseront pour s'authentifier auprès du cluster à l'aide de gcloud CLI. Vous ne devez pas modifier ce fichier.
Pour en savoir plus sur le contenu de kubectl-anthos-config.yaml
, consultez l'annexe.
Distribuer la configuration de connexion
Distribuez le fichier de configuration aux utilisateurs devant s'authentifier auprès de vos clusters d'utilisateur. Vous pouvez distribuer la configuration en :
- plaçant le fichier dans le répertoire par défaut ;
- distribuant le fichier de façon sécurisée ;
- hébergeant le fichier sur un serveur HTTPS.
Répertoires de configuration de connexion par défaut
Les emplacements par défaut pour le stockage du fichier de configuration pour chaque système d'exploitation sont les suivants :
- Linux
$HOME/.config/google/anthos/kubectl-anthos-config.yaml
, où$HOME
est le répertoire d'accueil de l'utilisateur.- macOS
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
, où$HOME
est le répertoire d'accueil de l'utilisateur.- Windows
%APPDATA%/google/anthos/kubectl-anthos-config.yaml
, où%APPDATA%
est le répertoire de données de l'application de l'utilisateur.
Une fois la configuration de connexion distribuée, vos développeurs peuvent configurer gcloud CLI pour accéder au cluster.
Modifier le cluster après la mise à niveau vers Kubernetes 1.21
Après avoir mis à niveau votre cluster vers Kubernetes 1.21, vous devez configurer GKE Identity Service et supprimer vos informations OIDC de la configuration de votre cluster. Pour mettre à jour la configuration, procédez comme suit :
Suivez la procédure décrite dans la section Mettre à niveau votre cluster.
À partir de votre répertoire
anthos-aws
, utilisezanthos-gke
pour basculer vers le contexte de votre cluster d'utilisateur.cd anthos-aws env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Remplacez CLUSTER_NAME par le nom de votre cluster d'utilisateur.Dans un éditeur de texte, ouvrez le fichier manifeste contenant la ressource AWSCluster. Gardez le fichier ouvert et utilisez les valeurs de l'objet
oidc
pour suivre les étapes décrites dans la section Configurer des clusters pour GKE Identity Service.À partir de votre répertoire
anthos-aws
, utilisezanthos-gke
pour basculer vers le contexte de votre service de gestion.cd anthos-aws anthos-gke aws management get-credentials
Dans un éditeur de texte, ouvrez le fichier YAML dans lequel vous avez créé votre AWSCluster. Si vous ne disposez pas de votre fichier YAML initial, vous pouvez utiliser
kubectl edit
.Modifier le fichier YAML
Si vous avez suivi les instructions de la section Créer un cluster d'utilisateur, votre fichier YAML s'appelle
cluster-0.yaml
. Ouvrez ce fichier dans un éditeur de texte.Utiliser kubectl edit
Pour modifier votre AWSCluster à l'aide de
kubectl edit
, exécutez la commande suivante :env HTTPS_PROXY=http://localhost:8118 \ kubectl edit awscluster cluster-name
Remplacez cluster-name par votre AWSCluster. Par exemple, pour modifier le cluster par défaut,
cluster-0
, exécutez la commande suivante :env HTTPS_PROXY=http://localhost:8118 \ kubectl edit awscluster cluster-0
Supprimez l'objet
oidc
du fichier manifeste de votre cluster.Enregistrez le fichier. Si vous utilisez
kubectl edit
,kubectl
applique automatiquement les modifications. Si vous modifiez le fichier YAML, appliquez-le à votre service de gestion à l'aide de la commande suivante :env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f cluster-0.yaml
Le service de gestion met ensuite à jour l'AWSCluster.
Configurer gcloud pour accéder à votre cluster
Cette section est destinée aux développeurs ou aux administrateurs de cluster.
Prérequis
Pour terminer cette section, vous devez disposer des éléments suivants :
- Une configuration de connexion.
Une version mise à jour de gcloud CLI avec les composants
anthos-auth
.gcloud components update gcloud components install anthos-auth
Vérifiez que la CLI gcloud a bien été installée en exécutant la commande suivante, qui devrait fournir des détails sur les arguments requis et les options disponibles.
gcloud anthos auth
S'authentifier auprès de votre cluster
Vous pouvez vous authentifier auprès de votre cluster des manières suivantes :
- Avec gcloud CLI sur votre ordinateur local
- Avec gcloud CLI sur une machine distante à l'aide d'un tunnel SSH
Avec Connect sur Google Cloud Console.
gcloud local
Utilisez gcloud anthos auth login
pour vous authentifier auprès de votre cluster avec votre configuration de connexion.
Si vous avez placé la configuration de connexion à l'emplacement par défaut et que le nom du cluster est configuré, vous pouvez utiliser gcloud anthos auth login
sans option. Vous pouvez également configurer le cluster, l'utilisateur et d'autres informations d'authentification avec des paramètres facultatifs.
Par défaut
gcloud anthos auth login --cluster CLUSTER_NAME
Remplacez CLUSTER_NAME par un nom de cluster complet. Par exemple, projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a
.
Paramètres facultatifs
gcloud anthos auth login
accepte les paramètres facultatifs suivants :
gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run
Les paramètres sont décrits dans le tableau suivant.
Paramètre | Description |
---|---|
cluster | Nom du cluster sur lequel s'authentifier. Correspond par défaut au cluster dans "kubectl-anthos-config.yaml". |
user | Nom d'utilisateur pour les identifiants dans kubeconfig . La valeur par défaut est {cluster-name}-anthos-default-user . |
login-config | Soit le chemin d'accès au fichier de configuration généré par l'administrateur du cluster pour le développeur, soit une URL hébergeant le fichier. La valeur par défaut est kubectl-anthos-config.yaml . |
login-config-cert | Si vous utilisez une URL pour login-config, le chemin d'accès au fichier de certificat CA pour les connexions HTTPS. |
kubeconfig | Chemin d'accès au fichier kubeconfig contenant des jetons. La valeur par défaut est $HOME/.kube/config` . |
simulation | Testez vos options de ligne de commande sans modifier votre configuration ou votre cluster. |
La commande gcloud anthos login
lance un navigateur qui demande à l'utilisateur de se connecter avec ses identifiants d'entreprise, effectue un échange d'identifiants OIDC et obtient les jetons appropriés. gcloud CLI écrit ensuite les jetons dans un fichier kubeconfig
. kubectl
utilise ce fichier pour s'authentifier auprès du cluster d'utilisateur.
Pour vérifier que l'authentification a abouti, exécutez une commande kubectl
avec votre fichier kubeconfig
:
env HTTPS_PROXY=http://localhost:8118 \
kubectl get nodes --kubeconfig my.kubeconfig
Tunnel gcloud
Si vous souhaitez vous authentifier auprès d'un cluster d'utilisateur depuis un ordinateur distant, vous pouvez effectuer l'authentification à l'aide d'un tunnel SSH. Pour utiliser un tunnel, votre fichier de configuration d'authentification doit se trouver sur la machine distante et vous devez être en mesure d'accéder à votre fournisseur OpenID depuis votre machine locale.
Sur votre machine locale, exécutez la commande suivante :
ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT
Remplacez l'élément suivant :
USERNAME par un utilisateur disposant d'un accès SSH à la machine distante.
REMOTE_MACHINE par le nom d'hôte ou l'adresse IP de la machine distante.
LOCAL_PORT est un port disponible sur votre ordinateur local que
ssh
utilise pour créer un tunnel vers la machine distante.REMOTE_PORT est le port que vous avez configuré pour votre URL de redirection OIDC. Le numéro de port fait partie du champ
kubectlRedirectURI
de votre fichier de configuration d'authentification.
Dans votre interface système SSH, exécutez la commande suivante pour lancer l'authentification :
gcloud anthos auth login --login-config AUTH_CONFIG_FILE
Remplacez AUTH_CONFIG_FILE par le chemin d'accès de votre fichier de configuration d'authentification sur la machine distante. gcloud CLI exécute un serveur Web sur la machine distante.
Sur votre ordinateur local, dans un navigateur, accédez à http://localhost:LOCAL_PORT/login et suivez la procédure de connexion OIDC.
Le fichier kubeconfig
de votre ordinateur distant dispose désormais du jeton permettant d'accéder au cluster d'utilisateur.
Dans votre interface système SSH, vérifiez que vous avez accès au cluster d'utilisateur :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes
Console
Vous pouvez vous authentifier avec la console Google Cloud, puis lancer le flux d'authentification à partir de la page des clusters Kubernetes dans la console Google Cloud :
-
Ouvrez la console Google Cloud.
-
Localisez votre cluster GKE sur AWS dans la liste, puis cliquez sur Connexion.
-
Sélectionnez S'authentifier auprès du fournisseur d'identité configuré pour le cluster, puis cliquez sur CONNEXION.
Vous êtes redirigé vers votre fournisseur d'identité et il vous faudra peut-être vous connecter à la console Google Cloud ou l'autoriser à accéder à votre compte. Vous êtes ensuite redirigé vers la page Clusters Kubernetes dans la console Google Cloud.
Mettre à jour la configuration OIDC
Pour mettre à jour la configuration OIDC sur votre cluster, exécutez la commande kubectl edit
.
env HTTPS_PROXY=http://localhost:8118 \
kubectl edit clientconfigs -n kube-public default
L'outil kubectl
charge la ressource ClientConfig dans votre éditeur par défaut. Pour mettre à jour la configuration, enregistrez le fichier. L'outil kubectl
met à jour la ressource ClientConfig sur votre cluster.
Pour en savoir plus sur le contenu de la ressource ClientConfig, consultez la section suivante.
Annexe : Exemple de configuration de connexion
Vous trouverez ci-après un exemple de kubectl-anthos-config.yaml
, qui est donné pour en comprendre le contenu. Vous devez toujours générer le fichier avec gcloud anthos create-login-config
.
apiVersion: authentication.gke.io/v2alpha1 kind: ClientConfig metadata: name: default namespace: kube-public spec: authentication: - name: oidc oidc: clientID: CLIENT_CONFIG clientSecret: CLIENT_SECRET extraParams: resource=k8s-group-claim,domain_hint=consumers certificateAuthorityData: CERTIFICATE_STRING issuerURI: https://adfs.contoso.com/adfs kubectlRedirectURI: http://redirect.kubectl.com/ scopes: allatclaim,group userClaim: "sub" groupsClaim: "groups" proxy: PROXY_URL #Optional certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA name: projects/my-project/locations/global/membership/cluster-0 server: https://192.168.0.1:PORT preferredAuthentication: oidc
Pour obtenir des explications sur le contenu des champs, consultez la section Champs d'authentification.
Étapes suivantes
Déployez votre première charge de travail sur GKE sur AWS.