Conceder e obter acesso ao bucket de armazenamento

Esta página orienta você sobre como gerenciar o acesso a buckets de armazenamento em projetos isolados do Google Distributed Cloud (GDC) para que as pessoas certas tenham as permissões adequadas. Ela aborda os pré-requisitos e as etapas para receber e conceder acesso de usuários e conta de serviço usando vinculações de papéis e papéis predefinidos. Essas informações permitem controlar o acesso aos recursos de armazenamento e manter a segurança e a eficiência operacional.

Esta página é destinada a públicos-alvo, como administradores de TI no grupo de operadores de infraestrutura ou desenvolvedores no grupo de operadores de aplicativos que gerenciam as configurações de acesso para buckets de armazenamento em ambientes GDC com isolamento físico. Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.

Antes de começar

Um namespace do projeto gerencia recursos de bucket no servidor da API Management. É necessário ter um projeto para trabalhar com buckets e objetos.

Conceder acesso ao bucket

É possível conceder acesso a recursos da API S3, como buckets e objetos nesses buckets, a assuntos User e ServiceAccount criando e aplicando RoleBindings que fazem referência a papéis predefinidos no servidor da API Management.

Observação: os assuntos Group não são aceitos para conceder permissões da API S3. Se você especificar um assunto Group em um RoleBinding, as permissões da API S3 não serão concedidas aos membros do grupo, mas as permissões da API Kubernetes ainda poderão ser aplicadas a assuntos Group dessa maneira.

Observação: o acesso ao grupo não é aceito pelo sistema de controle de acesso a objetos. Ele só reconhece e age em assuntos dos tipos User ou ServiceAccount.

Papéis predefinidos

• project-bucket-object-viewer::permite que um usuário liste todos os buckets no projeto, liste objetos nesses buckets e leia objetos e metadados de objetos. Não permite operações de gravação em objetos. Por exemplo: upload, substituição, exclusão. Tem acesso somente leitura a buckets de zona dupla na organização e nos projetos dela, bem como acesso somente leitura aos objetos nesses buckets.

• project-bucket-object-admin::permite que um usuário liste todos os buckets no projeto e grave e leia operações em objetos. Por exemplo: upload, substituição, exclusão. Tem acesso somente leitura a buckets de zona dupla na organização e nos projetos dela, bem como acesso de leitura e gravação aos objetos nesses buckets.

• project-bucket-admin::permite que os usuários gerenciem todos os buckets no namespace especificado, bem como todos os objetos nesses buckets. Tem acesso somente leitura a buckets de zona dupla na organização e nos projetos dela, bem como acesso de leitura e gravação aos objetos nesses buckets.

Para conferir uma lista completa das permissões concedidas para os papéis anteriores, consulte a seção Permissões de papéis predefinidos.

É necessário ter o papel de Administrador de IAM do projeto para criar vinculações de papéis nele. Confira abaixo um exemplo de como criar um recurso RoleBinding que concede acesso a um usuário e a uma conta de serviço:

1. Crie um arquivo YAML no seu sistema, como 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.
   

   Substitua:

   • PROJECT_NAMESPACE: o nome do namespace do projeto
   • SA_NAME: o nome da conta de serviço

2. Aplique o arquivo YAML:

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

Receber credenciais de acesso ao bucket

Depois de conceder acesso a um bucket, ele cria as credenciais de acesso em um secret. As credenciais são necessárias para configurar a CLI do Distributed Cloud e executar comandos para interagir com o bucket.

O formato do nome do secret é object-storage-key-STORAGE_CLASS-SUBJECT_TYPE-SUBJECT_HASH.

• Os valores de STORAGE_CLASS são:
  • std para a classe de armazenamento Standard.
• Os valores de SUBJECT_TYPE são:
  • user para o usuário.
  • sa para a conta de serviço.
• SUBJECT_HASH é o hash SHA256 codificado em base32 do nome do assunto.

Por exemplo, o usuário [e-mail] tem um secret chamado:

object-storage-key-std-user-l74gbpyrsbmwy4mivocr3nur6dzrnhcfhe3otyplul42i732aama

Receber credenciais de acesso do usuário

