Concedere e ottenere l'accesso al bucket di archiviazione per i progetti

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 le associazioni dei ruoli e i 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 segmenti di pubblico 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.

Nota: i soggetti Group non sono supportati per la concessione delle autorizzazioni API S3. Se specifichi un oggetto Group in un RoleBinding, le autorizzazioni dell'API S3 non verranno concesse ai membri del gruppo, ma le autorizzazioni dell'API Kubernetes possono comunque essere applicate agli oggetti Group in questo modo.

Nota: l'accesso ai gruppi non è supportato dal sistema di controllo dell'accesso dell'accesso agli oggetti. Riconosce e agisce solo su soggetti di tipo User o ServiceAccount.

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 in sola lettura ai bucket a doppia regione all'interno dell'organizzazione e dei relativi progetti, nonché dell'accesso in 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 al loro interno. 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 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: [e-mail]
     apiGroup: rbac.authorization.k8s.io
     # Could be bob or [e-mail] 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.

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 [e-mail] ha due secret denominati:

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

Ottenere l'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 trovare il nome del secret:

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

   Riceverai un output simile al seguente:

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

2. Recupera i contenuti del secret corrispondente per accedere ai bucket nella classe di archiviazione Standard:

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

   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 rese disponibili solo se esiste un bucket nello spazio dei nomi del progetto.

Nota: gli utenti non sono autorizzati a eseguire workload, che vengono eseguiti come service account, nel server dell'API di gestione in cui sono stati inizialmente creati i secret delle chiavi di accesso dei service account. Gli utenti non potranno concedere ai workload l'accesso a questi secret nel server dell'API di gestione. Questi secret verranno propagati agli spazi dei nomi del progetto nei cluster utente appropriati, dove gli utenti potranno accedervi (se dispongono dei ruoli RBAC appropriati all'interno del progetto).

Per un oggetto account di servizio (SA), trova il nome del secret dal cluster utente.

1. Per la classe di archiviazione standard, esegui questo comando per ottenere il nome del secret:

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

2. Esamina manualmente i nomi dei secret elencati o utilizza grep per trovare object-storage-key-(std|nl):

   kubectl get -n=PROJECT_NAME \
       serviceaccount SA_NAME \
       -o=jsonpath='{.secrets}{"\n"}' | grep -E 'object-storage-key-(std|nl)'
   

   Sostituisci quanto segue:

   • PROJECT_NAME: il nome del progetto.
   • SA_NAME: il nome del tuo account di servizio.

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

Autorizzazioni dei ruoli preimpostati

I ruoli predefiniti sono disponibili nel server API globale per l'accesso amministrativo e operativo ai bucket dual-region. Questi ruoli concedono anche l'accesso ai bucket a livello di zona, ma solo se viene utilizzata una risorsa IAMRoleBinding anziché una risorsa RoleBinding o ClusterRoleBinding. Per saperne di più sulle associazioni dei ruoli, consulta Concedi e revoca l'accesso.

Autorizzazioni project-bucket-object-viewer

Questo ruolo concede le autorizzazioni per ottenere 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 ruolo project-bucket-object-viewer Role:

• Autorizzazioni API per i bucket:

  1. get
  2. list
  3. guarda

• Autorizzazioni di archiviazione di oggetti S3:

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

• 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 da Role:

• Autorizzazioni API per i bucket:

  1. Crea
  2. Aggiorna
  3. Elimina