Nesta página, descrevemos as permissões para controlar o acesso ao Container Registry.
Depois de configurar as permissões, você pode configurar a autenticação para clientes do Docker que usa para enviar e extrair imagens.
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
Verifique se você tem permissões para gerenciar usuários. É necessário ter permissões em um dos seguintes papéis:
- Administrador IAM do projeto (roles/resourcemanager.projectIamAdmin)
- Administrador de segurança (roles/iam.securityAdmin)
Como alternativa à concessão desses papéis, é possível usar um papel personalizado ou papel predefinido com o mesmo permissões.
Permissões e papéis
Todos os usuários, contas de serviço e outras identidades que interagem com o Container Registry precisam ter Permissões do Identity and Access Management (IAM) para o Cloud Storage.
- Serviços do Google Cloud que normalmente acessam o Container Registry são configuradas com permissões padrão para registros no mesmo projeto do Google Cloud. Se as permissões padrão não atendam às suas necessidades, você terá que configurar as permissões apropriadas.
- Para outras identidades, você precisa configurar as permissões necessárias.
Você controla o acesso aos hosts do Container Registry com permissões do Cloud Storage. A tabela a seguir lista Papéis do Cloud Storage que têm o as permissões exigidas pelo Container Registry.
Mais algumas permissões são necessárias ao visualizar o Container Registry. usando o console do Google Cloud, consulte Permissões comuns necessárias para usar o console do Cloud.
Acesso necessário | Papel | Onde conceder permissões |
---|---|---|
Extrair imagens (somente leitura) de um registro atual | Leitor de objetos do Storage (roles/storage.objectViewer) | Conceda o papel no bucket de armazenamento do registro. |
Enviar (gravar) imagens para e extrair (ler) imagens de um host de registro atual em um projeto | Gravador de bucket legado do Storage (roles/storage.legacyBucketWriter) | Conceda o papel no bucket de armazenamento do registro. Essa permissão só é disponível no nível do bucket, não é possível concedê-lo no nível do projeto. |
Adicione hosts de registro a projetos do Google Cloud e crie o buckets de armazenamento associados. | Administrador do Storage (roles/storage.admin) | Conceder o papel no nível do projeto |
O envio de imagens requer permissões de leitura e gravação do objeto, bem como
storage.buckets.get
. O papel Gravador de bucket legado do Storage
inclui as permissões necessárias em um único papel do Cloud Storage,
não concede controle total sobre buckets e objetos de armazenamento.
O papel Administrador do Storage concede controle total sobre buckets e objetos de armazenamento. Se você conceder essa permissão no nível do projeto, o principal terá acesso a todos os buckets de armazenamento do projeto, incluindo buckets que não são usados pelos Container Registry. Considere cuidadosamente quais principais exigem esse papel.
- Por padrão, a conta de serviço do Cloud Build tem permissões o papel Administrador do Storage. Portanto, essa conta de serviço pode adicionar registros para o projeto pai com o primeiro envio e push de imagens para no projeto pai.
- Se você usa o Docker ou outras ferramentas para criar e enviar imagens para um registro, considere adicionar registros ao seu projeto usando uma conta com os administrador do Storage e conceder a permissão de Gravador de bucket legado de Leitor de objetos do Storage para outras contas que precisam enviar por push ou pull de imagens de contêiner.
Para mais informações sobre papéis e permissões do Cloud Storage, consulte a documentação do Cloud Storage.
Conceder permissões do IAM
O Container Registry usa intervalos do Cloud Storage como armazenamento subjacente para imagens de contêiner. Você controla o acesso às suas imagens concedendo permissões ao bucket para um registro.
O primeiro envio de imagem para um nome de host adiciona o host de registro e o armazenamento dele
a um projeto. Por exemplo, o primeiro envio para gcr.io/my-project
adiciona o host de registro gcr.io
ao projeto com o
ID do projeto
my-project
e cria um bucket de armazenamento para o registro. O nome do bucket tem
um dos seguintes formatos:
artifacts.PROJECT-ID.appspot.com
para imagens armazenadas no hostgcr.io
STORAGE-REGION.artifacts.PROJECT-ID.appspot.com
para imagens armazenadas em outros hosts de registro
Para realizar o primeiro envio de imagem, a conta responsável ter as permissões do papel Administrador do Storage.
Após o envio da imagem inicial para um host de registro, conceda permissões no bucket de armazenamento do registro para controlar o acesso a imagens no no registro:
- Gravador de bucket legado do Storage para push e pull
- Leitor de objetos do Storage para extrair apenas
É possível conceder permissão para um bucket usando o console do Google Cloud ou a Google Cloud CLI.
Limitações e restrições
Só é possível conceder permissões no nível do bucket de armazenamento para Hosts do Container Registry.
- O Container Registry ignora as permissões definidas em objetos individuais dentro um bucket do Cloud Storage.
- Não é possível conceder permissões nos repositórios de um registro. Se você precisar um controle de acesso mais granular, o Artifact Registry oferece o controle de acesso no nível do repositório e pode atender melhor às suas necessidades.
- Se você ativar o acesso uniforme no nível do bucket para qualquer bucket de armazenamento do Container Registry, é preciso conceder permissões a todos os usuários e contas de serviço que acessam seus registros. Em nesse caso, os papéis Proprietário e Editor por si só podem não conceder o as permissões necessárias.
Conceder permissões
Se o host de registro ainda não existir no projeto, uma conta com permissões no papel de administrador do Storage precisa enviar a primeira imagem para o registro. Isso cria o bucket de armazenamento para o host de registro.
O Cloud Build tem as permissões necessárias para executar a imagem inicial dentro do mesmo projeto. Se você estiver enviando imagens com outra ferramenta, verifique as permissões da conta do Google Cloud que você está usando para autenticar com o Container Registry.
Para mais informações sobre como enviar a imagem inicial com o Docker, consulte Como adicionar um registro.
No projeto com o Container Registry, conceda as permissões apropriadas no bucket do Cloud Storage usado pelo host de registro.
Console
- Acesse a página do Cloud Storage no console do Google Cloud.
Clique no link
artifacts.PROJECT-ID.appspot.com
ouSTORAGE-REGION.artifacts.PROJECT-ID.appspot.com
para o bucket.Substitua PROJECT-ID pelo Google Cloud ID do projeto do projeto que hospeda o Container Registry e STORAGE-REGION com o modelo multirregional (
asia
,eu
ouus
) do registro que hospeda a imagem.Selecione a guia Permissões.
Clique em Adicionar.
No campo Principais, insira os endereços de e-mail das contas. que exigem acesso, separados por vírgulas. O endereço de e-mail pode ser:
- Uma Conta do Google (por exemplo,
someone@example.com
). - um Grupo do Google (por exemplo,
my-developer-team@googlegroups.com
); uma conta de serviço do IAM
Veja a lista de serviços do Google Cloud. que geralmente acessam registros para encontrar o endereço de e-mail a conta de serviço associada. Se o serviço estiver em execução no um projeto diferente do Container Registry, verifique se o endereço de e-mail da conta de serviço no em outro projeto.
- Uma Conta do Google (por exemplo,
No menu suspenso Selecionar papel, selecione o Cloud Storage e selecione a permissão apropriada.
- Leitor de objetos do Storage para extrair apenas imagens
- Gravador de bucket legado do Storage para enviar e extrair imagens
Clique em Adicionar.
gcloud
Execute o seguinte comando para listar os intervalos no projeto:
gcloud storage ls
A resposta terá esta aparência:
gs://[BUCKET_NAME1]/ gs://[BUCKET_NAME2]/ gs://[BUCKET_NAME3]/ ...
Encontre o bucket do host de registro na lista de buckets retornada. O bucket que armazena suas imagens tem o nome BUCKET-NAME em um dos seguintes formatos:
artifacts.PROJECT-ID.appspot.com
para imagens armazenadas no hostgcr.io
STORAGE-REGION.artifacts.PROJECT-ID.appspot.com
para imagens armazenadas em outros hosts de registro
Onde
- PROJECT-ID é seu Google Cloud ID do projeto.
- STORAGE-REGION é o local do bucket de armazenamento:
us
para registros no hostus.gcr.io
eu
para registros no hosteu.gcr.io
asia
para registros no hostasia.gcr.io
Execute o seguinte comando no shell ou janela do terminal:
gcloud storage bucket add-iam-policy-binding gs://BUCKET_NAME \ --member=TYPE:EMAIL-ADDRESS \ --role=ROLE
Onde
- BUCKET_NAME é o nome do intervalo do Cloud Storage no formato
artifacts.PROJECT-ID.appspot.com
ouSTORAGE-REGION.artifacts.PROJECT-ID.appspot.com
. - TYPE pode ser um dos seguintes:
serviceAccount
, se EMAIL-ADDRESS especifica uma conta de serviço.user
, se EMAIL-ADDRESS for uma Conta do Google.group
, se EMAIL-ADDRESS for um Grupo do Google.
EMAIL-ADDRESS pode ser:
- Uma Conta do Google (por exemplo,
someone@example.com
). - um Grupo do Google (por exemplo,
my-developer-team@googlegroups.com
); uma conta de serviço do IAM
Veja a lista de serviços do Google Cloud. que geralmente acessam registros para encontrar o endereço de e-mail a conta de serviço associada. Se o serviço estiver em execução no um projeto diferente do Container Registry, verifique se o endereço de e-mail da conta de serviço no em outro projeto.
- Uma Conta do Google (por exemplo,
ROLE é o papel do Cloud Storage que você quer conceder.
objectViewer
para extrair imagenslegacyBucketWriter
imagens de push e pull
- BUCKET_NAME é o nome do intervalo do Cloud Storage no formato
Por exemplo, o comando concede à conta de serviço
my-account@my-project.iam.gserviceaccount.com
com permissões para enviar e extrair imagens no bucketmy-example-bucket
:gcloud storage bucket add-iam-policy-binding gs://my-example-bucket \ --member=serviceAccount:my-account@my-project.iam.gserviceaccount.com \ --role=roles/storage.objectUser
O comando
gcloud storage bucket add-iam-policy-binding
altera as permissões de IAM do bucket de armazenamento em que o registro está hospedado. Outros exemplos são na documentação da CLI gcloud.Se você estiver configurando o acesso para VMs do Compute Engine ou nós do GKE que enviarão imagens para o Container Registry, consulte Como configurar VMs e clusters de configuração do Terraform.
Configurar o acesso público às imagens
O Container Registry é acessível publicamente se o bucket de armazenamento subjacente do local do host for acessível publicamente. Em um projeto, todas as imagens em cada local do host são públicas ou não. No host de um projeto, não é possível veicular publicamente apenas imagens específicas. Se você tiver imagens específicas que quer tornar públicas:
- tenha o cuidado de mantê-las em um local de host separado que você torna público ou
- Crie um novo projeto para manter as imagens acessíveis publicamente.
Para disponibilizar imagens de contêiner publicamente, torne o intervalo de armazenamento subjacente acessível publicamente seguindo estas etapas:
Você precisa ter enviado uma imagem ao Container Registry para que o bucket de armazenamento subjacente exista.
Encontre o nome do bucket do Cloud Storage para esse registro. Para fazer isso, liste os buckets:
gcloud storage ls
Seu URL de bucket do Container Registry será listado como
gs://artifacts.PROJECT-ID.appspot.com
ougs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com
, em que:- PROJECT-ID é seu Google Cloud ID do projeto. Os projetos com escopo de domínio terão o nome de domínio como parte do ID do projeto.
- STORAGE-REGION é o local do bucket de armazenamento:
us
para registros no hostus.gcr.io
eu
para registros no hosteu.gcr.io
asia
para registros no hostasia.gcr.io
Torne o bucket de armazenamento do Container Registry acessível ao público. Basta executar o comando a seguir, que disponibiliza ao público todas as imagens no bucket.
gcloud storage bucket add-iam-policy-binding gs://BUCKET-NAME \ --member=allUsers --role=roles/storage.objectViewer
em que:
gs://BUCKET-NAME
é o URL do bucket do Container Registry
Remover o acesso público às imagens
Console
Você precisa ter enviado uma imagem ao Container Registry para que o bucket de armazenamento subjacente exista.
Abra a página do Container Registry no console do Google Cloud.
No painel esquerdo, clique em Configurações.
Na página Configurações em Acesso público, ative a opção a visibilidade como Particular. Essa configuração controla o acesso ao bucket de armazenamento subjacente.
gcloud storage
Encontre o nome do bucket do Cloud Storage para esse registro. Para fazer isso, liste os buckets:
gcloud storage ls
Seu URL de bucket do Container Registry será listado como
gs://artifacts.PROJECT-ID.appspot.com
ougs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com
, em que:- PROJECT-ID é o console do Google Cloud. ID do projeto. Os projetos com escopo de domínio terão o nome de domínio como parte do ID do projeto.
- STORAGE-REGION é o local do bucket de armazenamento:
us
para registros no hostus.gcr.io
eu
para registros no hosteu.gcr.io
asia
para registros no hostasia.gcr.io
Para remover o acesso público ao seu bucket de armazenamento, execute o seguinte comando no shell ou na janela do terminal:
gcloud storage bucket remove-iam-policy-binding gs://BUCKET-NAME \ --member=allUsers --role=roles/storage.objectViewer
em que:
BUCKET-NAME
é o nome do bucket desejado.
Revogar permissões
Siga as etapas abaixo para revogar as permissões do IAM.
Console
- Acesse a página do Cloud Storage no console do Google Cloud.
Clique no link
artifacts.PROJECT-ID.appspot.com
ouSTORAGE-REGION.artifacts.PROJECT-ID.appspot.com
para o bucket. Aqui, PROJECT-ID é o ID do projeto do Google Cloud do projeto que hospeda o Container Registry e STORAGE-REGION é a multirregião (asia
,eu
ouus
) do registro que hospeda a imagem.Selecione a guia Permissões.
Clique no ícone da lixeira ao lado do principal que você quer remover.
gcloud
Execute o seguinte comando no shell ou janela do terminal:
gcloud storage bucket remove-iam-policy-binding gs://BUCKET-NAME \
--member=PRINCIPAL --all
em que:
BUCKET-NAME
é o nome do bucket desejado.- PRINCIPAL pode ser um dos seguintes:
user:EMAIL-ADDRESS
para uma Conta do GoogleserviceAccount:EMAIL-ADDRESS
para uma conta de serviço do IAMgroup:EMAIL-ADDRESS
para um Grupo do Google.allUsers
para revogar o acesso público
Integrar com 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 uma 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 Container 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. Se você quiser enviar uma imagem da VM para um registro, será preciso modificar permissões para a conta de serviço da VM ou autenticar no registro a uma conta com acesso de gravação ao armazenamento.
- Você está usando uma conta de serviço personalizada para interagir com o Container Registry
As contas de serviço a seguir geralmente acessam o Container Registry. A da conta de serviço inclui o endereço de e-mail do 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 | Permissões |
---|---|---|---|
Ambiente flexível do App Engine | Conta de serviço padrão do App Engine | PROJECT-ID aappspot.gserviceaccount.com | Papel de editor, pode ler e gravar no armazenamento. |
Compute Engine | Conta de serviço padrão do Compute Engine | PROJECT-NUMBER-compute@developer.gserviceaccount.com | Papel de editor, limitado ao acesso somente leitura ao armazenamento |
Cloud Build | Conta de serviço do Cloud Build | PROJECT-NUMBER@cloudbuild.gserviceaccount.com | Permissões padrão incluem a criação de buckets de armazenamento e acesso de leitura e gravação. |
Cloud Run | Conta de serviço padrão do Compute Engine A conta de serviço de ambiente de execução padrão para revisões. |
PROJECT-NUMBER-compute@developer.gserviceaccount.com | Papel de editor, limitado ao acesso somente leitura ao armazenamento |
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 | Papel de editor, limitado ao acesso somente leitura ao armazenamento |
Configurar VMs e clusters para enviar imagens
Compute Engine e qualquer serviço do Google Cloud que use o Compute Engine tem uma conta de serviço padrão do Compute Engine como a identidade padrão.
As permissões do IAM e os escopos de acesso afetam a capacidade para ler e gravar no armazenamento.
- As permissões do IAM determinam o acesso aos recursos.
- Os escopos de acesso determinam
escopos padrão do OAuth para solicitações feitas pela CLI gcloud e pelo cliente
em uma instância de VM. Assim, os escopos de acesso podem limitar ainda mais
a métodos de API ao autenticar com o
Application Default Credentials.
- Para extrair uma imagem particular, a conta de serviço da VM precisa ter a permissão
read
para o intervalo de armazenamento da imagem. - Para enviar imagens privadas, a conta de serviço da VM precisa ter o
escopo de acesso
read-write
,cloud-platform
oufull-control
à do bucket de armazenamento da imagem.
- Para extrair uma imagem particular, a conta de serviço da VM precisa ter a permissão
Por padrão, a conta de serviço padrão do Compute Engine tem o papel de Editor. que inclui permissões para criar e atualizar recursos na maioria serviços do Google Cloud. No entanto, para a conta de serviço padrão uma conta de serviço personalizada associada a uma VM, o escopo de acesso padrão para buckets de armazenamento é somente leitura. Por padrão, as VMs não podem imagens de push.
Se você só pretende implantar imagens em ambientes como o Compute Engine e GKE, não será preciso modificar o escopo de acesso. Se você querem executar aplicativos nesses ambientes que enviam imagens para o registro, será necessário realizar outras configurações.
As configurações a seguir exigem alterações nas permissões do IAM ou do escopo de acesso.
- Como enviar imagens de uma VM ou cluster
- Se você quiser enviar imagens por push, a conta de serviço da instância de VM precisará ter o escopo
storage-rw
em vez destorage-ro
. - A VM e o Container Registry estão em projetos separados
- Você precisa conceder o IAM à conta de serviço permissões para acessar o bucket de armazenamento usado pelo Container Registry.
- Como executar comandos
gcloud
em VMs - A conta de serviço precisa ter o escopo
cloud-platform
. Esse escopo concede permissões para enviar e extrair imagens, bem como executar comandosgcloud
.
As etapas para configurar escopos estão nas seções a seguir.
Configurar escopos para VMs
Para definir escopos de acesso ao criar uma VM, use a opção --scopes.
gcloud compute instances create INSTANCE --scopes=SCOPE
Em que
- INSTANCE é o nome da instância de VM;
- SCOPE é o escopo que você quer configurar para a conta de serviço da VM:
- Solicitar imagens:
storage-ro
- Solicitar e enviar imagens:
storage-rw
- Solicitar e enviar imagens, executar comandos gcloud:
cloud-platform
- Solicitar imagens:
Para alterar os escopos de uma instância de VM existente:
Defina o escopo de acesso com a opção --scopes.
Pare a instância de VM. Consulte Como interromper uma instância.
Altere o escopo de acesso com o comando a seguir.
gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
Em que
- INSTANCE é o nome da instância de VM;
- SCOPE é o escopo que você quer configurar para a conta de serviço da VM:
- Solicitar imagens:
storage-ro
- Solicitar e enviar imagens:
storage-rw
- Solicitar e enviar imagens, executar comandos gcloud:
cloud-platform
- Solicitar imagens:
Reinicie a instância de VM. Consulte Como iniciar uma instância interrompida.
Se você quiser usar uma conta de serviço personalizada para VMs em vez da conta de serviço você pode especificar a conta de serviço e os escopos de acesso a serem usados quando você Crie a VM ou modificar as configurações da VM.
Configurar escopos para clusters do Google Kubernetes Engine
Por padrão, novos clusters do GKE são criados com permissões somente leitura para intervalos do Cloud Storage.
Para definir o escopo de armazenamento read-write
ao
criar um cluster do Google Kubernetes Engine, use a opção --scopes
.
Por exemplo, o comando a seguir cria um cluster com os escopos bigquery
, storage-rw
e compute-ro
:
gcloud container clusters create example-cluster \
--scopes=bigquery,storage-rw,compute-ro
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.
A conta de serviço do Container Registry
O Agente de serviço do Container Registry atua em nome Container Registry ao interagir com serviços do Google Cloud. O serviço tem o conjunto mínimo de permissões necessárias se você ativou o API Container Registry depois de 5 de outubro de 2020. O agente de serviço tem o papel de editor. Para mais informações sobre o agente de serviço e modificar as permissões dele, consulte Conta de serviço do Container Registry.
Faça um teste
Se você ainda não conhece o Google Cloud, crie uma conta para avaliar como O Container Registry funciona no mundo real diferentes. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.
Teste o Container Registry gratuitamente