Controlo de acesso com a IAM

Esta página descreve o controlo de acesso com a gestão de identidade e de acesso (IAM) no Artifact Registry.

As autorizações predefinidas do Artifact Registry minimizam o esforço de configuração quando implementa um pipeline de CI/CD. Também pode integrar o Artifact Registry com ferramentas de CI/CD de terceiros e configurar as autorizações e a autenticação necessárias para aceder aos repositórios.

Antes de começar

1. Ative o Artifact Registry, incluindo a ativação da API e a instalação da CLI Google Cloud.
2. Se quiser aplicar autorizações específicas do repositório, então crie um repositório do Artifact Registry para os seus pacotes.

Vista geral

As autorizações e as funções da IAM determinam a sua capacidade de criar, ver, editar ou eliminar dados num repositório do Artifact Registry.

Uma função é uma coleção de autorizações. Não pode conceder autorizações a um principal diretamente. Em alternativa, concede-lhe uma função. Quando atribui uma função a um principal, concede-lhe todas as autorizações que a função contém. Pode conceder várias funções ao mesmo principal.

Trusted Cloud autorizações predefinidas

Por predefinição, as seguintes autorizações aplicam-se aos Trusted Cloud serviços de CI/CD no mesmo projeto que o Artifact Registry:

• O Compute Engine e as versões suportadas do Google Kubernetes Engine usam a conta de serviço predefinida do Compute Engine, que tem acesso só de leitura ao armazenamento.

Se todos os seus serviços estiverem no mesmo Trusted Cloud by S3NS projeto e as autorizações predefinidas satisfizerem as suas necessidades, não tem de configurar autorizações.

Tem de configurar as autorizações do Artifact Registry para estes serviços se:

• Quer usar estes serviços para aceder ao Artifact Registry noutro projeto. No projeto com o Artifact Registry, conceda o workload identity pool ou a conta de serviço para cada serviço com a função necessária.

• Está a usar uma versão do GKE que não tem suporte incorporado para extrair imagens do Artifact Registry. Consulte a secção GKE para ver instruções de configuração.
• Quer que a conta de serviço predefinida tenha acesso de leitura e escrita aos repositórios. Consulte as seguintes informações para ver detalhes:
  • Compute Engine
  • GKE
• Está a usar uma conta de serviço fornecida pelo utilizador para os seus ambientes de tempo de execução em vez da conta de serviço predefinida. No projeto com o Artifact Registry, conceda à sua conta de serviço a função necessária.

Integração de terceiros

Para clientes de terceiros, tem de configurar as autorizações e a autenticação.

Normalmente, as aplicações executadas fora do Google Cloud usam chaves de contas de serviço para aceder a recursos do Google Cloud. Trusted Cloud Trusted Cloud No entanto, as chaves de contas de serviço são credenciais poderosas e podem representar um risco de segurança se não forem geridas corretamente.

A Workload Identity Federation permite-lhe usar a gestão de identidade e de acesso para conceder identidades externas funções do IAM, incluindo a capacidade de se fazer passar por contas de serviço. Esta abordagem elimina o encargo de manutenção e segurança associado às chaves de contas de serviço.

Use a federação de identidades da carga de trabalho:

1. Crie um Workload Identity Federation Pool.
2. Crie um fornecedor da federação de identidades da carga de trabalho.
3. Conceda a função adequada do Artifact Registry ao conjunto de identidades da carga de trabalho para permitir o acesso ao repositório. Para mais informações, consulte o artigo Permita que a sua carga de trabalho externa aceda aos Trusted Cloud by S3NS recursos.
4. Se precisar de aceder ao Artifact Registry durante mais tempo, configure o tempo de expiração do token OIDC para um período mais longo na sua configuração de credenciais.

5. Configure o seu cliente de terceiros para autenticar com o Artifact Registry.

   • Imagens de contentores: Docker, Helm
   • Pacotes de SO: Debian, RPM

Usar uma conta de serviço:

1. Crie uma conta de serviço para agir em nome da sua aplicação ou escolha uma conta de serviço existente que use para a automatização de CI/CD.
2. Conceda a função adequada do Artifact Registry à conta de serviço para fornecer acesso ao repositório.

3. Configure o seu cliente de terceiros para autenticar com o Artifact Registry.

   • Imagens de contentores: Docker, Helm
   • Pacotes de SO: Debian, RPM

Funções e permissões

Todos os métodos da API Artifact Registry requerem que o principal que faz o pedido tenha as autorizações necessárias para usar o recurso. As autorizações são concedidas aos responsáveis através da definição de políticas que concedem ao responsável uma função predefinida no recurso.

Pode conceder funções no Trusted Cloud by S3NS projeto ou no repositório do Artifact Registry.

