Conceda e obtenha acesso ao contentor de armazenamento para projetos

Esta página explica como gerir o acesso a contentores de armazenamento em projetos isolados do Google Distributed Cloud (GDC), para que as pessoas certas tenham as autorizações certas. Abrange os pré-requisitos e os passos para obter e conceder acesso de utilizadores e contas de serviço através de associações de funções e funções predefinidas. Estas informações permitem-lhe controlar eficazmente o acesso aos seus recursos de armazenamento e manter a segurança e a eficiência operacional.

Esta página destina-se a públicos-alvo como administradores de TI no grupo de operadores de infraestrutura ou programadores no grupo de operadores de aplicações que gerem as definições de acesso para contentores de armazenamento em ambientes isolados do GDC. Para mais informações, consulte o artigo Públicos-alvo para a documentação de projetos isolados do GDC.

Antes de começar

Um espaço de nomes do projeto gere os recursos do contentor no servidor da API Management. Tem de ter um projeto para trabalhar com contentores e objetos.

Conceda acesso ao contentor

Pode conceder acesso a recursos da API S3, como contentores e objetos nesses contentores, a sujeitos User e ServiceAccount através da criação e aplicação de RoleBindings que referenciam Roles predefinidas no servidor da API Management.

Nota: Group sujeitos não são compatíveis com a concessão de autorizações da API S3. Se especificar um sujeito Group num RoleBinding, as autorizações da API S3 não são concedidas aos membros do grupo, mas as autorizações da API Kubernetes podem continuar a ser aplicadas a sujeitos Group desta forma.

Nota: o acesso a grupos não é compatível com o sistema de controlo de acesso a objetos. Apenas reconhece e age sobre sujeitos dos tipos User ou ServiceAccount.

Funções predefinidas

• project-bucket-object-viewer: permite que um utilizador apresente todos os contentores no projeto, apresente os objetos nesses contentores e leia os objetos e os metadados dos objetos. Não permite operações de escrita em objetos. Por exemplo: carregar, substituir e eliminar. Tem acesso só de leitura a contentores de zona dupla na organização e nos respetivos projetos, bem como acesso só de leitura aos objetos nesses contentores.

• project-bucket-object-admin: permite que um utilizador apresente todos os contentores no projeto e faça operações de escrita e leitura em objetos. Por exemplo: carregar, substituir e eliminar. Tem acesso só de leitura a contentores de zona dupla na organização e nos respetivos projetos, bem como acesso de leitura e escrita aos objetos nesses contentores.

• project-bucket-admin: permite que os utilizadores geram todos os contentores no espaço de nomes indicado, bem como todos os objetos nesses contentores. Tem acesso só de leitura a contentores de zona dupla na organização e nos respetivos projetos, bem como acesso de leitura e escrita aos objetos nesses contentores.

Para ver uma lista completa das autorizações concedidas para as funções anteriores, consulte a secção Autorizações de funções predefinidas.

Tem de ter a função de administrador de IAM do projeto para poder criar associações de funções nesse projeto. Segue-se um exemplo de criação de um recurso RoleBinding que concede acesso a um utilizador e a uma conta de serviço:

1. Crie um ficheiro 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 o seguinte:

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

2. Aplique o ficheiro YAML:

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

Obtenha as credenciais de acesso ao contentor

Depois de conceder acesso a um contentor, são criadas as credenciais de acesso num Secret.

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

• Os valores para STORAGE_CLASS são:
  • std para a classe de armazenamento Standard.
• Os valores para SUBJECT_TYPE são:
  • user para utilizador.
  • sa para ServiceAccount.
• SUBJECT_HASH é o hash SHA256 codificado em base32 do nome do sujeito.

Por exemplo, o utilizador [e-mail] tem dois Secrets com os seguintes nomes:

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

Obtenha o acesso do utilizador

Para um sujeito de utilizador, o Secret está no espaço de nomes object-storage-access-keys no servidor da API Management.

1. Execute o seguinte comando para encontrar o nome do Secret:

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

   Recebe um resultado semelhante ao seguinte:

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

2. Obtenha o conteúdo do Secret correspondente para aceder aos contentores na classe de armazenamento Standard:

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

   Recebe um resultado semelhante ao seguinte:

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

3. Descodifique o ID da chave de acesso e o Secret:

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

   Recebe um resultado semelhante ao seguinte:

   0HX3O0YC2J722EJLPJEO
   Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT
   

4. Siga a secção Configure a gdcloud CLI com as informações resultantes.

Obtenha o acesso da conta de serviço

As credenciais do Secret S3 só são criadas e ficam disponíveis para serem obtidas se existir um contentor no espaço de nomes do projeto.

Nota: os utilizadores não podem executar cargas de trabalho, que são executadas como contas de serviço, no servidor da API Management onde os Secrets da chave de acesso das contas de serviço foram criados inicialmente. Os utilizadores não podem conceder às cargas de trabalho acesso a esses Secrets no servidor da API Management. Esses Secrets são propagados para os espaços de nomes do projeto nos clusters de utilizadores adequados, onde os utilizadores podem aceder aos mesmos (se tiverem as funções RBAC adequadas nesse projeto).

Para um sujeito de conta de serviço (SA), encontre o nome do Secret no cluster de utilizadores.

1. Para a classe de armazenamento standard, execute o seguinte comando para obter o nome do Secret:

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

2. Em seguida, pode procurar manualmente os nomes dos Secrets apresentados ou usar o comando grep para encontrar object-storage-key-(std|nl). Para a última opção, execute o seguinte:

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

3. Pode referenciar o Secret no seu pod como variáveis de ambiente ou ficheiros.

Autorizações de funções predefinidas

As funções predefinidas estão disponíveis no servidor da API global para acesso administrativo e operacional a contentores de zona dupla. Estas funções também concedem acesso a contentores zonais, mas apenas se for usado um recurso IAMRoleBinding em vez de um recurso RoleBinding ou ClusterRoleBinding. Para mais informações sobre as associações de funções, consulte o artigo Conceda e revogue o acesso.

Autorizações de project-bucket-object-viewer

Esta função concede autorizações para obter e apresentar objetos e metadados de objetos no contentor.

Segue-se uma lista de todas as autorizações de armazenamento de objetos que a Role project-bucket-object-viewer concede:

• Autorizações da API Bucket:

  1. get
  2. list
  3. watch

• Autorizações de armazenamento de objetos S3:

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

Autorizações de project-bucket-object-admin

Esta função concede autorizações para colocar e eliminar objetos, versões de objetos e etiquetas no contentor. Além disso, também concede todas as autorizações em project-bucket-object-viewer.

Segue-se uma lista de todas as autorizações de armazenamento de objetos adicionais que a Role concede:

• Autorizaçõ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

Autorizações de project-bucket-admin

Esta função concede autorizações para criar, atualizar ou eliminar recursos Bucket no espaço de nomes do projeto. Além disso, também concede todas as autorizações em project-bucket-object-admin.

Segue-se uma lista de autorizações adicionais que a Role concede:

• Autorizações da API Bucket:

  1. Create
  2. Update
  3. Delete