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

Cette page vous explique comment vous authentifier de manière sécurisée auprès du serveur d'API Kubernetes à partir de clusters GKE. Vous pouvez sécuriser votre cluster en vous assurant que seuls les utilisateurs et les applications autorisés accèdent à vos ressources Kubernetes. Vous découvrirez les méthodes d'authentification disponibles, la méthode d'authentification recommandée et comment authentifier les utilisateurs, les applications et les anciens systèmes.

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

Cette page s'adresse aux spécialistes de la sécurité et aux opérateurs qui doivent s'authentifier de manière sécurisée auprès du serveur d'API Kubernetes à partir de clusters GKE. Cette page fournit des informations essentielles sur les méthodes d'authentification disponibles et sur la manière de les implémenter. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Avant de lire cette page, assurez-vous de maîtriser les concepts suivants :

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.

Authentifier les utilisateurs

GKE s'appuie sur Google Cloud CLI pour simplifier la gestion de l'authentification des utilisateurs finaux. Gcloud CLI authentifie les utilisateurs auprès deGoogle Cloud, configure 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 parkubectl 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 serviceGoogle 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 :

  1. 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

  2. Récupérez les identifiants Kubernetes pour un cluster spécifique à l'aide de la commande suivante :

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • CONTROL_PLANE_LOCATION: emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.

  3. Vérifiez que vous êtes authentifié :

    kubectl cluster-info

Une fois authentifiés, les utilisateurs ou les Google Cloud comptes de service 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.

  1. 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.

  2. 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

  3. 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.

  1. 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.

  2. 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.

  3. Récupérez les identifiants du cluster à l'aide de la commande suivante :

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    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.

  1. 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

  2. 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.

  3. 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

  4. 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

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

    gcloud config set project PROJECT_ID
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

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 :

  1. 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

  2. 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.

  3. 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

  4. Si vous utilisez le point de terminaison basé sur un DNS pour l'accès au plan de contrôle, obtenez la valeur endpoint pour votre cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(endpoint)"

    Si vous utilisez le point de terminaison basé sur l'adresse IP pour l'accès au plan de contrôle, obtenez la valeur endpoint à partir de la commande précédente et la valeur clusterCaCertificate pour votre cluster:

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

  5. Créez un fichier kubeconfig.yaml. Utilisez le format suivant si vous utilisez le point de terminaison basé sur DNS pour l'accès au plan de contrôle:

    apiVersion: v1
kind: Config
clusters:
- name: CLUSTER_NAME
  cluster:
    server: https://endpoint
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

    Si vous utilisez des points de terminaison basés sur l'adresse IP pour l'accès au plan de contrôle, ajoutez la valeur que vous avez obtenue pour clusterCaCertificate à l'étape précédente dans le paramètre cluster du fichier kubeconfig.yaml:

    apiVersion: v1
kind: Config
clusters:
- name: CLUSTER_NAME
  cluster:
    server: https://endpoint
    certificate-authority-data: masterAuth.clusterCaCertificate
users:
...

    Vous n'avez pas besoin de décoder le certificat encodé en base64.

  6. 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

  7. Votre application peut désormais envoyer des requêtes à l'API Kubernetes et sera authentifiée en tant que compte de service IAM.

Mettre à jour les 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 \
     --location=CONTROL_PLANE_LOCATION \
     --no-enable-basic-auth

Désactiver l'authentification avec un 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 \
    --location=CONTROL_PLANE_LOCATION
    --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