Concedere e ottenere l'accesso al bucket di archiviazione

Questa pagina spiega come gestire l'accesso ai bucket di archiviazione all'interno dei progetti Google Distributed Cloud (GDC) con air gap, in modo che le persone giuste dispongano delle autorizzazioni corrette. Vengono illustrati i prerequisiti e i passaggi per ottenere e concedere l'accesso agli account utente e di servizio utilizzando associazioni di ruoli e ruoli predefiniti. Queste informazioni ti consentono di controllare in modo efficace l'accesso alle tue risorse di archiviazione e di mantenere sia la sicurezza che l'efficienza operativa.

Questa pagina è rivolta a utenti come gli amministratori IT del gruppo di operatori dell'infrastruttura o gli sviluppatori del gruppo di operatori delle applicazioni che gestiscono le impostazioni di accesso per i bucket di archiviazione negli ambienti GDC con air gap. Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC con air gap.

Prima di iniziare

Uno spazio dei nomi del progetto gestisce le risorse dei bucket nel server dell'API di gestione. Devi avere un progetto per lavorare con bucket e oggetti.

Concedi l'accesso al bucket

Puoi concedere l'accesso alle risorse dell'API S3, come i bucket e gli oggetti al loro interno, ai soggetti User e ServiceAccount creando e applicando RoleBinding che fanno riferimento ai ruoli predefiniti nel server dell'API di gestione.

Ruoli predefiniti

  • project-bucket-object-viewer: consente a un utente di elencare tutti i bucket nel progetto, elencare gli oggetti in questi bucket e leggere gli oggetti e i relativi metadati. Non consente di scrivere operazioni sugli oggetti. Ad esempio: caricamento, sovrascrittura, eliminazione. Dispone dell'accesso di sola lettura ai bucket a doppia regione all'interno dell'organizzazione e dei relativi progetti, nonché dell'accesso di sola lettura agli oggetti in questi bucket.

  • project-bucket-object-admin: consente a un utente di elencare tutti i bucket nel progetto e di eseguire operazioni di scrittura e lettura sugli oggetti. Ad esempio: caricamento, sovrascrittura, eliminazione. Dispone dell'accesso di sola lettura ai bucket a doppia regione all'interno dell'organizzazione e dei relativi progetti, nonché dell'accesso di lettura e scrittura agli oggetti in questi bucket.

  • project-bucket-admin: consente agli utenti di gestire tutti i bucket nello spazio dei nomi specificato, nonché tutti gli oggetti in questi bucket. Dispone dell'accesso di sola lettura ai bucket a doppia regione all'interno dell'organizzazione e dei relativi progetti, nonché dell'accesso di lettura e scrittura agli oggetti in questi bucket.

Per visualizzare un elenco completo delle autorizzazioni concesse per i ruoli precedenti, consulta la sezione Autorizzazioni dei ruoli predefiniti.

Devi disporre del ruolo Amministratore progetto IAM per il progetto per creare associazioni di ruoli in quel progetto. Di seguito è riportato un esempio di creazione di una risorsa RoleBinding che concede l'accesso a un utente e a un account di servizio:

  1. Crea un file YAML sul tuo sistema, ad esempio 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: PROJECT_NAMESPACE
      name: readwrite-all-buckets
    roleRef:
      kind: Role
      name: project-bucket-object-admin
      apiGroup: rbac.authorization.k8s.io
    subjects:
    - kind: ServiceAccount
      namespace: PROJECT_NAMESPACE
      name: SA_NAME
    - kind: User
      namespace: PROJECT_NAMESPACE
      name: bob@example.com
      apiGroup: rbac.authorization.k8s.io
      # Could be bob or bob@example.com based on your organization settings.
    

    Sostituisci quanto segue:

    • PROJECT_NAMESPACE: il nome dello spazio dei nomi del progetto
    • SA_NAME: il nome del account di servizio

  2. Applica il file YAML:

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

Ottieni le credenziali di accesso al bucket

Una volta concesso l'accesso a un bucket, vengono create le credenziali di accesso in un secret. Le credenziali sono necessarie per configurare l'interfaccia a riga di comando di Distributed Cloud ed eseguire i comandi per interagire con il bucket.

Il formato del nome del secret è object-storage-key-STORAGE_CLASS-SUBJECT_TYPE-SUBJECT_HASH.

  • I valori per STORAGE_CLASS sono:
    • std per la classe di archiviazione Standard.
  • I valori per SUBJECT_TYPE sono:
    • user per l'utente.
    • sa per ServiceAccount.
  • SUBJECT_HASH è l'hash SHA256 con codifica base32 del nome dell'oggetto.

