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) air-gapped à l'aide de la CLI gdcloud. Les clusters standards sont des environnements Kubernetes configurables à l'échelle du projet, avec un minimum de services par défaut. Ils 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 des clusters Kubernetes.

Cette page s'adresse aux audiences du groupe des 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 Audiences pour la documentation GDC sous air gap.

Avant de commencer

  • Demandez à votre administrateur IAM de l'organisation de vous attribuer le rôle Administrateur IAM du projet (project-iam-admin). Pour en savoir plus sur les rôles, consultez Définitions des rôles.
  • Installez gdcloud CLI si ce n'est pas déjà fait.

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

Un utilisateur disposant du rôle Administrateur IAM du projet (project-iam-admin) effectue les étapes suivantes pour accorder à d'autres utilisateurs les rôles nécessaires à la gestion des accès dans les clusters standards :

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

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

    Pour en savoir plus sur les rôles, consultez les sections Descriptions des rôles prédéfinis et Définitions des rôles 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 le cluster standard existe.
    • ROLE : nom du rôle que vous souhaitez attribuer (par exemple, cluster-admin ou cluster-developer).
    • USER_ACCOUNT : compte utilisateur auquel 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 accorde le rôle Administrateur de cluster à 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=cluster-admin \
  --member=user:fop-user@example.com

Gérer l'accès dans le cluster standard

Un utilisateur auquel le rôle cluster-admin a été attribué dans la section précédente effectue les étapes suivantes :

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

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

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

    Remplacez les variables suivantes :

    • KUBECONFIG_FILE : chemin d'accès au fichier kubeconfig, par exemple standard-cluster-kubeconfig.yaml.
    • STANDARD_CLUSTER_NAME : nom du cluster Standard.
    • PROJECT : nom du projet dans lequel le cluster standard existe.

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

    Les utilisateurs disposant des autorisations 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 Role personnalisé 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 RoleBinding pour 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