Controle de acesso com o IAM

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

As permissões padrão do Artifact Registry minimizam o esforço de configuração ao 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 necessárias 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 e saiba como conceder acesso para visualizar ou gerenciar metadados.

Antes de começar

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

Visão geral

As permissões e papéis do IAM 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.

Google Cloud permissões padrão

Por padrão, as seguintes permissões se aplicam aos serviços de CI/CD 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.

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

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

  • Você está usando uma versão do GKE que não tem suporte integrado para extrair imagens do Artifact Registry. Consulte a seção do 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:
  • 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, é necessário configurar as permissões e a autenticação.

Tradicionalmente, os aplicativos executados fora do Google Cloud usam chaves de conta de serviço para acessar 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 sobrecarga de manutenção e segurança associada às chaves de conta de serviço.

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 ao pool de identidades da carga de trabalho para permitir o acesso ao repositório. Para mais informações, consulte Permitir que sua carga de trabalho externa acesse recursos do Google Cloud .
  4. Se você precisar acessar o Artifact Registry por mais tempo, configure um período mais longo para a expiração do token OIDC na sua configuração de credenciais.

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

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. Configure o cliente de terceiros para se autenticar com o Artifact Registry.

GitLab no Google Cloud

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

Para configurar a federação de identidade da carga de trabalho e os papéis do IAM necessários para o GitLab em Google Cloud, consulte o tutorial do GitLab Google Cloud Federação de identidade da carga de trabalho e políticas do IAM.

Para conectar seu 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 que faz a solicitação tenha as permissões necessárias para usar o recurso. As permissões são concedidas aos principais ao definir políticas que concedem a eles uma função predefinida no recurso.

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

Papéis predefinidos do Artifact Registry

O IAM fornece papéis predefinidos que concedem acesso a recursos específicos do Google Cloud .

Use os seguintes papéis predefinidos para repositórios no domínio pkg.dev:
Papel Descrição
Leitor do Artifact Registry
(roles/artifactregistry.reader)		 Ver e receber artefatos, ver metadados do repositório.
Gravador do Artifact Registry
(roles/artifactregistry.writer)		 Ler e gravar artefatos.
Administrador do repositório 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 seguintes papéis predefinidos adicionais contêm as permissões necessárias para migrar do Container Registry para o Artifact Registry.

Papel Descrição
Administrador de migração do Container Registry para o Artifact Registry (roles/artifactregistry.containerRegistryMigrationAdmin) Inclui todas as permissões necessárias para executar ferramentas de migração.
Gravador Create-on-push do Artifact Registry (roles/artifactregistry.createOnPushWriter) Ler e gravar artefatos. Crie repositórios gcr.io ao fazer push para URLs gcr.io.
Administrador de repositório de Create-on-push no Artifact Registry (roles/artifactregistry.createOnPushRepoAdmin) Ler, gravar e excluir artefatos. Crie repositórios gcr.io.
Para uma lista completa das permissões individuais em cada papel, consulte Papéis do Artifact Registry. Também é possível usar o comando 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. Não conceda papéis básicos em um ambiente de produção, mas é possível fazer isso em um ambiente de desenvolvimento ou teste.

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

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

Concedendo papéis

Conceda papéis no nível do projeto se os mesmos papéis 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 papéis em um repositório virtual, eles serão aplicados a todos os repositórios upstream disponíveis no repositório virtual, independentemente das permissões individuais do repositório.

Se você estiver concedendo papéis usando o comando gcloud, será possível especificar uma única vinculação de papel para um principal ou fazer mudanças de política em grande escala recebendo, modificando e definindo a política de permissão de um recurso. Para mais informações, consulte Conceder ou revogar vários papéis de forma programática.

Como conceder papéis 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 do Artifact Registry:

Console

  1. Abra a página do IAM no console 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 uma função para o principal. De acordo com o princípio de segurança de privilégio mínimo, considere conceder a menor quantidade de privilégio necessária para acessar os recursos obrigatórios do Artifact Registry. Para informações sobre papéis e permissões predefinidos do Artifact Registry, consulte Papéis predefinidos do Artifact Registry.

  6. Clique em Salvar.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  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:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com 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, consulte Conceder ou revogar vários papéis de forma programática

