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

Questa pagina ti guida nella gestione dell'accesso ai bucket di archiviazione all'interno dei progetti isolati di Google Distributed Cloud (GDC), in modo che le persone giuste dispongano delle autorizzazioni corrette. Vengono trattati i prerequisiti e i passaggi per ottenere e concedere l'accesso a utenti e account di servizio utilizzando i binding dei ruoli e i ruoli predefiniti. Queste informazioni ti consentono di controllare in modo efficace l'accesso alle risorse di archiviazione e di mantenere la sicurezza e l'efficienza operativa.

Questa pagina è rivolta a segmenti di pubblico come gli amministratori IT all'interno del gruppo di operatori dell'infrastruttura o gli sviluppatori all'interno del gruppo di operatori dell'applicazione che gestiscono le impostazioni di accesso per i bucket di archiviazione negli ambienti air-gap di GDC. Per saperne di più, consulta Segmenti di pubblico per la documentazione air-gapped di GDC.

Prima di iniziare

Uno spazio dei nomi del progetto gestisce le risorse bucket nel server API di gestione. Per lavorare con bucket e oggetti, devi avere un progetto.

Concedi l'accesso al bucket

Puoi concedere l'accesso alle risorse dell'API S3, come bucket e oggetti in questi bucket, ai soggetti User e ServiceAccount creando e applicando RoleBinding che fanno riferimento a ruoli predefiniti nel server dell'API Management.

Nota: i soggetti Group non sono supportati per la concessione delle autorizzazioni API S3. Se specifichi un Group soggetto 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 ai soggetti Group in questo modo.

Nota: l'accesso al gruppo 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 metadati degli oggetti. Non consente di scrivere operazioni sugli oggetti. Ad esempio: caricamento, sovrascrittura, eliminazione. Dispone dell'accesso di sola lettura ai bucket dual-zone 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 ed eseguire operazioni di scrittura e lettura sugli oggetti. Ad esempio, caricamento, sovrascrittura ed eliminazione. Dispone dell'autorizzazione di sola lettura sui bucket dual-zone all'interno dell'organizzazione e dei relativi progetti, nonché dell'autorizzazione di lettura/scrittura sugli 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 dual-zone all'interno dell'organizzazione e dei relativi progetti, nonché dell'accesso in lettura/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.

Per creare associazioni di ruoli in un progetto, devi disporre del ruolo Amministratore IAM progetto per il 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
   

Ottenere 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 del soggetto.

Ad esempio, l'utente [e-mail] ha due secret denominati:

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

Ottenere l'accesso utente

Per un soggetto 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 chiave di accesso e il secret:

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

   Riceverai un output simile al seguente:

   0HX3O0YC2J722EJLPJEO
   Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT
   

4. Segui la sezione Configura gcloud CLI con le informazioni risultanti.

Ottenere l'accesso al account di servizio

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

Nota :gli utenti non possono eseguire carichi di lavoro, che vengono eseguiti come service account, nel server API di gestione in cui sono stati creati inizialmente 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 Management. 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 soggetto account di servizio (SA), trova il nome del secret dal cluster utente.

1. Per la classe di archiviazione standard, esegui il comando seguente 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. Dopodiché, puoi esaminare manualmente i nomi dei segreti elencati o utilizzare grep per trovare object-storage-key-(std|nl). Per la seconda opzione, esegui questo comando:

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

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

Autorizzazioni dei ruoli preimpostate

I ruoli predefiniti sono disponibili nel server API globale per l'accesso amministrativo e operativo ai bucket dual-zone. Questi ruoli concedono anche l'accesso ai bucket di zona, ma solo se viene utilizzata una risorsa IAMRoleBinding anziché una risorsa RoleBinding o ClusterRoleBinding. Per saperne di più sulle associazioni di ruoli, consulta Concedere e revocare 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 degli oggetti concesse dal visualizzatore di progetti, bucket e oggetti Role:

• Autorizzazioni API bucket:

  1. get
  2. list
  3. guarda

• Autorizzazioni di archiviazione degli oggetti S3:

  1. GetObject
  2. GetObjectAcl
  3. GetObjectLegalHold
  4. GetObjectRetention
  5. GetObjectTagging
  6. GetObjectVersion
  7. GetObjectVersionTagging
  8. ListBucket
  9. ListBucketVersions
  10. ListBucketMultipartUploads
  11. ListMultipartUploadParts

project-bucket-object-admin permissions

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

Un elenco di tutte le autorizzazioni di archiviazione degli oggetti aggiuntive concesse da Role sono le seguenti:

• Autorizzazioni di archiviazione degli 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 risorse Bucket nello spazio dei nomi del progetto. Inoltre, concede anche tutte le autorizzazioni in project-bucket-object-admin.

Di seguito è riportato un elenco di autorizzazioni aggiuntive concesse da Role:

• Autorizzazioni API bucket:

  1. Crea
  2. Aggiorna
  3. Elimina