Gérer l'accès aux clusters standards

Ce document explique comment gérer les autorisations pour les clusters standards dans Google Distributed Cloud (GDC) sous air gap à l'aide de la CLI gdcloud. Les clusters standards sont des environnements Kubernetes configurables à portée de projet avec des services par défaut minimaux qui offrent une plus grande flexibilité et un meilleur contrôle pour les charges de travail personnalisées.

Pour en savoir plus sur les clusters standards et les autres types de clusters, consultez Configurations de cluster Kubernetes.

Ce document est destiné aux audiences du groupe d'opérateurs d'applications, telles que les opérations de développement ou les data scientists, qui doivent gérer et sécuriser les ressources dans les projets GDC. Pour en savoir plus, consultez la documentation sur les audiences pour GDC sous air gap.

Avant de commencer

Avant de gérer l'accès aux clusters standards, vous devez disposer des autorisations nécessaires et préparer votre environnement.

Demander des rôles IAM

Contactez l'administrateur IAM de votre organisation pour demander les rôles suivants en fonction des tâches que vous devez effectuer :

  • Administrateur IAM du projet (project-iam-admin) : créez, mettez à jour et supprimez des liaisons de rôle pour les clusters standards au sein d'un projet.
  • Administrateur de cluster standard (standard-cluster-admin) : créez, mettez à jour et supprimez des liaisons de rôle dans un cluster standard spécifique.

Préparer votre environnement

Accorder des autorisations pour l'accès au cluster standard

Un utilisateur disposant du rôle d'administrateur IAM du projet (project-iam-admin) peut accorder à d'autres utilisateurs les rôles nécessaires pour gérer l'accès dans les clusters standards :

  1. Connectez-vous avec votre fournisseur d'identité configuré à l'aide de la CLI gdcloud.

  2. Attribuez à l'utilisateur le rôle d'administrateur de cluster standard (standard-cluster-admin) pour le projet. Cette commande lie l'utilisateur au rôle, ce qui lui permet de gérer l'accès au cluster standard.

    Pour en savoir plus sur les rôles, consultez Descriptions des rôles prédéfinis et Définitions de rôle pour les projets.

    gdcloud projects add-iam-policy-binding PROJECT \
  --role=ROLE \
  --member=user:USER_ACCOUNT

    Remplacez les variables suivantes :

    • PROJECT: nom du projet dans lequel se trouve le cluster standard.
    • ROLE: nom du rôle que vous souhaitez attribuer (par exemple, standard-cluster-admin).
    • USER_ACCOUNT: compte utilisateur pour lequel vous souhaitez attribuer le rôle, y compris le préfixe du fournisseur d'identité associé à votre organisation (par exemple, idpprefix-user@example.com). Le préfixe spécifique utilisé dépend de la configuration IdP de votre organisation. Pour en savoir plus, consultez Se connecter à un fournisseur d'identité.

    L'exemple suivant attribue le rôle d'administrateur de cluster standard à user@example.com, en supposant que le préfixe du fournisseur d'identité est fop- pour le projet foo :

    gdcloud projects add-iam-policy-binding foo \
  --role=standard-cluster-admin \
  --member=user:fop-user@example.com

Gérer l'accès au cluster standard

Un utilisateur disposant du rôle d'administrateur de cluster standard (standard-cluster-admin) peut accorder l'accès à un cluster standard :

  1. Connectez-vous avec votre fournisseur d'identité configuré à l'aide de la CLI gdcloud.

  2. Générez un fichier kubeconfig pour un cluster standard à l'aide de l'option --standard. Cette option est requise pour cibler un cluster standard.

    export KUBECONFIG=KUBECONFIG_FILE
gdcloud clusters get-credentials STANDARD_CLUSTER_NAME --standard --project=PROJECT

    Remplacez les variables suivantes :

    • KUBECONFIG_FILE: chemin d'accès au fichier kubeconfig, tel que standard-cluster-kubeconfig.yaml.
    • STANDARD_CLUSTER_NAME: nom du cluster standard.
    • PROJECT: nom du projet dans lequel se trouve le cluster standard.

  3. Définissez les autorisations dans le cluster standard à l'aide de kubectl.

    Les utilisateurs disposant des autorisations standard-cluster-admin peuvent créer des objets Role et ClusterRole personnalisés. Pour accorder ces autorisations, ils peuvent créer les objets Rolebinding et ClusterRoleBinding correspondants afin de lier les rôles à des sujets spécifiques, tels que des utilisateurs ou des comptes de service.

    L'exemple suivant utilise kubectl pour créer un exemple de Role nommé test-role dans l'espace de noms test :

    kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-role
  namespace: test
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
EOF

    L'exemple suivant crée le RoleBinding pour le Role nommé test-role dans l'espace de noms test. Il accorde des autorisations à l'utilisateur alice@example.com avec le préfixe du fournisseur d'identité fop-, ainsi qu'à un ServiceAccount nommé my-service-account dans l'espace de noms default :

    kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-role-binding
  namespace: test
subjects:
- kind: User
  name: fop-alice@example.com
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-service-account
  namespace: default
roleRef:
  kind: Role
  name: test-role
  apiGroup: rbac.authorization.k8s.io
EOF