Para um assunto de usuário, o secret está no namespace object-storage-access-keys no servidor da API Management.

1. Execute o comando a seguir para listar os recursos de secret que você tem permissão para visualizar no namespace object-storage-access-keys:

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

   Se você puder visualizar secrets nesse namespace, verá uma saída que contém um ou mais nomes de secret que começam com object-storage-key-, semelhante a esta:

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

   • OBSERVAÇÃO: se você for um administrador com permissão para visualizar todos os recursos de secret ou representar outros usuários, poderá executar um dos comandos a seguir para encontrar o nome dos secrets de um usuário especificado:

     Liste todos os secrets pertencentes a um usuário especificado:

     export USER_NAME=[e-mail]
     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'
     

     Represente um usuário para conferir quais secrets ele pode visualizar:

     export USER_NAME=[e-mail]
     kubectl auth can-i --list --namespace object-storage-access-keys --as "${USER_NAME:?} | grep "object-storage-key-"
     

2. Receba o conteúdo do secret correspondente:

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

   Você vai receber uma saída semelhante a esta:

   data:
     access-key-id: MEhYM08wWUMySjcyMkVKTFBKRU8=
     create-time: MjAyMi0wNy0yMiAwMTowODo1OS40MTQyMTE3MDMgKzAwMDAgVVRDIG09KzE5OTAuMzQ3OTE2MTc3
     secret-access-key: Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==
   

3. Decodifique o ID da chave de acesso e o secret:

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

   Você vai receber uma saída semelhante a esta:

   0HX3O0YC2J722EJLPJEO
   Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT
   

4. Siga a seção Configurar a CLI gdcloud com as informações resultantes.

Receber acesso à conta de serviço

As credenciais secretas do S3 só são criadas e ficam disponíveis para serem recebidas se um bucket existir no namespace do projeto.

**Observação** :os usuários não podem executar cargas de trabalho, que são executadas como contas de serviço, no servidor da API Management em que os secrets da chave de acesso das contas de serviço foram criados inicialmente. Os usuários não podem conceder acesso a essas cargas de trabalho aos secrets no servidor da API Management. Esses secrets serão propagados para os namespaces do projeto nos clusters de usuários apropriados, em que os usuários poderão acessá-los (se tiverem os papéis RBAC adequados nesse projeto).

Para um assunto de conta de serviço (SA), o secret é criado no mesmo namespace da conta de serviço.

Execute o comando a seguir para verificar se é possível receber e listar recursos de secret no namespace. Entre em contato com o administrador se esse não for o caso:

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

Para encontrar o nome do secret, execute:

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'

Você vai receber uma saída semelhante a esta:

object-storage-key-std-sa-mng3olp3vsynhswzasowzu3jgzct2ert72pjp6wsbzqhdwckwzbq

É possível fazer referência ao secret no pod como variáveis de ambiente ou arquivos.

Permissões de papéis predefinidos

Os papéis predefinidos também estão disponíveis no servidor da API global para acesso administrativo e operacional a buckets de zona dupla.

Permissões de project-bucket-object-viewer

Esse papel concede permissões para receber e listar objetos e metadados de objetos no bucket.

Confira abaixo uma lista de todas as permissões de armazenamento de objetos que o verbo project-bucket-object-viewer concede:

• Permissões da API Bucket:

  1. get
  2. list
  3. assistir

• Permissões de armazenamento de objetos 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

Permissões de project-bucket-object-admin

Esse papel concede permissões para colocar e excluir objetos, versões de objetos e tags no bucket. Além disso, ele também concede todas as permissões em project-bucket-object-viewer.

Confira abaixo uma lista de todas as permissões adicionais de armazenamento de objetos que o papel concede:

• Permissões de armazenamento de objetos S3:

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

Permissões de project-bucket-admin

Esse papel concede permissões para criar, atualizar ou excluir recursos de bucket no namespace do projeto. Além disso, ele também concede todas as permissões em project-bucket-object-admin.

Confira abaixo uma lista de permissões adicionais que o papel concede:

• Permissões da API Bucket:

  1. Criar
  2. Atualizar
  3. Delete