Controle de acesso com o IAM

Nesta página, descrevemos o controle de acesso com o Identity and Access Management (IAM) na o Artifact Registry.

As permissões padrão do Artifact Registry reduzem o esforço de configuração quando para implementar um pipeline de CI/CD. Também é possível integrar o Artifact Registry com ferramentas de CI/CD de terceiros e configurar as permissões e a autenticação para acessar repositórios.

Se você usa o Artifact Analysis para trabalhar com metadados de contêiner, como vulnerabilidades encontradas em imagens, consulte a Documentação do Artifact Analysis para mais informações sobre como conceder acesso para visualizar ou gerenciar metadados.

Antes de começar

1. Ative o Artifact Registry, incluindo ativar a API e instalar a Google Cloud CLI.
2. Se você quiser aplicar permissões específicas do repositório, Crie um repositório do Artifact Registry. para seus pacotes.

Visão geral

As permissões do IAM e Os papéis determinam sua capacidade de criar, visualizar editar ou excluir dados em um repositório do Artifact Registry.

Um papel é um conjunto de permissões. Não é possível conceder uma permissão principal diretamente. em vez disso, você concede a eles um papel. Quando você faz isso, concede ao principal todas as permissões contidas no papel. É possível atribuir vários papéis ao mesmo principal.

Permissões padrão do Google Cloud

Por padrão, as seguintes permissões se aplicam aos serviços de CI/CD do Google Cloud no mesmo projeto que o Artifact Registry:

• As permissões do Cloud Build incluem permissões para fazer upload e download de artefatos.
• O Compute Engine, as versões compatíveis do Google Kubernetes Engine e o Cloud Run usam a conta de serviço padrão do Compute Engine, que tem acesso somente de leitura ao armazenamento.

Se todos os serviços estiverem no mesmo projeto do Google Cloud e o padrão as permissões atenderem às suas necessidades, não será necessário configurá-las.

Você precisará configurar as permissões do Artifact Registry para esses serviços se:

• Você quiser usar esses serviços para acessar o Artifact Registry em outro projeto. No projeto com o Artifact Registry, conceda o pool de identidade da carga de trabalho ou conta de serviço para cada serviço que e o papel necessário. Se você se conectar ao Cloud Run, conceda a Agente de serviço do Cloud Run, o estado de rede.
• você está usando uma versão do GKE que não tem suporte para extração de imagens do Artifact Registry. Consulte a seção GKE para instruções de configuração
• Você quiser que a conta de serviço padrão tenha acesso de leitura e gravação aos repositórios. Consulte as seguintes informações para saber mais detalhes:
  • Compute Engine
  • GKE
• Você está usando uma conta de serviço fornecida pelo usuário para seus ambientes de execução. em vez da conta de serviço padrão. No projeto com o Artifact Registry, conceda à conta de serviço o papel necessário.

Integração de terceiros

Para clientes de terceiros, você precisa configurar as permissões e a autenticação.

Os aplicativos executados fora do Google Cloud costumam chaves de conta de serviço para acessar os recursos do Google Cloud. No entanto, as chaves de contas de serviço são credenciais avançadas e podem apresentar um risco de segurança quando não são gerenciadas corretamente.

A federação de identidade da carga de trabalho permite usar o Identity and Access Management para Conceder papéis do IAM a identidades externas, incluindo a capacidade de representar contas de serviço. Essa abordagem elimina a carga de manutenção e segurança associada aos serviços chaves de conta.

Usar a federação de identidade da carga de trabalho:

1. Crie um pool de federação de identidade da carga de trabalho.
2. Crie um provedor de federação de identidade da carga de trabalho.
3. Conceda o papel apropriado do Artifact Registry à carga de trabalho para permitir o acesso ao repositório.

4. Configurar seu cliente de terceiros para autenticação com o o Artifact Registry.

   • Imagens de contêiner: Docker, Helm (link em inglês)
   • Pacotes de idiomas: Javae Node.js Python, Go
   • Pacotes do SO: Debian, RPM
   • Outro: modelos do Kubeflow Pipelines

Usar uma conta de serviço:

1. Crie uma conta de serviço para agir em nome do seu aplicativo ou escolha uma conta de serviço atual que você usa para sua automação de CI/CD.
2. Conceda o papel apropriado do Artifact Registry à conta de serviço para fornecer acesso ao repositório.

