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 d'appliance isolée Google Distributed Cloud (GDC), afin que les bonnes personnes disposent des autorisations appropriées. 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'applications qui gèrent les paramètres d'accès aux buckets de stockage dans les environnements GDC isolés.

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.

Rôles prédéfinis

  • project-bucket-object-viewer: : ce rôle permet à un utilisateur de lister tous les buckets du projet, les objets de ces buckets, et de lire les objets et les métadonnées d'objets. Ce rôle ne vous permet pas d'effectuer des opérations d'écriture sur des objets, comme l'importation, l'écrasement ou la suppression.

  • project-bucket-object-admin: : ce rôle permet à un utilisateur de lister tous les buckets du projet, et d'effectuer des opérations d'écriture et de lecture sur les objets, comme les importer, les écraser ou les supprimer.

  • project-bucket-admin: : ce rôle permet aux utilisateurs de gérer tous les buckets de l'espace de noms donné, ainsi que tous les objets de ces buckets.

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

Pour obtenir les autorisations nécessaires pour créer des liaisons de rôle de projet, demandez à votre administrateur IAM de projet de vous accorder le rôle Administrateur IAM de projet (project-iam-admin).

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.

     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  # Could be bob or bob@example.com based on your organization settings.
       apiGroup: rbac.authorization.k8s.io
     ```
    
  2. Appliquez le fichier YAML :

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

Obtenir les identifiants d'accès au bucket

Lorsque vous accordez 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-std-SUBJECT_TYPE-SUBJECT_HASH.

  • Les valeurs de SUBJECT_TYPE sont les suivantes :
    • user : l'utilisateur.
    • sa : ServiceAccount.
  • SUBJECT_HASH correspond au hachage SHA256 encodé en base32 du nom du sujet.

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

object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja

Accéder au secret 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. Recherchez le nom du secret :

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

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

    secrets        []        [object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja,object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja]        [get]
    
  2. Obtenez le contenu du secret correspondant pour accéder aux buckets :

    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 code 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 s3cmd avec les informations obtenues.

Accéder au secret du compte de service

Pour un sujet de compte de service (SA), le secret est créé dans le même espace de noms que le compte de service. Pour trouver le nom, exécutez la commande suivante :

  kubectl get --namespace NAMESPACE_NAME secrets -o=jsonpath=
  '{.items[?(@.metadata.annotations.object\.gdc\.goog/subject=="SA_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 (https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables) ou fichiers (https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod).

Autorisations des rôles prédéfinis

Lorsque vous travaillez avec le stockage d'objets, vous devrez peut-être demander les rôles suivants.

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.

Le rôle project-bucket-object-viewer dispose des autorisations suivantes :

  • Autorisations de l'API pour les buckets :

    1. Get
    2. Liste
    3. Regarder
  • Autorisations de stockage d'objets S3 :

    1. GetObject
    2. GetObjectAcl
    3. GetObjectVersion
    4. ListBucket
    5. ListBucketVersions
    6. ListBucketMultipartUploads
    7. ListMultipartUploadParts

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

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

Le rôle project-bucket-object-admin dispose des autorisations de stockage d'objets suivantes :

  • Autorisations de stockage d'objets S3 :

    1. AbortMultipartUpload
    2. DeleteObject
    3. PutObject

Autorisations d'administrateur de bucket de projet

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

Le rôle project-bucket-object-admin dispose des autorisations suivantes :

  • Autorisations de l'API pour les buckets :

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