Gérer le stockage d'objets

Consignes de dénomination des buckets de stockage

Les noms de buckets doivent respecter les conventions de dénomination suivantes :

  • être unique dans le projet ; Un projet ajoute un préfixe unique au nom du bucket, ce qui évite les conflits au sein de l'organisation. Dans le cas peu probable où un préfixe et un nom de bucket entreraient en conflit entre plusieurs organisations, la création du bucket échouerait et l'erreur bucket name in use s'afficherait.
  • comporter au moins un caractère et pas plus de 57 ;
  • N'incluez aucune information permettant d'identifier personnellement l'utilisateur.
  • être conforme au DNS ;
  • Commencer par une lettre et ne contenir que des lettres, des chiffres et des traits d'union.

Installer l'outil s3cmd CLI

L'outil s3cmd est un outil de ligne de commande permettant de gérer le stockage d'objets.

  1. Pour télécharger l'outil, accédez au répertoire à partir duquel le package GDC a été extrait.
  2. Exécutez les commandes suivantes pour extraire l'image s3cmd, s3cmd.tar.tar.gz, dans un répertoire temporaire vide :

    tmpdir=$(mktemp -d)
    
    gdcloud artifacts extract oci/ $tmpdir \
      --image-name=$(gdcloud artifacts tree oci | grep s3cmd.tar | sed 's/^.* //')
    
  3. scp le fichier tar sur une machine cliente sur laquelle vous utilisez s3cmd pour les opérations sur les objets. Décompressez et installez l'image.

Choisissez l'une des méthodes d'installation suivantes pour installer l'outil s3cmd :

Installer à l'aide d'un fichier tar

  1. Pour décompresser l'archive et installer le package s3cmd, exécutez les commandes suivantes. Vous devez disposer du module Python distutils pour installer le package. Le module fait souvent partie du package Python de base, ou vous pouvez l'installer à l'aide de votre gestionnaire de packages.

    tar xvf /tmp/gpc-system-tar-files/s3cmd.tar.tar.gz
    cd /tmp/gpc-system-tar-files/s3cmd
    sudo python3 setup.py install
    
  2. Facultatif : Nettoyez les fichiers téléchargés :

    rm /tmp/gpc-system-tar-files/s3cmd.tar.tar.gz
    rm -r /tmp/gpc-system-tar-files/s3cmd
    

Installer avec une image Docker

  1. Pour installer l'image s3cmd, exécutez les commandes suivantes :

    docker load --input s3cmd-docker.tar
    export S3CFG=/EMPTY_FOLDER_PATH/
    alias s3cmd="docker run -it --net=host --mount=type=bind,source=/$S3CFG/,target=/g/
    s3cmd-docker:latest -c /g/s3cfg"
    
  2. Facultatif : Nettoyez les fichiers téléchargés :

    rm s3cmd-docker.tar
    
  3. Ajoutez l'exportation et l'alias au fichier .bashrc pour qu'ils soient conservés après le redémarrage du client.

Configurer l'outil s3cmd

Utilisez l'outil s3cmd pour les opérations basées sur les objets.

Exécutez la commande s3cmd --configure et spécifiez les éléments suivants :

  1. Clé d'accès : saisissez la clé d'accès obtenue à partir du secret dans Obtenir des identifiants d'accès.
  2. Clé secrète : saisissez la clé secrète obtenue à partir du secret dans Obtenir des identifiants d'accès.
  3. Région par défaut : appuyez sur ENTER.
  4. Point de terminaison S3 : saisissez le point de terminaison fourni par votre opérateur d'infrastructure (IO).
  5. Pour le style de nommage de bucket DNS, saisissez s3://%(bucket).
  6. Facultatif : Saisissez un mot de passe de chiffrement pour protéger les fichiers en transit.
  7. Dans "Chemin d'accès à GPG", saisissez /usr/bin/gpg.
  8. Saisissez Yes pour utiliser le protocole HTTPS.
  9. Appuyez sur Enter pour ne pas saisir le nom du serveur proxy.

Créer des buckets de stockage

Avant de commencer

Un espace de noms de projet gère les ressources de bucket dans le cluster d'administrateur racine. Vous devez disposer d'un projet pour créer un bucket. Pour créer un projet, consultez Créer un projet. Vous devez disposer des autorisations appropriées au niveau du bucket pour effectuer les opérations suivantes. Consultez Accorder l'accès à un bucket.

Créer un bucket