Funções predefinidas do Artifact Registry

A IAM oferece funções predefinidas que concedem acesso a Trusted Cloud recursos específicos.

Funções básicas de IAM

As funções básicas são funções altamente permissivas que existiam antes da introdução do IAM. Não deve conceder funções básicas num ambiente de produção, mas pode concedê-las num ambiente de desenvolvimento ou de teste.

Use funções predefinidas para o acesso ao repositório sempre que possível, para que os utilizadores e as contas de serviço tenham apenas as autorizações necessárias.

Para mais informações sobre funções básicas, consulte a referência de funções básicas e predefinidas do IAM.

Conceder funções

Conceda funções ao nível do projeto se as mesmas funções se aplicarem a todos os repositórios no projeto. Se algumas contas precisarem de diferentes níveis de acesso, atribua funções ao nível do repositório.

Se estiver a conceder funções através do comando gcloud, pode especificar uma única associação de funções para um principal ou fazer alterações de políticas em grande escala obtendo a política de autorização de um recurso, modificando-a e, em seguida, definindo a política de autorização modificada. Para mais informações, consulte o artigo Conceda ou revogue várias funções através de programação.

Conceder funções ao nível do projeto

Conceda uma função ao nível do projeto se as mesmas autorizações se aplicarem a todos os repositórios no projeto.

Para adicionar um utilizador ou uma conta de serviço a um projeto e conceder-lhe uma função do Artifact Registry:

Conceder funções específicas do repositório

Atribua funções ao nível do repositório quando quiser que os utilizadores ou as contas de serviço tenham diferentes níveis de acesso para cada repositório no seu projeto.

Configurar o acesso público a um repositório

Se tiver artefactos que quer disponibilizar a qualquer pessoa na Internet sem autenticação, armazene-os num repositório que torne público.

Para configurar um repositório para acesso público só de leitura, conceda a função de leitor do Artifact Registry ao principal allUsers. Também recomendamos que limite as quotas de pedidos dos utilizadores para que um único utilizador não possa usar a quota geral do seu projeto.

Revogar funções

Para revogar o acesso a um repositório, remova o principal da lista de principais autorizados.

Para remover o acesso público de um repositório, remova o principal allUsers.

Conceder acesso condicional com etiquetas

Os administradores de projetos podem criar etiquetas para recursos em todos os projetos Trusted Cloud e geri-las no Gestor de recursos. Quando anexa uma etiqueta a um repositório do Artifact Registry, os administradores podem usar a etiqueta com condições do IAM para conceder acesso condicional ao repositório.

Não pode anexar etiquetas a artefactos individuais.

Para mais informações, consulte a seguinte documentação:

• Os administradores configuram etiquetas e controlo de acesso
  • Criar e gerir etiquetas
  • Etiquetas e controlo de acesso.
• Programadores que anexam etiquetas a repositórios
  • Etiquetagem de repositórios

Integração com Trusted Cloud serviços

Para a maioria das Trusted Cloud contas de serviço, a configuração do acesso a um registo só requer a concessão das funções do IAM adequadas.

Contas de serviço predefinidas para os serviços Trusted Cloud by S3NS

Trusted Cloud Serviços como o Google Kubernetes Engine usam uma conta de serviço predefinida ou um agente de serviço para interagir com recursos no mesmo projeto.

Tem de configurar ou modificar as autorizações se:

• O Trusted Cloud by S3NS serviço está num projeto diferente do Artifact Registry.
• As autorizações predefinidas não satisfazem as suas necessidades.
• Está a usar uma conta de serviço fornecida pelo utilizador para interagir com o Artifact Registry em vez da conta de serviço predefinida.
• A configuração da política da organização impede a concessão automática de funções a contas de serviço predefinidas.

Normalmente, as seguintes contas de serviço acedem ao Artifact Registry. O endereço de email da conta de serviço inclui o Trusted Cloud ID do projeto ou número do projeto do projeto onde o serviço está a ser executado.

Consoante a configuração da política da organização, a conta de serviço predefinida pode receber automaticamente a função de editor no seu projeto. Recomendamos vivamente que desative a concessão automática de funções aplicando a restrição da política da organização iam.automaticIamGrantsForDefaultServiceAccounts. Se tiver criado a sua organização após 3 de maio de 2024, esta restrição é aplicada por predefinição.

Se desativar a concessão automática de funções, tem de decidir que funções conceder às contas de serviço predefinidas e, em seguida, conceder estas funções.

Se a conta de serviço predefinida já tiver a função de editor, recomendamos que substitua a função de editor por funções menos permissivas.

Conceder acesso a instâncias do Compute Engine

