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

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 Workload Identity.

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 :

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

  • Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
  • Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

  1. Exécutez gcloud init et suivez les instructions :

    gcloud init

    Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

    gcloud init --console-only
  2. Suivez les instructions pour autoriser gcloud à utiliser votre compte Google Cloud.
  3. Créez ou sélectionnez une configuration.
  4. Choisissez un projet Google Cloud.
  5. Choisissez une zone Compute Engine par défaut pour les clusters zonaux ou une région pour les clusters régionaux ou Autopilot.

Utiliser gcloud config

  • Définissez votre ID de projet par défaut :
    gcloud config set project PROJECT_ID
  • Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut :
    gcloud config set compute/zone COMPUTE_ZONE
  • Si vous utilisez des clusters Autopilot ou régionaux, définissez votre région de calcul par défaut:
    gcloud config set compute/region COMPUTE_REGION
  • Mettez à jour gcloud vers la dernière version :
    gcloud components update

Authentifier les utilisateurs

GKE s'appuie sur l'outil de ligne de commande gcloud pour simplifier la gestion de l'authentification des utilisateurs finaux. L'outil gcloud 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. Vous pouvez contrôler l'accès à votre cluster à l'aide de la gestion de l'authentification et des accès (IAM) ou du contrôle des accès basé sur les rôles Kubernetes (RBAC).

Avant l'intégration de GKE à OAuth, les certificats x509 préprovisionnés et les mots de passe statiques étaient les seules méthodes d'authentification disponibles. Aujourd'hui, ces méthodes ne sont plus recommandées. Elles sont désactivées par défaut sur les nouveaux clusters depuis la version 1.12 de GKE. Si vous utilisez d'anciennes méthodes d'authentification, nous vous recommandons de cesser de les utiliser.

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 à l'outil gcloud à 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 \
        --zone=COMPUTE_ZONE
    
  3. Vous êtes maintenant authentifié, ainsi que vous pouvez le vérifier à l'aide de la commande kubectl suivante :

    kubectl cluster-info
    

Authentifier des services

Dans certains cas, vous devez authentifier un service auprès du serveur d'API d'un cluster GKE, sans intervention de l'utilisateur (par exemple, pour un script de pipeline CI/CD). La méthode d'authentification à employer dépend de l'environnement dans lequel votre service s'exécute.

Service au sein du même cluster GKE

Si votre service s'exécute dans un pod du cluster GKE auquel vous souhaitez vous connecter, 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, vous pouvez ignorer cette étape.

    Dans notre exemple, nous utilisons un compte de service Kubernetes nommé cicd dans l'espace de noms cicd-ns.

  2. Accordez au compte de service Kubernetes les autorisations appropriées à l'aide de Kubernetes RBAC.

    Dans notre exemple, nous attribuons le rôle edit dans l'espace de noms prod. Dans la pratique, vous devez attribuer le rôle qui répond à vos besoins.

    kubectl create rolebinding cicd \
        --clusterrole=edit \
        --serviceaccount=cicd-ns:cicd \
        --namespace=prod
    
  3. Au moment de l'exécution, lorsque votre service appellera kubectl, il recevra automatiquement les identifiants que vous avez configurés.

Autre service Google Cloud

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

  1. Associez un compte de service Google à votre environnement Compute Engine. Si votre service s'exécute dans une VM Compute Engine, associez un compte de service Google à l'instance. Si votre service s'exécute dans un cluster GKE, utilisez Workload Identity pour configurer le pod afin qu'il s'exécute en tant que compte de service Google.

    Dans notre exemple, nous utilisons ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com comme compte de service Google.

  2. Accordez au compte de service Google l'accès au cluster souhaité.

    Dans notre exemple, nous attribuons 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
    
  3. Récupérez les identifiants du cluster à l'aide de la commande suivante :

    gcloud container clusters get-credentials CLUSTER_NAME \
        --zone=COMPUTE_ZONE
    

    Votre service sera automatiquement authentifié à l'aide du compte de service Google mis en place dans l'environnement.

Service hébergé dans un autre environnement

Si votre service s'authentifie à partir d'un environnement extérieur à Google Cloud, il n'a pas accès aux identifiants gérés par le compte de service Google. Pour récupérer les identifiants du cluster, vous devez créer un compte de service Google, 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 l'outil gcloud.

  1. Créez un compte de service Google pour votre service. Si vous disposez déjà d'un compte de service Google, vous pouvez ignorer cette étape.

    Dans notre exemple, nous créons un compte de service nommé ci-cd-pipeline :

    gcloud iam service-accounts create ci-cd-pipeline
    
  2. Accordez au compte de service Google l'accès à votre cluster.

    Dans notre exemple, nous utilisons ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com comme compte de service Google, et nous lui attribuons 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
    

    Nous avons accordé l'accès à l'aide d'IAM. Pour un contrôle plus précis de l'accès, utilisez plutôt Kubernetes RBAC.

  3. Créez une clé pour votre compte de service Google, téléchargez-la et rendez-la disponible 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, utilisez la commande gcloud suivante et la clé du compte de service Google pour l'authentification :

    gcloud auth activate-service-account ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
        --key-file=gsa-key.json
    

    Cette opération nécessite que l'outil gcloud soit installé dans votre environnement. Pour savoir comment installer l'outil gcloud, consultez la page Installer le SDK Cloud. Si vous ne parvenez pas à installer l'outil gcloud dans votre environnement, consultez la section Environnements sans gcloud.

  5. Utilisez l'outil gcloud 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 l'outil gcloud 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 l'outil gcloud 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 Google pour votre service. Si vous disposez déjà d'un compte de service Google, vous pouvez ignorer cette étape.

    Dans notre exemple, nous créons un compte de service nommé ci-cd-pipeline :

    gcloud iam service-accounts create ci-cd-pipeline
    
  2. Accordez au compte de service Google l'accès à votre cluster.

    Dans notre exemple, nous utilisons ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com comme compte de service Google, et nous lui attribuons 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
    

    Nous avons accordé l'accès à l'aide d'IAM. Pour un contrôle plus précis de l'accès, utilisez plutôt Kubernetes RBAC.

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

    Dans notre exemple, 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. 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)"
    
  5. 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:
        auth-provider:
          name: gcp
    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)
  6. Dans votre environnement, déployez les fichiers kubeconfig.yaml et gsa-key.json avec votre service. Au moment de l'exécution, dans l'environnement où s'exécute votre service, définissez les variables d'environnement suivantes :

    export KUBECONFIG=path/to/kubeconfig.yaml
    export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
    
  7. Votre service peut ensuite appeler kubectl : il sera authentifié en tant que compte de service Google.

Anciennes méthodes d'authentification

Avant l'intégration de GKE à OAuth, les seules méthodes d'authentification disponibles étaient les certificats x509 générés pour un usage unique 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. L'authentification avec un mot de passe statique est obsolète et a été supprimée depuis la version 1.19 de GKE.

Si ces méthodes sont activées, le certificat client et le mot de passe statique peuvent être récupérés par tout utilisateur disposant de l'autorisation container.clusters.getCredentials. Notez que 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, les certificats clients sont signés par l'autorité de certification (CA) racine du cluster.

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.

Étape suivante