3. Configurar seu cliente de terceiros para autenticação com o o Artifact Registry.

   • Imagens de contêiner: Docker, Helm (link em inglês)
   • Pacotes de idiomas: Javae Node.js Python, Go
   • Pacotes do SO: Debian, RPM
   • Outro: modelos do Kubeflow Pipelines

GitLab no Google Cloud

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

A integração do GitLab no Google Cloud usa Federação de identidade da carga de trabalho para autorização e autenticação cargas de trabalho do GitLab no Google Cloud sem a necessidade de contas de serviço ou chaves da conta de serviço. Para mais informações sobre como a federação de identidade da carga de trabalho é usado nesta parceria, consulte Visão geral da autenticação.

Para configurar a federação de identidade da carga de trabalho e as configurações Papéis do IAM para o GitLab no Google Cloud, consulte o tutorial do GitLab Políticas do IAM e da federação de identidade da carga de trabalho do Google Cloud.

Para conectar o repositório do Artifact Registry, siga o tutorial do GitLab Google Artifact Registry.

Papéis e permissões

Todo método da API Artifact Registry exige que o principal (usuário, grupo ou conta de serviço) que faz a solicitação tem as permissões necessárias para usar o recurso. As permissões são dadas aos principais definindo políticas que conceder ao principal um papel predefinido no recurso.

É possível conceder papéis no projeto do Google Cloud ou no Artifact Registry repositório de dados.

Papéis predefinidos do Artifact Registry

O IAM fornece papéis predefinidos que concedem acesso a recursos específicos do Google Cloud e impedem o acesso não autorizado a outros recursos.

Use os papéis predefinidos a seguir para papéis padrão, virtuais e remotos. repositórios no domínio pkg.dev:

Papel	Descrição
Leitor do Artifact Registry (roles/artifactregistry.reader)	Acessar e receber artefatos, ver metadados do repositório.
Gravador do Artifact Registry (roles/artifactregistry.writer)	Ler e gravar artefatos.
Administrador de repositórios do Artifact Registry (roles/artifactregistry.repoAdmin)	Ler, gravar e excluir artefatos.
Administrador do Artifact Registry (roles/artifactregistry.admin)	Criar e gerenciar repositórios e artefatos.

Os papéis predefinidos a seguir incluem permissões para criar Repositórios gcr.io para hospedar imagens do domínio gcr.io. O não incluem permissões para criar outros formatos de repositório no Artifact Registry no domínio pkg.dev. Esses papéis dão suporte a versões anteriores compatibilidade com o Container Registry, já que ele usa o primeiro envio de uma imagem de contêiner para criar cada registro multirregional.

Papel	Descrição
Gravador Create-on-push do Artifact Registry (roles/artifactregistry.createOnPushWriter)	Ler e gravar artefatos. Criar repositórios gcr.io.
Administrador de repositório de Create-on-push no Artifact Registry (roles/artifactregistry.createOnPushRepoAdmin)	Ler, gravar e excluir artefatos. Criar repositórios gcr.io.

Para uma lista completa das permissões individuais de cada papel, consulte Papéis do Artifact Registry. Você também pode usar o gcloud iam roles describe para conferir uma lista de permissões em cada papel.

Papéis básicos do IAM

Papéis básicos são papéis altamente permissivos que existiam antes da introdução do IAM. É possível usar papéis básicos para conceder aos principais aos recursos do Google Cloud.

Use papéis predefinidos para o repositório. acesso sempre que possível para que usuários e contas de serviço tenham apenas o as permissões necessárias.

Para mais informações sobre papéis básicos, consulte Referência dos papéis básicos e predefinidos do IAM.

Como conceder permissões

Conceda permissões no nível do projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto. Se algumas contas exigirem níveis de acesso diferentes, conceda papéis no nível do repositório.

Se você estiver concedendo permissões em um repositório virtual, essas essas permissões se aplicam a todos os repositórios upstream disponíveis por meio da repositório, independentemente das permissões individuais do repositório.

Para conceder papéis usando o comando gcloud, é possível especificar um único vinculação de papel para um principal ou use um arquivo de política para definir várias vinculações.

Observação: aplicar um arquivo de política a um projeto redefine todas as políticas do IAM para esse projeto. Portanto, use essa opção com cuidado.

Como conceder permissões em todo o projeto

Conceda um papel no nível do projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.

Para adicionar um usuário ou conta de serviço a um projeto e conceder a ele um Papel no Artifact Registry:

