S'authentifier auprès du serveur d'API Kubernetes

Autopilot Standard

Cette page décrit les méthodes d'authentification compatibles pour la connexion au serveur d'API Kubernetes dans Google Kubernetes Engine (GKE).

Pour en savoir plus sur l'authentification des charges de travail Kubernetes auprès des API Google Cloud, consultez la page Fédération d'identité de charge de travail pour GKE.

Présentation

Il existe plusieurs méthodes d'authentification sur un serveur d'API Kubernetes. Dans GKE, l'authentification OAuth est la méthode recommandée pour s'authentifier auprès des clusters. Cette méthode est configurée automatiquement.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Authentifier les utilisateurs

GKE s'appuie sur Google Cloud CLI pour simplifier la gestion de l'authentification des utilisateurs finaux. gcloud CLI authentifie l'utilisateur auprès de Google Cloud, paramètre la configuration Kubernetes, obtient un jeton d'accès OAuth pour le cluster, puis maintient à jour ce jeton.

Tous les clusters GKE sont configurés pour accepter les identités de compte de service et de compte utilisateur Google Cloud, en validant les identifiants présentés par kubectl et en récupérant l'adresse e-mail associée à l'identité d'un utilisateur ou d'un compte de service. Par conséquent, les identifiants de ces comptes doivent inclure le champ d'application OAuth de userinfo.email afin de s'authentifier avec succès.

Lorsque vous utilisez gcloud pour configurer le fichier kubeconfig de votre environnement pour un nouveau cluster ou pour un cluster existant, gcloud fournit à kubectl les mêmes identifiants que ceux utilisés par gcloud. Par exemple, si vous utilisez la commande gcloud auth login, vos identifiants personnels sont fournis à kubectl, y compris le champ d'application userinfo.email. Cela permet au cluster GKE d'authentifier le client kubectl.

Vous pouvez également choisir de configurer kubectl pour utiliser les identifiants d'un compte de service Google Cloud lors de son exécution sur une instance Compute Engine. Toutefois, par défaut, le champ d'application userinfo.email n'est pas inclus dans les identifiants créés par les instances Compute Engine. Par conséquent, vous devez ajouter explicitement ce champ d'application, par exemple en utilisant l'option --scopes lors de la création de l'instance Compute Engine.

Vous pouvez autoriser des actions dans votre cluster à l'aide d'Identity and Access Management (IAM) ou du contrôle des accès basé sur les rôles Kubernetes (RBAC).

S'authentifier avec OAuth

Pour vous authentifier auprès de votre cluster à l'aide de la méthode OAuth, procédez comme suit :

Connectez-vous à la gcloud CLI à l'aide de vos identifiants. Cette commande ouvre un navigateur Web vous permettant de terminer le processus d'authentification auprès de Google Cloud :
```
gcloud auth login
```
Attention : Sur les VM Compute Engine, vous ne devez pas utiliser cette méthode. Vous devez utiliser un compte de service pour l'authentification. Pour en savoir plus, consultez la section Autre service Google Cloud.
Récupérez les identifiants Kubernetes pour un cluster spécifique à l'aide de la commande suivante :
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --zone=COMPUTE_ZONE
```
Vérifiez que vous êtes authentifié :
```
kubectl cluster-info
```

Une fois authentifiés, les comptes utilisateur ou de service Google Cloud doivent également être autorisés à effectuer des actions sur un cluster GKE. Pour en savoir plus sur la configuration des autorisations, consultez la page Contrôle des accès basé sur les rôles.

Authentifier des applications

Vous pouvez également vous authentifier auprès du serveur d'API à partir d'une application dans un pod sans interaction de l'utilisateur, par exemple à partir d'un script de votre pipeline CI/CD. La méthode d'authentification à employer dépend de l'environnement dans lequel votre service s'exécute.

Application dans le même cluster

Si votre application s'exécute dans le même cluster GKE, utilisez un compte de service Kubernetes pour l'authentification.

Créez un compte de service Kubernetes et associez-le à votre pod. Si votre pod dispose déjà d'un compte de service Kubernetes ou si vous souhaitez utiliser le compte de service par défaut de l'espace de noms, ignorez cette étape.
Utilisez Kubernetes RBAC pour accorder au compte de service Kubernetes les autorisations requises par votre application.

L'exemple suivant accorde des autorisations view permettant d'afficher les ressources dans l'espace de noms prod à un compte de service nommé cicd dans l'espace de noms cicd-ns :
```
kubectl create rolebinding cicd-secret-viewer \
    --namespace=prod \
    --clusterrole=view \
    --serviceaccount=cicd-ns:cicd