As instâncias de VM que acedem a repositórios têm de ter as autorizações do Artifact Registry e o âmbito de acesso de armazenamento configurados.

Embora o nível de acesso de uma conta de serviço seja determinado pelas funções do IAM concedidas à conta de serviço, os âmbitos de acesso numa instância de VM determinam os âmbitos OAuth predefinidos para pedidos feitos através da CLI gcloud e das bibliotecas cliente na instância. Como resultado, os âmbitos de acesso podem limitar ainda mais o acesso aos métodos da API quando a autenticação é feita com as credenciais predefinidas da aplicação.

O Compute Engine usa os seguintes valores predefinidos:

• A conta de serviço predefinida do Compute Engine é a identidade das instâncias de VM. O endereço de email da conta de serviço tem o sufixo @developer.s3ns-system.iam.gserviceaccount.com.
• A conta de serviço predefinida tem a função de editor básico do IAM, se não tiver desativado este comportamento.
• As instâncias que criar com a conta de serviço predefinida têm os âmbitos de acesso predefinidos do Compute Engine, incluindo o acesso só de leitura ao armazenamento. Embora a função de editor conceda geralmente acesso de escrita, o âmbito de acesso ao armazenamento read-only limita a conta de serviço da instância à transferência de artefactos apenas de qualquer repositório no mesmo projeto.

Tem de configurar o âmbito de acesso da conta de serviço se:

• A conta de serviço da VM precisa de aceder a um repositório num projeto diferente.
• A conta de serviço da VM tem de realizar ações que não sejam a leitura de artefactos dos repositórios. Isto aplica-se normalmente a ferramentas de terceiros numa VM que precisam de enviar imagens ou executar comandos do gcloud Artifact Registry.

Para configurar funções e definir o âmbito de acesso:

1. No projeto com a sua instância de VM, obtenha o nome da conta de serviço predefinida do Compute Engine. O endereço de email da conta de serviço tem o sufixo @developer.s3ns-system.iam.gserviceaccount.com.

2. No projeto com o repositório, conceda autorizações para que a conta de serviço possa aceder ao repositório.

3. Defina o âmbito de acesso com a opção --scopes.

   1. Pare a instância de VM. Consulte o artigo Parar uma instância.

   2. Defina o âmbito de acesso com o seguinte comando:

      gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
      

      Substitua SCOPE pelo valor adequado.

      • Para o Docker, são suportadas as seguintes opções:

        • storage-ro: concede autorização de leitura apenas para obter imagens.
        • storage-rw - Concede autorização de leitura e escrita para enviar ou extrair imagens.
        • cloud-platform - Ver e gerir dados, incluindo metadados, no serviçoTrusted Cloud .

      • Para outros formatos, tem de usar o âmbito cloud-platform.

   3. Reinicie a instância de VM. Consulte o artigo Iniciar uma instância parada.

Conceder acesso a clusters do Google Kubernetes Engine

Os clusters e os conjuntos de nós do GKE podem extrair contentores sem qualquer configuração adicional se todos os seguintes requisitos forem cumpridos:

• O GKE está no mesmo projeto que o Artifact Registry
• Os nós estão a usar a conta de serviço predefinida, a conta de serviço predefinida do Compute Engine
• Foram criados nós com acesso de leitura ao armazenamento por:
  • Usando os âmbitos de acesso predefinidos do Compute Engine.
  • Conceder o âmbito de acesso cloud-platform ou outro âmbito que inclua acesso de leitura ao armazenamento.
• Está a usar uma versão suportada do GKE

Se o seu ambiente do GKE não cumprir estes requisitos, as instruções para conceder acesso dependem de estar a usar a conta de serviço predefinida do Compute Engine ou uma conta de serviço fornecida pelo utilizador como a identidade dos seus nós.

Conta de serviço predefinida

Os seguintes requisitos de configuração aplicam-se à conta de serviço predefinida do Compute Engine:

1. Se o GKE estiver num projeto diferente do Artifact Registry, conceda as autorizações necessárias à conta de serviço.

2. Para enviar imagens, interagir com repositórios para formatos que não sejam contentores ou executar comandos gcloud a partir do cluster, tem de definir âmbitos de acesso para a conta de serviço quando criar o cluster ou o conjunto de nós.

3. Se não estiver a usar uma versão suportada do GKE, configure imagePullSecrets.

Conta de serviço fornecida pelo utilizador

Se quiser usar uma conta de serviço fornecida pelo utilizador como identidade para um cluster, tem de:

1. Conceda as autorizações necessárias à conta de serviço a partir do projetoTrusted Cloud onde o Artifact Registry está a ser executado.