Pour créer un bucket, appliquez une spécification de bucket à l'espace de noms de votre projet :

    kubectl apply -f bucket.yaml

Voici un exemple de spécification de bucket :

    apiVersion: object.gdc.goog/v1alpha1
    kind: Bucket
    metadata:
      name: BUCKET_NAME
      namespace: NAMESPACE_NAME
    spec:
      description: DESCRIPTION
      storageClass: standard-rwo
      bucketPolicy :
        lockingPolicy :
          defaultObjectRetentionDays: RETENTION_DAY_COUNT

Pour en savoir plus, consultez la documentation de référence de l'API Bucket.

Lister les buckets de stockage

Pour lister tous les buckets auxquels vous avez accès dans un locataire de stockage d'objets donné, procédez comme suit :

  1. Exécutez les commandes suivantes pour lister tous les buckets :

    kubectl get buckets --all-namespaces
    kubectl get buckets --namespace NAMESPACE_NAME
    

Supprimer des buckets de stockage

Vous pouvez supprimer des buckets de stockage à l'aide de la CLI. Les buckets doivent être vides pour pouvoir être supprimés.

  1. Utilisez la commande GET ou DESCRIBE dans la section Afficher la configuration du bucket pour obtenir le nom complet du bucket.

  2. Si le bucket n'est pas vide, videz-le :

    s3cmd rm --recursive -—force s3://FULLY_QUALIFIED_BUCKET_NAME
    
  3. Supprimez le bucket vide :

    kubectl delete buckets/BUCKET_NAME --namespace NAMESPACE_NAME
    

Afficher la configuration du bucket

Utilisez l'une ou l'autre de ces commandes pour afficher les détails de configuration d'un bucket :

    kubectl describe buckets/BUCKET_NAME --namespace NAMESPACE_NAME
    kubectl get buckets/BUCKET_NAME --namespace NAMESPACE_NAME -o yaml

Définir une durée de conservation des objets

Par défaut, vous pouvez supprimer des objets à tout moment. Activez le verrouillage des objets avec une période de conservation pour empêcher la suppression de tous les objets du bucket pendant le nombre de jours spécifié. Vous ne pouvez pas supprimer un bucket tant que vous n'avez pas supprimé tous les objets après la période de conservation.

Vous devez activer le verrouillage d'objets lorsque vous créez le bucket. Vous ne pouvez pas activer ni désactiver le verrouillage des objets après avoir créé un bucket. Vous pouvez toutefois modifier la période de conservation par défaut des objets.

Vous pouvez créer un bucket avec ou sans activer le verrouillage d'objets. Si vous avez activé le verrouillage des objets, il est facultatif de spécifier une durée de conservation par défaut.

Pour modifier la durée de conservation, mettez à jour le champ Bucket.spec.bucketPolicy.lockingPolicy.defaultObjectRetentionDays dans la ressource Bucket.

Voici un exemple de mise à jour du champ dans la ressource Bucket :

apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: NAMESPACE_NAME
spec:
  description: "This bucket has a default retention period specified."
  storageClass: standard-rwo
  bucketPolicy :
    lockingPolicy :
      defaultObjectRetentionDays: RETENTION_DAY_COUNT
---
apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: NAMESPACE_NAME
spec:
  description: "This would enable object locking but not specify a default retention period."
  storageClass: standard-rwo
  bucketPolicy :
    lockingPolicy :
---
apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: NAMESPACE_NAME
spec:
  description: "This bucket does not have locking or retention enabled."
  storageClass: standard-rwo

Toute modification apportée à la période de conservation s'applique aux objets créés dans le bucket après la modification. Pour les objets préexistants, la période de conservation ne change pas.

Lorsque vous avez activé le verrouillage d'objet, si vous tentez d'écraser un objet, vous ajoutez une nouvelle version de l'objet. Vous pouvez récupérer les deux versions de l'objet. Pour savoir comment lister les versions d'objets, consultez ListObjectVersions dans la documentation Amazon Web Services : https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectVersions.html.

Pour créer un bucket WORM (Write-Once, Read-Many), consultez la section Bucket WORM.

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-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-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 cluster d'administrateur racine.

  1. Recherchez 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. Obtenez le contenu du secret correspondant pour accéder aux buckets :

    kubectl get -o yaml --namespace object-storage-access-keys secret
    object-storage-key-rm-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 s3cmd avec les informations obtenues.

Accéder au secret du compte de service