Console

1. Abra a página "IAM" no console do Google Cloud.

   Abrir a página do IAM

2. Clique em Selecionar um projeto, escolha o projeto em que o Artifact Registry está em execução e clique em Abrir.

3. Clique em Add.

4. Insira um endereço de e-mail. É possível adicionar indivíduos, contas de serviço ou Grupos do Google como participantes.

5. Selecione um papel para o principal. De acordo com a seção de segurança princípio de privilégio mínimo, considere conceder o mínimo de para acessar os recursos obrigatórios do Artifact Registry. Para informações sobre as permissões e os papéis predefinidos do Artifact Registry, consulte Papéis predefinidos do Artifact Registry.

6. Clique em Salvar.

gcloud

1. No Console do Google Cloud, ative o Cloud Shell.

   Ativar o Cloud Shell

   Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

2. Para conceder um papel a um único principal, execute o seguinte comando:

   gcloud projects add-iam-policy-binding PROJECT \
      --member=PRINCIPAL \
      --role=ROLE
   

   em que

   • PROJECT é o ID do projeto em que o Artifact Registry está sendo executado.

   • PRINCIPAL é o diretor para quem a vinculação deve ser adicionada. Use o formulário user|group|serviceAccount:email ou domain:domain.

     Exemplos: user:[e-mail], group:[e-mail], serviceAccount:[e-mail] ou domain:example.domain.com.

   • ROLE é o papel que você quer conceder.

   Para mais informações, consulte a documentação add-iam-policy-binding.

   Para conceder papéis usando um arquivo de política, execute o seguinte comando:

   gcloud projects set-iam-policy PROJECT /PATH/TO/policy.yaml

   Onde

   • PROJECT é o ID do projeto ou identificador totalmente qualificado para o projeto em que o Artifact Registry está em execução.
   • /PATH/TO/policy.yaml é o caminho e o nome do arquivo de política.
   .
   Observação: aplicar um arquivo de política a um projeto redefine todas as políticas do IAM políticas para esse projeto. Portanto, use essa opção com cuidado.

   Para conseguir a política configurada atualmente, execute o seguinte comando:

   gcloud projects get-iam-policy PROJECT

   Em que PROJECT é o ID do projeto ou identificador totalmente qualificado para o projeto.

   Para mais informações, consulte a documentação set-iam-policy.

Como conceder permissões específicas de repositório

Conceda permissões no nível do repositório quando quiser que os usuários ou as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.

Console

Para conceder acesso a um repositório específico:

1. Abra a página Repositórios no console do Google Cloud.

   Abrir a página Repositórios

2. Selecione o repositório apropriado.

3. Caso o painel de informações não seja exibido, clique em Mostrar painel de informações na barra de menu.

4. Na guia "Permissões", clique em Adicionar principal.

5. Insira um endereço de e-mail. É possível adicionar pessoas, contas de serviço Grupos como principais.

6. Selecione um papel para o principal. De acordo com a seção de segurança princípio de privilégio mínimo, considere conceder o mínimo de para acessar os recursos obrigatórios do Artifact Registry. Para informações sobre permissões e papéis predefinidos do Artifact Registry, consulte Papéis predefinidos do Artifact Registry.

7. Clique em Salvar.

gcloud

1. No Console do Google Cloud, ative o Cloud Shell.

   Ativar o Cloud Shell

   Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

2. É possível definir um conjunto de IAMs de vinculações de políticas individuais ou usar um arquivo de política.

   Para conceder um papel a um único principal, execute o seguinte comando:

   gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
      --location=LOCATION \
      --member=PRINCIPAL \
      --role=ROLE
   

   em que

   • REPOSITORY é o ID do repositório.

   • PRINCIPAL é o diretor para quem a vinculação deve ser adicionada. Use o formulário user|group|serviceAccount:email ou domain:domain.

     Exemplos: user:[e-mail], group:[e-mail], serviceAccount:[e-mail] ou domain:example.domain.com.

   • ROLE é o papel que você quer conceder.

   • LOCATION é o local regional ou multirregional do repositório.

   Por exemplo, para adicionar uma vinculação de política do IAM ao papel roles/artifactregistry.writer para o usuário [e-mail] com o repositório my-repo no local --us-central1, execute:

   gcloud artifacts repositories add-iam-policy-binding my-repo \
   --location=us-central1 --member=user:[e-mail] --role=roles/artifactregistry.writer
   

   Para conceder papéis usando um arquivo de política, execute o seguinte comando:

   gcloud artifacts repositories set-iam-policy REPOSITORY /PATH/TO/policy.yaml --location=LOCATION

   Onde

   • REPOSITORY é o ID do repositório.
   • /PATH/TO/policy.yaml é o caminho e o nome do arquivo de política.
   • LOCATION é o local regional ou multirregional do repositório.

   Por exemplo, para definir a política do IAM para o repositório my-repo no local --us-central1 com a política definida em policy.yaml, execute:

   gcloud artifacts repositories set-iam-policy my-repo policy.yaml --location=us-central1
   

   Observação: aplicar um arquivo de política a um repositório redefine todos políticas do IAM para esse repositório. Portanto, use essa opção com cuidado.