```
Au moment de l'exécution, lorsque votre application envoie une requête d'API Kubernetes, le serveur d'API authentifie les identifiants du compte de service.

Applications dans Google Cloud

Si votre application s'exécute dans Google Cloud mais en dehors du cluster cible (par exemple, une VM Compute Engine ou un autre cluster GKE), vous devez vous authentifier auprès du serveur d'API à l'aide des identifiants du compte de service IAM disponibles dans l'environnement.

Attribuez un compte de service IAM à votre environnement. Si votre application s'exécute dans une VM Compute Engine, attribuez un compte de service IAM à l'instance. Si votre application s'exécute dans un autre cluster GKE, utilisez la fédération d'identité de charge de travail pour GKE pour configurer votre pod afin qu'il s'exécute en tant que compte de service IAM.

Les exemples qui suivent utilisent ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com comme compte de service IAM.
Accordez au compte de service Google l'accès au cluster.

L'exemple suivant accorde le rôle IAM roles/container.developer, qui permet d'accéder aux objets de l'API Kubernetes dans les clusters :
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/container.developer
```
Vous pouvez également utiliser RBAC pour accorder l'accès au cluster au compte de service IAM. Exécutez la commande kubectl create rolebinding à partir de la page Applications dans le même cluster et utilisez --user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com au lieu de l'option --service-account.
Récupérez les identifiants du cluster à l'aide de la commande suivante :
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --zone=COMPUTE_ZONE
```
Votre application est automatiquement authentifiée à l'aide du compte de service IAM défini dans l'environnement.

Applications dans d'autres environnements

Si votre application s'authentifie à partir d'un environnement extérieur à Google Cloud, elle ne peut pas accéder aux identifiants gérés par le compte de service IAM. Pour récupérer les identifiants du cluster, vous pouvez créer un compte de service IAM, télécharger sa clé, puis utiliser cette clé au moment de l'exécution depuis votre service pour récupérer les identifiants du cluster à l'aide de gcloud CLI.

Créez un compte de service IAM pour votre application. Si vous disposez déjà d'un compte de service IAM, ignorez cette étape.

La commande suivante crée un compte de service IAM nommé ci-cd-pipeline :
```
gcloud iam service-accounts create ci-cd-pipeline
```
Accordez au compte de service IAM l'accès à votre cluster.

La commande suivante accorde le rôle IAM roles/container.developer au compte de service IAM ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com :
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/container.developer
```
Vous pouvez également utiliser RBAC pour accorder au compte de service IAM l'accès au cluster. Exécutez la commande kubectl create rolebinding à partir de la page Applications dans le même cluster et utilisez --user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com au lieu de l'option --service-account.
Créez une clé pour votre compte de service IAM et téléchargez-la. Rendez-la disponible pour votre application au moment de l'exécution :
```
gcloud iam service-accounts keys create gsa-key.json \
    --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
```
Lors de l'exécution, dans l'environnement exécutant votre service, authentifiez-vous après de gcloud CLI avec la clé de votre compte de service IAM :
```
gcloud auth activate-service-account ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --key-file=gsa-key.json
```

Utilisez gcloud CLI pour récupérer les identifiants du cluster :

gcloud config set project PROJECT_ID
gcloud container clusters get-credentials CLUSTER_NAME \
    --zone=COMPUTE_ZONE

Environnements sans gcloud

Il est recommandé d'utiliser gcloud CLI pour récupérer les identifiants du cluster, car cette méthode est résiliente à certains événements du cluster tels qu'une rotation d'adresses IP ou une rotation des identifiants du plan de contrôle. Toutefois, si vous ne pouvez pas installer gcloud CLI dans votre environnement, vous pouvez toujours créer un fichier kubeconfig statique pour réaliser l'authentification auprès du cluster. La démarche à suivre est la suivante :

Créez un compte de service IAM pour votre application. Si vous disposez déjà d'un compte de service IAM, ignorez cette étape.

La commande suivante crée un compte de service IAM nommé ci-cd-pipeline :
```
gcloud iam service-accounts create ci-cd-pipeline
```
Accordez au compte de service IAM l'accès à votre cluster.