Ad esempio, l'utente bob@foo.com ha un secret denominato:

object-storage-key-std-user-l74gbpyrsbmwy4mivocr3nur6dzrnhcfhe3otyplul42i732aama

Ottieni le credenziali di accesso utente

Per un oggetto utente, il secret si trova nello spazio dei nomi object-storage-access-keys nel server dell'API di gestione.

  1. Esegui questo comando per elencare le risorse Secret che hai l'autorizzazione di visualizzare nello spazio dei nomi object-storage-access-keys:

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

    Se puoi visualizzare i secret in questo spazio dei nomi, vedrai un output che contiene uno o più nomi di secret che iniziano con object-storage-key-, simile al seguente:

    secrets        []        [object-storage-key-std-user-l74gbpyrsbmwy4mivocr3nur6dzrnhcfhe3otyplul42i732aama]        [get]
    
    • NOTA: se sei un amministratore con l'autorizzazione per visualizzare tutte le risorse Secret o impersonare altri utenti, puoi eseguire uno dei seguenti comandi per trovare il nome dei secret per un utente specificato:

      Elenca tutti i secret appartenenti a un utente specificato:

      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'
      

      Impersona un utente per vedere quali secret può visualizzare:

      export USER_NAME=bob@example.com
      kubectl auth can-i --list --namespace object-storage-access-keys --as "${USER_NAME:?}" | grep "object-storage-key-"
      
  2. Recupera i contenuti del secret corrispondente:

    kubectl get -o yaml --namespace object-storage-access-keys secret SECRET_NAME
    

    Riceverai un output simile al seguente:

    data:
      access-key-id: MEhYM08wWUMySjcyMkVKTFBKRU8=
      create-time: MjAyMi0wNy0yMiAwMTowODo1OS40MTQyMTE3MDMgKzAwMDAgVVRDIG09KzE5OTAuMzQ3OTE2MTc3
      secret-access-key: Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==
    
  3. Decodifica l'ID e il secret della chiave di accesso:

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

    Riceverai un output simile al seguente:

    0HX3O0YC2J722EJLPJEO
    Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT
    
  4. Segui la sezione Configura la CLI gdcloud con le informazioni risultanti.

Ottieni l'accesso al account di servizio

Le credenziali secret S3 vengono create e sono disponibili per l'acquisizione solo se esiste un bucket nello spazio dei nomi del progetto.

Per un oggetto account di servizio (SA), il secret viene creato nello stesso spazio dei nomi del account di servizio.

Esegui questo comando per verificare che puoi ottenere ed elencare le risorse Secret nello spazio dei nomi. Se non è così, contatta l'amministratore:

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

Per trovare il nome del secret, esegui:

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'

Riceverai un output simile al seguente:

object-storage-key-std-sa-mng3olp3vsynhswzasowzu3jgzct2ert72pjp6wsbzqhdwckwzbq

Puoi fare riferimento al secret nel pod come variabili di ambiente o file.

Autorizzazioni dei ruoli predefiniti

Tieni presente che i ruoli predefiniti sono disponibili anche nel server API globale per l'accesso amministrativo e operativo ai bucket a doppia regione.

Autorizzazioni project-bucket-object-viewer

Questo ruolo concede le autorizzazioni per recuperare ed elencare gli oggetti e i relativi metadati nel bucket.

Di seguito è riportato un elenco di tutte le autorizzazioni di archiviazione di oggetti concesse dal verbo project-bucket-object-viewer:

  • Autorizzazioni API per i bucket:

    1. get
    2. list
    3. guarda
  • Autorizzazioni di archiviazione di oggetti 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

Autorizzazioni project-bucket-object-admin

Questo ruolo concede le autorizzazioni per inserire ed eliminare oggetti, versioni degli oggetti e tag nel bucket. Inoltre, concede tutte le autorizzazioni in project-bucket-object-viewer.

Di seguito è riportato un elenco di tutte le autorizzazioni aggiuntive per l'archiviazione di oggetti concesse dal ruolo:

  • Autorizzazioni di archiviazione di oggetti S3:

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

autorizzazioni project-bucket-admin

Questo ruolo concede le autorizzazioni per creare, aggiornare o eliminare le risorse Bucket nello spazio dei nomi del progetto. Inoltre, concede tutte le autorizzazioni in project-bucket-object-admin.

Di seguito è riportato un elenco di autorizzazioni aggiuntive concesse dal ruolo:

  • Autorizzazioni API per i bucket:

    1. Crea
    2. Aggiorna
    3. Elimina