Pour un sujet de compte de service, le secret se trouve dans le même espace de noms que le bucket. 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-rm-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

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. DeleteObjectVersion
    4. PutObject
    5. RestoreObject

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

Créer un bucket WORM

Un bucket WORM garantit que rien d'autre n'écrase les objets et qu'ils sont conservés pendant une période minimale. La journalisation des audits est un exemple de cas d'utilisation pour un bucket WORM.

Pour créer un bucket WORM, procédez comme suit :

  1. Définissez une période de conservation lorsque vous créez le bucket. Par exemple, le bucket suivant a une période de conservation de 365 jours.

    apiVersion: object.gdc.goog/v1alpha1
    kind: Bucket
    metadata:
      name: foo logging-bucket
      namespace: foo-service
    spec:
      description: "Audit logs for foo"
      storageClass: standard-rwo
      bucketPolicy :
        lockingPolicy :
          defaultObjectRetentionDays: 365
    
  2. Attribuez le rôle project-bucket-object-viewer à tous les utilisateurs qui ont besoin d'un accès en lecture seule :

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      namespace: foo-service
      name: object-readonly-access
    roleRef:
      kind: Role
      name: project-bucket-object-viewer
      apiGroup: rbac.authorization.k8s.io
    subjects:
    - kind: ServiceAccount
      namespace: foo-service
      name: foo-log-processor
    - kind: User
      name: bob@example.com
      apiGroup: rbac.authorization.k8s.io
    
  3. Attribuez le rôle project-bucket-object-admin aux utilisateurs qui doivent écrire du contenu dans le bucket :

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      namespace: foo-service
      name: object-write-access
    roleRef:
      kind: Role
      name: project-bucket-object-viewer
      apiGroup: rbac.authorization.k8s.io
    subjects:
    - kind: ServiceAccount
      namespace: foo-service
      name: foo-service-account
    

Restaurer à partir du stockage d'objets vers le système de fichiers sur le stockage de blocs

Allouer un volume persistant

Pour restaurer des fichiers à partir d'un point de terminaison de stockage d'objets, procédez comme suit :

  1. Attribuez un volume persistant (PV) à cibler lors de la restauration. Utilisez une revendication de volume persistant (PVC) pour allouer le volume, comme indiqué dans l'exemple suivant :

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: restore-pvc
      namespace: restore-ns
    spec:
      storageClassName: standard-rwo
      accessModes:
    ReadWriteOnce
      resources:
        requests:
          storage: 1Gi # Need sufficient capacity for full restoration.
    
  2. Vérifiez l'état du PVC :

    kubectl get pvc restore-pvc -n restore-ns
    

    Une fois que le PVC est à l'état Bound, il est prêt à être utilisé dans le pod qui le réhydrate.

  3. Si un ensemble Stateful finit par consommer le PV, vous devez faire correspondre les PVC StatefulSet affichés. Les pods produits par StatefulSet consomment les volumes hydratés. L'exemple suivant montre des modèles de revendication de volume dans un StatefulSet nommé ss.

      volumeClaimTemplates:
      - metadata:
          name: pvc-name
        spec:
          accessModes: [ "ReadWriteOnce" ]
          storageClassName: standard-rwo
          resources:
            requests:
              storage: 1Gi
    
  4. Préallouez des PVC avec des noms tels que ss-pvc-name-0 et ss-pvc-name-1 pour vous assurer que les pods résultants consomment les volumes préalloués.

Hydrater le volume persistant (PV)

Une fois le PVC lié à un PV, démarrez Job pour remplir le PV :

apiVersion: batch/v1
kind: Job
metadata:
  name: transfer-job
  namespace: transfer
spec:
  template:
    spec:
      serviceAccountName: data-transfer-sa
      volumes:
      - name: data-transfer-restore-volume
        persistentVolumeClaim:
          claimName: restore-pvc
      containers:
      - name: storage-transfer-pod
        image: gcr.io/private-cloud-staging/storage-transfer:latest
        command: /storage-transfer
        args:
        - --src_endpoint=https://your-src-endpoint.com
        - --src_path=/your-src-bucket
        - --src_credentials=transfer/src-secret
        - --dst_path=/restore-pv-mnt-path
        - --src_type=s3
        - --dst_type=local
      volumeMounts:
      - mountPath: /restore-pv-mnt-path
        name: data-transfer-restore-volume

Une fois l'Job terminé, les données du bucket de stockage d'objets sont insérées dans le volume. Un autre pod peut consommer les données en utilisant les mêmes mécanismes standards pour monter un volume.