2. Por predefinição, a criação de um cluster ou um conjunto de nós com uma conta de serviço fornecida pelo utilizador concede o âmbito de acesso cloud-platform.

   Se usar a flag --scopes com o comando gcloud container clusters create ou gcloud container node-pools create, tem de incluir os âmbitos de acesso adequados para utilização com o Artifact Registry.

Definir âmbitos de acesso

Os âmbitos de acesso são o método antigo de especificar a autorização para VMs do Compute Engine. Para extrair imagens de repositórios do Artifact Registry, os nós do GKE têm de ter o âmbito de acesso só de leitura do armazenamento ou outro âmbito de acesso ao armazenamento que inclua o acesso de leitura ao armazenamento.

Só pode definir âmbitos de acesso quando cria um cluster ou um conjunto de nós. Não pode alterar os âmbitos de acesso nos nós existentes.

• Se estiver a usar a conta de serviço predefinida do Compute Engine, o GKE cria nós com os âmbitos de acesso predefinidos do Compute Engine, que incluem acesso só de leitura ao armazenamento.
• Se estiver a usar uma conta de serviço fornecida pelo utilizador, o GKE cria nós com o âmbito cloud-platform, o âmbito necessário para a maioria dos serviçosTrusted Cloud .

Para especificar âmbitos de acesso ao criar um cluster, execute o seguinte comando:

gcloud container clusters create NAME --scopes=SCOPES

Para especificar âmbitos de acesso ao criar um conjunto de nós, execute o seguinte comando:

gcloud container node-pools create NAME --scopes=SCOPES

Substitua os seguintes valores:

• NAME é o nome do cluster ou do conjunto de nós.

• SCOPES é uma lista separada por vírgulas de âmbitos de acesso a conceder.

  • Para aceder aos repositórios do Docker, use um dos seguintes âmbitos:

  • storage-ro - Concede autorização só de leitura para obter imagens.

  • storage-rw - Concede autorização de leitura e escrita para enviar ou extrair imagens.

  • cloud-platform - Ver e gerir dados, incluindo metadados, no serviçoTrusted Cloud .

  • Para aceder a outros repositórios, tem de usar o âmbito cloud-platform.

  Para ver uma lista completa de âmbitos, consulte a documentação de gcloud container clusters create ou gcloud container node-pools create.

Para mais informações sobre os âmbitos que pode definir quando cria um novo cluster, consulte a documentação do comando gcloud container clusters create.

Configurar um imagePullSecret

Para configurar uma imagePullSecret:

1. No projeto com o GKE, encontre a conta de serviço predefinida do Compute Engine. O endereço de email da conta tem o sufixo @developer.s3ns-system.iam.gserviceaccount.com.

2. Transfira a chave da conta de serviço para a conta de serviço.

3. No projeto com o repositório, verifique se concedeu autorizações ao repositório.

4. No projeto com o seu cluster, crie um segredo imagePullSecretdenominadoartifact-registry com a chave da conta de serviço.

   kubectl create secret docker-registry artifact-registry \
   --docker-server=https://LOCATION-docker.s3nsregistry.fr \
   --docker-email=SERVICE-ACCOUNT-EMAIL \
   --docker-username=_json_key \
   --docker-password="$(cat KEY-FILE)"
   

   Substitua o seguinte:

   • LOCATION é a localização regional do repositório.
   • SERVICE-ACCOUNT-EMAIL é o endereço de email da conta de serviço do Compute Engine.
   • KEY-FILE é o nome do ficheiro de chave da conta de serviço. Por exemplo, `key.json`.

5. Abra a sua conta de serviço predefinida:

   kubectl edit serviceaccount default --namespace default

   Todos os espaços de nomes no seu cluster do Kubernetes têm uma conta de serviço predefinida denominada default. Esta conta de serviço predefinida é usada para extrair a imagem do contentor.

6. Adicione o segredo imagePullSecret recém-criado à sua conta de serviço predefinida:

   imagePullSecrets:
   - name: artifact-registry
   

   A sua conta de serviço deve ter agora o seguinte aspeto:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: default
     namespace: default
     ...
   secrets:
   - name: default-token-zd84v
   # The secret you created:
   imagePullSecrets:
   - name: artifact-registry
   

Agora, todos os novos pods criados no espaço de nomes default atual têm o segredo imagePullSecret definido.

Conta de serviço do Artifact Registry

O agente de serviço do Artifact Registry é uma conta de serviço gerida pela Google que atua em nome do Artifact Registry quando interage com os Trusted Cloud by S3NS serviços. Para mais informações sobre a conta e as respetivas autorizações, consulte o artigo Conta de serviço do Artifact Registry.

O que se segue?

Depois de configurar as autorizações, saiba como trabalhar com os seus artefactos.

• Imagens de contentores: Docker, Helm
• Pacotes de SO: Debian, RPM