Como conceder papéis específicos de repositório

Conceda papéis 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 indivíduos, contas de serviço ou Grupos do Google como participantes.

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

  7. Clique em Salvar.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  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:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com 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 write@gmail.com com o repositório my-repo no local --us-west1, execute:

    gcloud artifacts repositories add-iam-policy-binding my-repo \
--location=us-west1 --member=user:write@gmail.com --role=roles/artifactregistry.writer

    Para conceder papéis usando um arquivo de política, siga o procedimento descrito em Conceder ou revogar vários papéis de maneira programática com os comandos gcloud artifacts repositories get-iam-policy e gcloud artifacts repositories set-iam-policy.

    3. Terraform

    Use o recurso google_artifact_registry_repository_iam para configurar uma política do IAM. O exemplo a seguir define uma conta de serviço 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ê não usa o Terraform para Google Cloud, consulte a página Primeiros passos: Google Cloud no 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 outros exemplos, consulte a documentação do recurso google_artifact_registry_repository_iam.

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 de leitura, conceda o papel Leitor do Artifact Registry ao principal allUsers. Também recomendamos limitar as cotas de solicitações do usuário para que um único usuário não consuma a cota geral do 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 para solicitações da API Artifact Registry e evite o uso indevido por usuários não autenticados. Consulte Limitar o uso para instruções.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  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-west1 como público, execute:

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

  3. Defina um limite por usuário para solicitações da API Artifact Registry e evite o uso indevido por usuários não autenticados. Consulte Limitar o uso para instruções.

Revogando papéis

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.

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ê estiver tornando um repositório de público para particular, expanda o principal allUsers.

  5. Clique em Remover principal para revogar o acesso.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  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 de quem você quer remover a vinculação. Use o formulário user|group|serviceAccount:email ou domain:domain.

      Exemplos: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com 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 de quem você quer remover a vinculação. Use o formulário user|group|serviceAccount:email ou domain:domain.

      Exemplos: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com 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 write@gmail.com com o repositório my-repo no local --us-west1, execute:

    gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location=us-west1 \
   --member=user:write@gmail.com \
   --role=roles/artifactregistry.writer

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

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

Conceder acesso condicional com tags

Os administradores de projetos podem criar tags para recursos no Google Cloud e gerenciá-las no Resource Manager. Ao anexar uma tag a um repositório do Artifact Registry, os administradores podem usar a tag com 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:

Como integrar com serviços do Google Cloud

Para a maioria das contas de serviço do Google Cloud , configurar o acesso a um registro só exige a concessão dos papéis do IAM adequados.

Contas de serviço padrão para serviços do Google Cloud

Google Cloud serviços como Cloud Build ou Google Kubernetes Engine usam uma conta de serviço padrão ou agente de serviço para interagir com recursos no mesmo projeto.

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

  • O serviço Google Cloud está em um projeto diferente do Artifact Registry.
  • As permissões padrão não atendem às suas necessidades.
  • Você está usando uma conta de serviço fornecida pelo usuário para interagir com o Artifact Registry em vez da conta de serviço padrão.
  • A configuração da política da organização impede a concessão automática de papéis a contas de serviço padrão.

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

Serviço Conta de serviço Endereço de e-mail
Ambiente flexível do App Engine Conta de serviço do App Engine PROJECT-ID@appspot.gserviceaccount.com
Compute Engine Conta de serviço padrão do Compute Engine PROJECT-NUMBER-compute@developer.gserviceaccount.com
Cloud Build Conta de serviço do Compute Engine
ou
conta de serviço legada do Cloud Build		 Dependendo das configurações da organização, o endereço de e-mail da conta de serviço padrão é um dos seguintes:
  • Compute Engine: PROJECT-NUMBER-compute@developer.gserviceaccount.com
  • Cloud Build: PROJECT-NUMBER@cloudbuild.gserviceaccount.com