Terraform

Use o recurso google_artifact_registry_repository_iam para e configure uma política do IAM. O exemplo abaixo define um serviço conta com o nome de recurso repo-account e concede a ela acesso de leitura a um repositório com o nome de recurso my-repo.

Se você nunca usou o Terraform para Google Cloud, consulte a página Vamos começar - Google Cloud na site da HashiCorp.

provider "google" {
    project = "PROJECT-ID"
}

resource "google_artifact_registry_repository" "my-repo"     {
  provider = google-beta

  location = "LOCATION"
  repository_id = "REPOSITORY"
  description = "DESCRIPTION"
  format = "FORMAT"
}

resource "google_service_account" "repo-account" {
  provider = google-beta

  account_id   = "ACCOUNT-ID"
  display_name = "Repository Service Account"
}

resource "google_artifact_registry_repository_iam_member" "repo-iam" {
  provider = google-beta

  location = google_artifact_registry_repository.my-repo.location
  repository = google_artifact_registry_repository.my-repo.name
  role   = "roles/artifactregistry.reader"
  member = "serviceAccount:${google_service_account.repo-account.email}"
}

ACCOUNT-ID é o ID da conta de serviço. Essa é a parte do campo de e-mail da conta de serviço antes do símbolo @.

Para obter mais exemplos, consulte a documentação da google_artifact_registry_repository_iam recurso.

Como configurar o acesso público a um repositório

Se você tiver artefatos que quer disponibilizar para qualquer pessoa na Internet sem autenticação, armazene-os em um repositório público.

Para configurar um repositório para acesso público somente leitura, conceda ao Papel de Leitor do Artifact Registry para o allUsers principal. Também recomendamos limitar as cotas de solicitações de usuários para que um único usuário não poderá usar toda a cota geral do seu projeto.

Console

1. Abra a página Repositórios no console do Google Cloud.

   Abrir a página Repositórios

2. Selecione o repositório apropriado.

3. Caso o painel de informações não seja exibido, clique em Mostrar painel de informações na barra de menu.

4. Na guia "Permissões", clique em Adicionar principal.

5. No campo Novos principais, insira allUsers.

6. Selecione o papel Leitor do Artifact Registry.

7. Defina um limite por usuário nas solicitações da API Artifact Registry para evitar uso indevido por usuários não autenticados. Consulte Como limitar o uso para mais instruções.

gcloud

1. No Console do Google Cloud, ative o Cloud Shell.

   Ativar o Cloud Shell

   Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

2. Execute este comando:

   gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION --member=allUsers --role=ROLE
   

   em que

   • REPOSITORY é o ID do repositório.

   • ROLE é o papel que você quer conceder.

   • LOCATION é o local regional ou multirregional do repositório.

   Por exemplo, configure o repositório my-repo no local --us-central1 como público, execute:

   gcloud artifacts repositories add-iam-policy-binding my-repo \
    --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader
   

3. Defina um limite por usuário nas solicitações da API Artifact Registry para evitar uso indevido por usuários não autenticados. Consulte Como limitar o uso para mais instruções.

Como revogar permissões

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

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

Console

Para revogar as permissões:

1. Abra a página Repositórios no console do Google Cloud.

   Abrir a página Repositórios

2. Selecione o repositório apropriado.

3. Caso o painel de informações não seja exibido, clique em Mostrar painel de informações na barra de menu.

4. Na guia "Permissões", expanda o principal apropriado. Se você estão tornando um repositório público particular, expanda o principal allUsers.

5. Clique em Remover principal para revogar o acesso.

gcloud

1. No Console do Google Cloud, ative o Cloud Shell.

   Ativar o Cloud Shell

   Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

