Accorder et obtenir l'accès à un bucket de stockage

Cette page vous explique comment gérer l'accès aux buckets de stockage dans les projets Google Distributed Cloud (GDC) isolés, afin que les bonnes personnes disposent des bonnes autorisations. Il couvre les prérequis et les étapes à suivre pour obtenir et accorder l'accès aux comptes utilisateur et de service à l'aide de liaisons de rôle et de rôles prédéfinis. Ces informations vous permettent de contrôler efficacement l'accès à vos ressources de stockage, et de maintenir à la fois la sécurité et l'efficacité opérationnelle.

Cette page s'adresse à des audiences telles que les administrateurs informatiques du groupe des opérateurs d'infrastructure ou les développeurs du groupe des opérateurs d'application qui gèrent les paramètres d'accès aux buckets de stockage dans les environnements GDC isolés. Pour en savoir plus, consultez la documentation sur les audiences pour GDC en mode air-gapped.

Avant de commencer

Un espace de noms de projet gère les ressources de bucket sur le serveur de l'API Management. Vous devez disposer d'un projet pour travailler avec des buckets et des objets.

Accorder l'accès au bucket

Vous pouvez accorder l'accès aux buckets à d'autres utilisateurs ou comptes de service en créant et en appliquant des RoleBindings avec des rôles prédéfinis dans le serveur de l'API Management.

Rôles prédéfinis

• project-bucket-object-viewer: : permet à un utilisateur de lister tous les buckets du projet, les objets de ces buckets, ainsi que de lire les objets et les métadonnées d'objet. Il ne vous permet pas d'effectuer des opérations d'écriture sur des objets. (importation, écrasement, suppression, par exemple). Dispose d'un accès en lecture seule aux buckets à double zone de l'organisation et de ses projets, ainsi qu'aux objets de ces buckets.

• project-bucket-object-admin: : permet à un utilisateur de lister tous les buckets du projet, et d'effectuer des opérations d'écriture et de lecture sur les objets. (importation, écrasement, suppression, par exemple). Dispose d'un accès en lecture seule aux buckets à double zone de l'organisation et de ses projets, ainsi qu'un accès en lecture/écriture aux objets de ces buckets.

• project-bucket-admin: : permet aux utilisateurs de gérer tous les buckets de l'espace de noms donné, ainsi que tous les objets de ces buckets. Dispose d'un accès en lecture seule aux buckets à double zone de l'organisation et de ses projets, ainsi qu'un accès en lecture/écriture aux objets de ces buckets.

Pour obtenir la liste complète des autorisations accordées pour les rôles précédents, consultez la section Autorisations des rôles prédéfinis.

Demandez à votre administrateur IAM de projet de vous accorder les autorisations nécessaires pour créer des RoleBindings. Voici un exemple de création d'un RoleBinding pour accorder l'accès à un utilisateur et à un compte de service :

1. Créez un fichier YAML sur votre système, par exemple rolebinding-object-admin-all-buckets.yaml.

   # Example file name:
   # rolebinding-object-admin-all-buckets.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     namespace: NAMESPACE_NAME
     name: readwrite-all-buckets
   roleRef:
     kind: Role
     name: project-bucket-object-admin
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: ServiceAccount
     namespace: NAMESPACE_NAME
     name: SA_NAME
   - kind: User
     namespace: NAMESPACE_NAME
     name: bob@example.com
     apiGroup: rbac.authorization.k8s.io
     # Could be bob or bob@example.com based on your organization settings.
   

2. Appliquez le fichier YAML :

   kubectl apply \
   -f rolebinding-object-admin-all-buckets.yaml
   

Obtenir les identifiants d'accès aux buckets

Une fois que vous avez accordé l'accès à un bucket, les identifiants d'accès sont créés dans un secret.

Le format du nom du secret est object-storage-key-STORAGE_CLASS-SUBJECT_TYPE-SUBJECT_HASH.

• Voici les valeurs pour STORAGE_CLASS :
  • std pour la classe de stockage Standard.
• Voici les valeurs pour SUBJECT_TYPE :
  • user pour l'utilisateur.
  • sa pour ServiceAccount.
• SUBJECT_HASH correspond au hachage SHA256 encodé en base32 du nom du sujet.

Par exemple, l'utilisateur bob@foo.com possède un secret nommé :

object-storage-key-std-user-l74gbpyrsbmwy4mivocr3nur6dzrnhcfhe3otyplul42i732aama

Obtenir les identifiants d'accès utilisateur

Pour un sujet utilisateur, le secret se trouve dans l'espace de noms object-storage-access-keys du serveur de l'API Management.