La commande suivante accorde le rôle IAM roles/container.developer au compte de service IAM ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com :
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/container.developer
```
Vous pouvez également créer un rôle IAM personnalisé pour un contrôle plus précis des autorisations que vous accordez.

Créez une clé pour votre compte de service IAM et téléchargez-la.

Dans l'exemple suivant, le fichier de clé est nommé gsa-key.json :

gcloud iam service-accounts keys create gsa-key.json \
    --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com

Récupérez les valeurs endpoint et clusterCaCertificate du cluster à l'aide des commandes suivantes :

gcloud container clusters describe CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
     --format="value(endpoint)"

gcloud container clusters describe CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --format="value(masterAuth.clusterCaCertificate)"

Créez un fichier kubeconfig.yaml à partir du modèle ci-dessous :

apiVersion: v1
kind: Config
clusters:
- name: CLUSTER_NAME
  cluster:
    server: https://endpoint
    certificate-authority-data: masterAuth.clusterCaCertificate
users:
- name: ci-cd-pipeline-gsa
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - --use_application_default_credentials
      command: gke-gcloud-auth-plugin
      installHint: Install gke-gcloud-auth-plugin for kubectl by following
        https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin
      provideClusterInfo: true
contexts:
- context:
    cluster: CLUSTER_NAME
    user: ci-cd-pipeline-gsa
  name: CLUSTER_NAME-ci-cd
current-context: CLUSTER_NAME-ci-cd

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster
endpoint : valeur endpoint récupérée à l'étape précédente
masterAuth.clusterCaCertificate : valeur clusterCaCertificate récupérée à l'étape précédente (inutile de décoder le certificat encodé en base64)

Dans votre environnement, déployez les fichiers kubeconfig.yaml et gsa-key.json avec votre application. Au moment de l'exécution, dans l'environnement où s'exécute votre application, définissez les variables d'environnement suivantes :
```
export KUBECONFIG=path/to/kubeconfig.yaml
export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
```
Votre application peut désormais envoyer des requêtes à l'API Kubernetes et sera authentifiée en tant que compte de service IAM.

Anciennes méthodes d'authentification

Avant l'intégration de GKE à OAuth, les seules méthodes d'authentification disponibles étaient les certificats X.509 préprovisionnés et les mots de passe statiques. Aujourd'hui, ces méthodes ne sont plus recommandées et il est préférable de les désactiver. Ces méthodes présentent une surface d'attaque plus étendue pouvant compromettre la sécurité du cluster. Elles sont désactivées par défaut depuis la version 1.12 de GKE. Si vous utilisez d'anciennes méthodes d'authentification, nous vous recommandons de les désactiver.

Si ces anciennes méthodes sont actives, un utilisateur disposant de l'autorisation container.clusters.getCredentials peut récupérer le certificat client et le mot de passe statique. Les rôles roles/container.admin, roles/owner et roles/editor disposent tous de cette autorisation. Veillez donc à utiliser ces rôles à bon escient. En savoir plus sur les rôles IAM dans GKE.

Désactiver l'authentification par mot de passe statique

Un mot de passe statique est une combinaison de nom d'utilisateur et de mot de passe validée par le serveur d'API. Dans GKE, cette méthode d'authentification est appelée authentification de base.

Pour mettre à jour un cluster existant et supprimer le mot de passe statique, exécutez cette commande :

gcloud container clusters update CLUSTER_NAME --no-enable-basic-auth

Désactiver l'authentification par certificat client

Avec le mode d'authentification par certificat, un client présente un certificat que le serveur d'API valide auprès de l'autorité de certification spécifiée. Dans GKE, l'autorité de certification (CA) racine du cluster signe les certificats clients.

L'authentification par certificat client n'est pas sans incidence sur les autorisations d'accès au serveur d'API Kubernetes. Si l'ancienne méthode d'autorisation appelée contrôle des accès basé sur les attributs (ABAC) est activée sur le cluster, les certificats clients peuvent par défaut s'authentifier et effectuer n'importe quelle action sur le serveur d'API. En revanche, lorsque c'est le contrôle des accès basé sur les rôles (RBAC) qui est activé, les certificats clients doivent obtenir des autorisations spécifiques pour accéder aux ressources Kubernetes.

Pour créer un cluster sans générer de certificat client, utilisez l'option --no-issue-client-certificate :

gcloud container clusters create CLUSTER_NAME \
    --no-issue-client-certificate

Actuellement, il n'existe aucun moyen de supprimer un certificat client d'un cluster existant. Pour cesser d'utiliser l'authentification par certificat client sur un cluster existant, assurez-vous que RBAC est activé sur le cluster et que le certificat client ne dispose d'aucune autorisation sur le cluster.

Étapes suivantes

Découvrez l'authentification Google Cloud.
Découvrez le contrôle des accès dans GKE.
Découvrez les comptes de service Google.
Découvrez la fédération d'identité de charge de travail pour GKE.
Découvrez comment renforcer la sécurité de votre cluster.