2. Para revogar um papel no nível do projeto, execute o seguinte comando:

   gcloud projects remove-iam-policy-binding PROJECT \
      --member=PRINCIPAL \
      --role=ROLE
   

   • PROJECT é o ID do projeto.

   • PRINCIPAL é o principal da qual remover a vinculação. Use o formulário user|group|serviceAccount:email ou domain:domain.

     Exemplos: user:[e-mail], group:[e-mail], serviceAccount:[e-mail] ou domain:example.domain.com.

   • ROLE é o papel que você quer revogar.

   Para revogar um papel para um repositório, execute o seguinte comando:

   gcloud artifacts repositories remove-iam-policy-binding REPOSITORY
      --location=LOCATION \
      --member=PRINCIPAL \
      --role=ROLE
   

   em que

   • REPOSITORY é o ID do repositório.

   • PRINCIPAL é o principal da qual remover a vinculação. Use o formulário user|group|serviceAccount:email ou domain:domain.

     Exemplos: user:[e-mail], group:[e-mail], serviceAccount:[e-mail] ou domain:example.domain.com.

     Para revogar o acesso público ao repositório, especifique o principal allUsers.

   • ROLE é o papel que você quer revogar.

   Por exemplo, para remover uma vinculação de política do papel roles/artifactregistry.writer para o usuário [e-mail] com o repositório my-repo no local --us-central1, execute:

   gcloud artifacts repositories remove-iam-policy-binding my-repo \
      --location=us-central1 \
      --member=user:[e-mail] \
      --role=roles/artifactregistry.writer

   Para revogar o acesso público a my-repo no local --us-central1, execute:

   gcloud artifacts repositories remove-iam-policy-binding my-repo \
      --location=us-central1 \
      --member=allUsers \
      --role=roles/artifactregistry.reader
   

Como conceder acesso condicional com tags

Os administradores do projeto podem criar tags para recursos no Google Cloud e gerenciá-las no Resource Manager. Quando você anexa uma tag a um repositório do Artifact Registry, os administradores podem usar a tag Condições do IAM para conceder acesso condicional ao repositório.

Não é possível anexar tags a artefatos individuais.

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

• Administradores configurando tags e controle de acesso
  • Como criar e gerenciar tags
  • Tags e controle de acesso.
• Desenvolvedores anexam tags aos repositórios
  • Repositórios de tags

Como integrar com os serviços do Google Cloud

Para a maioria das contas de serviço do Google Cloud, configurar o acesso a um registro requer apenas a concessão das permissões apropriadas do IAM.

Permissões padrão para serviços do Google Cloud

Os serviços do Google Cloud, como o Cloud Build ou o Google Kubernetes Engine, usam uma conta de serviço padrão ou Agente de serviço para interagir no mesmo projeto.

Você mesmo precisa configurar ou modificar permissões se:

• O serviço do Google Cloud está em um projeto diferente do Artifact Registry.
• As permissões padrão não atendem às suas necessidades. Por exemplo, o padrão A conta de serviço do Compute Engine tem acesso somente leitura ao armazenamento projeto. Para enviar uma imagem de uma VM para o Artifact Registry, podem modificar as permissões da conta de serviço da VM ou usar uma conta diferente com as permissões necessárias.
• se você usa uma conta de serviço fornecida pelo usuário para interagir o Artifact Registry em vez da conta de serviço padrão.

As contas de serviço a seguir geralmente acessam o Artifact Registry. O da conta de serviço inclui o endereço de e-mail do Google Cloud ID ou número do projeto do projeto em que o serviço está sendo executado.

Serviço	Conta de serviço	Endereço de e-mail	Permissões
Ambiente flexível do App Engine	App Engine conta de serviço	[e-mail]	Papel de editor, pode ler e gravar nos repositórios
Compute Engine	Conta de serviço padrão do Compute Engine	[e-mail]	Papel de editor, limitado ao acesso somente leitura a repositórios
Cloud Build	Serviço do Cloud Build conta	[e-mail] Observação:a conta de serviço padrão do Cloud Build usada para executar builds está sendo alterada. Para mais informações, consulte Alteração da conta de serviço do Cloud Build.	Permissões padrão incluem acesso de leitura e gravação aos repositórios Repositórios gcr.io.
Cloud Run	Agente de serviço do Cloud Run O agente de serviço para run.googleapis.com.	[e-mail]	Permissões de leitor, limitadas ao acesso somente leitura aos repositórios
GKE;	Conta de serviço padrão do Compute Engine A conta de serviço padrão para nós.	[e-mail]	Papel de editor, limitado ao acesso somente leitura a repositórios