1. Exécutez la commande suivante pour lister les ressources Secret que vous êtes autorisé à afficher dans l'espace de noms object-storage-access-keys :

   kubectl auth can-i --list --namespace object-storage-access-keys
   

   • REMARQUE : Si vous êtes un administrateur autorisé à afficher toutes les ressources Secret ou à emprunter l'identité d'autres utilisateurs, vous pouvez exécuter l'une des commandes suivantes pour trouver le nom des Secrets d'un utilisateur spécifié :

     Répertoriez tous les secrets appartenant à un utilisateur spécifié :

     export USER_NAME=bob@example.com
     kubectl get secrets --namespace object-storage-access-keys -o json | jq  -r --arg USER_NAME "${USER_NAME:?}" '.items[] | select( (.metadata.annotations."object.gdc.goog/subject"==$USER_NAME)) | .metadata.name'
     

     Empruntez l'identité d'un utilisateur pour voir les secrets qu'il peut consulter :

     export USER_NAME=bob@example.com
     kubectl auth can-i --list --namespace object-storage-access-keys --as "${USER_NAME:?}"
     

   Si vous pouvez afficher des secrets dans cet espace de noms, vous devriez voir un résultat contenant un nom de secret semblable à ce qui suit :

   object-storage-key-std-user-l74gbpyrsbmwy4mivocr3nur6dzrnhcfhe3otyplul42i732aama
   

2. Obtenez le contenu du secret correspondant :

   kubectl get -o yaml --namespace object-storage-access-keys secret object-storage-key-std-user-l74gbpyrsbmwy4mivocr3nur6dzrnhcfhe3otyplul42i732aama
   

   Vous obtenez un résultat semblable à celui-ci :

   data:
     access-key-id: MEhYM08wWUMySjcyMkVKTFBKRU8=
     create-time: MjAyMi0wNy0yMiAwMTowODo1OS40MTQyMTE3MDMgKzAwMDAgVVRDIG09KzE5OTAuMzQ3OTE2MTc3
     secret-access-key: Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==
   

3. Décodez l'ID de clé d'accès et le secret :

   echo "MEhYM08wWUMySjcyMkVKTFBKRU8=" | base64 -d \
       && echo \
       && echo "Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==" | base64 -d
   

   Vous obtenez un résultat semblable à celui-ci :

   0HX3O0YC2J722EJLPJEO
   Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT
   

4. Suivez la section Configurer la CLI gdcloud avec les informations obtenues.

Obtenir l'accès au compte de service

Pour un sujet de compte de service, le secret est créé dans le même espace de noms que le compte de service.

Exécutez la commande suivante pour vérifier que vous pouvez obtenir et lister les ressources Secret dans l'espace de noms. Si ce n'est pas le cas, contactez votre administrateur :

export SA_NAMESPACE=NAMESPACE_NAME
kubectl auth can-i --list --namespace $SA_NAMESPACE

Pour trouver le nom du secret, exécutez la commande suivante :

export SA_NAME=SA_NAME
kubectl get secrets --namespace $SA_NAMESPACE  -o json | jq  -r --arg USER_NAME "${SA_NAME:?}" '.items[] | select( (.metadata.annotations."object.gdc.goog/subject"==$USER_NAME)) | .metadata.name'

Vous obtenez un résultat semblable à celui-ci :

object-storage-key-std-sa-mng3olp3vsynhswzasowzu3jgzct2ert72pjp6wsbzqhdwckwzbq

Vous pouvez référencer le secret dans votre pod en tant que variables d'environnement ou fichiers.

Autorisations des rôles prédéfinis

Notez que des rôles prédéfinis sont également disponibles sur le serveur d'API mondial pour l'accès administratif et opérationnel aux buckets à double zone.

Autorisations "Lecteur des objets du bucket du projet"

Ce rôle accorde les autorisations nécessaires pour obtenir et lister les objets et les métadonnées des objets dans le bucket.

Voici la liste de toutes les autorisations de stockage d'objets accordées par le verbe project-bucket-object-viewer :

• Autorisations de l'API pour les buckets :

  1. get
  2. list
  3. watch

• Autorisations de stockage d'objets S3 :

  1. GetBucketVersioning
  2. GetObject
  3. GetObjectAcl
  4. GetObjectLegalHold
  5. GetObjectRetention
  6. GetObjectTagging
  7. GetObjectVersion
  8. GetObjectVersionTagging
  9. ListBucket
  10. ListBucketVersions
  11. ListBucketMultipartUploads
  12. ListMultipartUploadParts

Autorisations d'administrateur d'objet et de bucket de projet

Ce rôle permet de placer et de supprimer des objets, des versions d'objets et des tags dans le bucket. Il accorde également toutes les autorisations dans project-bucket-object-viewer.

Voici la liste de toutes les autorisations supplémentaires accordées par le rôle pour le stockage d'objets :

• Autorisations de stockage d'objets S3 :

  1. AbortMultipartUpload
  2. DeleteObject
  3. DeleteObjectTagging
  4. DeleteObjectVersion
  5. DeleteObjectVersionTagging
  6. PutObject
  7. PutObjectTagging
  8. PutObjectVersionTagging
  9. PutOverwriteObject
  10. RestoreObject

Autorisations d'administrateur de bucket de projet

Ce rôle accorde les autorisations nécessaires pour créer, mettre à jour ou supprimer des ressources de bucket dans l'espace de noms du projet. Il accorde également toutes les autorisations dans project-bucket-object-admin.

Voici une liste des autorisations supplémentaires accordées par le rôle :

• Autorisations de l'API pour les buckets :

  1. Créer
  2. Mettre à jour
  3. Supprimer