Accorder et obtenir l'accès aux buckets de stockage pour les projets

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 deux secrets nommés :

  1. object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja

Obtenir l'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 trouver le nom du secret :

    kubectl auth can-i --list --namespace object-storage-access-keys | grep object-storage-key-

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

    secrets        []        [object-storage-key-nl-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja,object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja]        [get]

  2. Récupérez le contenu du secret correspondant pour accéder aux buckets de la classe de stockage Standard :

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

    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, recherchez le nom du secret dans le cluster d'utilisateur.

  1. Pour la classe de stockage standard, exécutez la commande suivante pour obtenir le nom du secret :

    kubectl get -n=<PROJECT-NAME> serviceaccount <SA-NAME> -o json | jq -r '.secrets[] | select(.name | test("object-storage-key-std"))'

  2. Vous pouvez ensuite parcourir manuellement la liste des noms de secrets ou utiliser grep pour trouver object-storage-key-(std|nl). Pour la dernière option, exécutez la commande suivante :

    kubectl get -n=<PROJECT-NAME> serviceaccount <SA-NAME> -o=jsonpath='{.secrets}{"\n"}' | grep object-storage-key-(std|nl)

  3. 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. GetObject
    2. GetObjectAcl
    3. GetObjectLegalHold
    4. GetObjectRetention
    5. GetObjectTagging
    6. GetObjectVersion
    7. GetObjectVersionTagging
    8. ListBucket
    9. ListBucketVersions
    10. ListBucketMultipartUploads
    11. 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