Como conceder acesso a instâncias do Compute Engine

As instâncias de VM que acessam repositórios precisam ter permissões do Artifact Registry e escopo de acesso de armazenamento configurado.

O nível de acesso de uma conta de serviço é determinado papéis do IAM concedidos à conta de serviço, escopos de acesso em uma instância de VM determina os escopos padrão do OAuth para solicitações feitas por meio do CLI gcloud e bibliotecas de cliente na instância. Por isso, os escopos de acesso limitar ainda mais o acesso aos métodos de API ao autenticar com Application Default Credentials.

O Compute Engine usa os seguintes padrões:

• A conta de serviço padrão do Compute Engine é a identidade da VM instâncias. O endereço de e-mail da conta de serviço tem o sufixo @developer.gserviceaccount.com.
• A conta de serviço padrão tem o IAM básico Papel de editor, se você não desativou esse comportamento.
• As instâncias criadas com a conta de serviço padrão têm o Os escopos de acesso padrão do Compute Engine, incluindo acesso somente leitura ao armazenamento. O papel Editor geralmente concede gravação o escopo de acesso de armazenamento read-only limita o serviço da instância para fazer o download de artefatos somente de qualquer repositório no mesmo projeto.

Você precisará configurar o escopo de acesso da conta de serviço se:

• A conta de serviço da VM precisa acessar um repositório em outro projeto.
• A conta de serviço da VM precisa executar outras ações além de ler artefatos de repositórios. Isso geralmente aplica ferramentas de terceiros a uma VM que precisa enviar imagens ou executar comandos gcloud do Artifact Registry.

Para configurar permissões e definir o escopo de acesso:

1. No projeto com a instância de VM, veja o nome da conta de serviço padrão do Compute Engine. O endereço de e-mail da conta de serviço tem o sufixo @developer.gserviceaccount.com.

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

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

   1. Pare a instância de VM. Consulte Como interromper uma instância.

   2. Defina o escopo de acesso com o comando a seguir.

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

      Substitua SCOPE pelo valor adequado.

      • No Docker, as seguintes opções são compatíveis:

        • storage-ro: concede permissão de leitura apenas para extrair imagens.
        • storage-rw: concede permissão de leitura e gravação para enviar ou extrair imagens.
        • cloud-platform: visualiza e gerencie dados, incluindo metadados, no serviço do Google Cloud.

      • Para outros formatos, use o escopo cloud-platform.

   3. Reinicie a instância de VM. Consulte Como iniciar uma instância interrompida.

Como conceder acesso a clusters do Google Kubernetes Engine

Os clusters e os pools de nós do GKE podem extrair contêineres configuração adicional se todos os requisitos a seguir forem atendidos:

• O GKE está no mesmo projeto que o Artifact Registry
• Os nós estão usando a conta de serviço padrão, a conta de serviço padrão do Compute Engine
• Os nós foram criados com acesso de leitura ao armazenamento por:
  • Usar os escopos de acesso padrão do Compute Engine.
  • Como conceder o escopo de acesso cloud-platform ou outro escopo que inclua acesso de leitura ao armazenamento.
• você executa uma versão compatível do GKE;

Se o ambiente do GKE não atender a esses requisitos, instruções para conceder acesso dependem de você usar conta de serviço padrão do Compute Engine ou uma conta de serviço fornecida pelo usuário como a identidade dos nós.

Conta padrão de serviço

Os requisitos de configuração a seguir se aplicam à conta de serviço padrão do Compute Engine:

1. Se o GKE estiver em um projeto diferente Artifact Registry, concede as permissões necessárias para conta de serviço.

2. Para enviar imagens, interaja com repositórios para formatos diferentes de contêineres ou executar comandos gcloud do cluster, é preciso definir escopos de acesso da conta de serviço ao criar cluster ou pool de nós.

3. Se você não usa uma versão compatível do GKE, configure imagePullSecrets.

Conta de serviço fornecida pelo usuário

Se você quiser usar uma conta de serviço fornecida pelo usuário como a identidade de um cluster, é preciso:

1. Conceda as permissões necessárias à conta de serviço pelo Projeto do Google Cloud em que o Artifact Registry está sendo executado.