Cloud Run Agente de serviço do Cloud Run
O agente de serviço do run.googleapis.com.		 service-PROJECT-NUMBER@serverless-robot-prod.iam.gserviceaccount.com
GKE Conta de serviço padrão do Compute Engine
A conta de serviço padrão para nós.		 PROJECT-NUMBER-compute@developer.gserviceaccount.com

Dependendo da configuração da política da organização, a conta de serviço padrão pode receber automaticamente o papel de Editor no projeto. É altamente recomendável desativar a concessão automática de papéis aplicando a restrição da política da organização iam.automaticIamGrantsForDefaultServiceAccounts. Se você criou a organização após 3 de maio de 2024, essa restrição será aplicada por padrão.

Se você desativar a concessão automática de papéis, precisará decidir quais papéis conceder às contas de serviço padrão e, em seguida, conceder esses papéis por conta própria.

Se a conta de serviço padrão já tiver o papel de Editor, recomendamos que você o substitua por papéis menos permissivos.Para modificar com segurança os papéis da conta de serviço, use o Simulador de política para ver o impacto da alteração e, em seguida, conceda e revogue os papéis apropriados.

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.

Embora o nível de acesso de uma conta de serviço seja determinado pelos papéis do IAM concedidos a ela, os escopos de acesso em uma instância de VM determinam os escopos padrão do OAuth para as solicitações feitas por meio da CLI gcloud e das bibliotecas de cliente na instância. Como resultado, os escopos de acesso podem limitar ainda mais o acesso aos métodos da API ao autenticar com credenciais padrão do aplicativo.

O Compute Engine usa os seguintes padrões:

  • A conta de serviço padrão do Compute Engine é a identidade das instâncias de VM. 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 papel básico de Editor do IAM, a menos que você tenha desativado esse comportamento.
  • As instâncias criadas com a conta de serviço padrão têm os escopos de acesso padrão do Compute Engine, incluindo acesso somente leitura ao armazenamento. Embora a função de Editor geralmente conceda acesso de gravação, o escopo de acesso ao armazenamento read-only limita a conta de serviço da instância a fazer o download de artefatos apenas 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 papéis 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çoGoogle 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 pools de nós do GKE podem extrair contêineres sem nenhuma configuração extra se todos os requisitos a seguir forem atendidos:

Se o ambiente do GKE não atender a esses requisitos, as instruções para conceder acesso dependerão se você estiver usando a conta de serviço padrão do Compute Engine ou uma conta de serviço fornecida pelo usuário como 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 do Artifact Registry, conceda as permissões necessárias à conta de serviço.

  2. Para enviar imagens, interagir com repositórios para formatos diferentes de contêineres ou executar comandos gcloud no cluster, defina escopos de acesso para a conta de serviço ao criar o cluster ou o pool de nós.

  3. Se você não estiver usando 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, faça o seguinte:

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

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

    Se você usar a flag --scopes com o comando gcloud container clusters create ou gcloud container node-pools create, inclua os escopos de acesso adequados para uso com o Artifact Registry.

Como definir escopos de acesso

Os escopos de acesso são o método legado de especificar autorização para 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 de armazenamento ou outro escopo de acesso que inclua acesso de leitura de armazenamento.

Só é possível definir escopos de acesso ao criar um cluster ou pool de nós. Não é possível mudar os escopos de acesso em nós atuais.

  • Se você estiver usando a conta de serviço padrão do Compute Engine, o GKE vai criar nós com os escopos de acesso padrão do Compute Engine, que incluem acesso somente leitura ao armazenamento.
  • Se você estiver usando uma conta de serviço fornecida pelo usuário, o GKE vai criar nós com o escopo cloud-platform, que é necessário para a maioria dos serviços doGoogle 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 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çoGoogle Cloud .

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

    Para uma lista completa de escopos, consulte a documentação de 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.

Configurar um imagePullSecret

Para configurar um imagePullSecret:

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

  2. Faça o download da chave da conta de serviç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)"

    Substitua:

    • 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 os serviços do Google Cloud. Para mais informações sobre a conta e as permissões dela, consulte Conta de serviço do Artifact Registry.

A seguir

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

Também é possível restringir downloads de artefatos com regras de download.