2. Por padrão, criar um cluster ou pool de nós com um serviço fornecido pelo usuário conta concede o escopo de acesso cloud-platform.

   Se você usar a sinalização --scopes com o gcloud container clusters create ou comando gcloud container node-pools create, você precisa incluir as escopos de acesso para uso com o Artifact Registry.

Como definir escopos de acesso

Os escopos de acesso são o método legado que especifica a autorização em VMs do Compute Engine. Para extrair imagens de repositórios do Artifact Registry, Os nós do GKE precisam ter o escopo de acesso somente leitura ao armazenamento ou e outro escopo de acesso ao armazenamento que inclui acesso de leitura.

Só é possível definir escopos de acesso ao criar um cluster ou pool de nós. Você não podem alterar os escopos de acesso nos nós existentes.

• Se você usa a conta de serviço padrão do Compute Engine, O GKE cria nós com a Compute Engine escopos de acesso padrão, que incluem acesso somente leitura a armazenamento.
• Se você usa uma conta de serviço fornecida pelo usuário, o GKE cria nós com o escopo cloud-platform, que é o escopo necessário para a maioria serviços do Google Cloud.

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

gcloud container clusters create NAME --scopes=SCOPES

Para especificar escopos de acesso ao criar um pool 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 pool de nós.

• SCOPES é uma lista separada por vírgulas de escopos de acesso a serem concedidos.

  • Para acessar os repositórios do Docker, use um dos seguintes escopos:

  • storage-ro: concede permissão somente leitura para extrair imagens.

  • storage-rw: concede permissão de leitura e gravação para enviar ou extrair imagens.

  • cloud-platform: visualiza e gerencie dados, incluindo metadados, no serviço do Google Cloud.

  • Para acessar outros repositórios, use o escopo cloud-platform.

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

Para mais informações sobre escopos que podem ser definidos ao criar um novo cluster, consulte a documentação do comando gcloud container clusters create.

Como configurar um imagePullSecret

Para configurar um imagePullSecret:

1. No projeto com o GKE, encontre o padrão do Compute Engine conta de serviço. O endereço de e-mail da conta tem o sufixo @developer.gserviceaccount.com.

2. Fazer o download da chave da conta de serviço para a conta de serviço.

   Observação: as chaves de conta de serviço poderão causar problemas de segurança se não forem gerenciadas corretamente. Sempre que possível, escolha uma alternativa mais segura para as chaves de conta de serviço. Caso seja necessário autenticar com uma chave de conta de serviço, você será responsável pela segurança da chave privada e por outras operações descritas em Práticas recomendadas para gerenciar chaves de contas de serviço. Se não for possível criar uma chave de conta de serviço, a criação pode ser desativada para sua organização. Para mais informações, consulte Gerenciar recursos da organização com segurança por padrão.

3. No projeto com o repositório, verifique se você concedeu permissões a ele.

4. No projeto com o cluster, crie um secret imagePullSecret chamado artifact-registry com a chave da conta de serviço.

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

   Onde

   • LOCATION é o local regional ou multirregional do repositório.
   • SERVICE-ACCOUNT-EMAIL é o endereço de e-mail da conta de serviço do Compute Engine.
   • KEY-FILE é o nome do arquivo de chave da conta de serviço. Por exemplo key.json.

5. Abra sua conta de serviço padrão:

   kubectl edit serviceaccount default --namespace default

   Cada namespace no cluster do Kubernetes tem uma conta de serviço padrão chamada default. Essa conta de serviço padrão é usada para extrair a imagem do contêiner.

6. Adicione o secret imagePullSecret recém-criado à sua conta de serviço padrão:

   imagePullSecrets:
   - name: artifact-registry
   

   Sua conta de serviço agora terá esta aparência:

   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 namespace default atual terão o secret imagePullSecret definido.

Conta de serviço do Artifact Registry

O agente de serviço do Artifact Registry é uma conta serviço gerenciado pelo Google que atua em nome do Artifact Registry ao interagir com o Google Cloud serviços. Para mais informações sobre a conta e suas permissões, consulte Conta de serviço do Artifact Registry.

A seguir

Depois de configurar as permissões, saiba mais sobre como trabalhar com os artefatos.

• Imagens de contêiner: Docker, Helm
• Pacotes de linguagem: Java, Node.js, Python, Go
• Pacotes do SO: Debian, RPM