Mapear papéis do IAM do Container Registry para o Artifact Registry

O Container Registry e o Artifact Registry usam diferentes papéis do Identity and Access Management para controlar às imagens de contêiner armazenadas no registro.

Para facilitar a transição do Container Registry para o Artifact Registry, execute o seguinte: um comando da Google Cloud CLI que:

  • identifica as políticas de permissão que se aplicam a um bucket de armazenamento do Cloud Storage. que armazena imagens para o Container Registry
  • Retorna uma política com papéis semelhantes do Artifact Registry para conceder o acesso dos usuários do Container Registry aos repositórios do Artifact Registry.

O comando usa a Análise de políticas do IAM para para analisar as políticas de permissão do IAM.

Antes de começar

  1. Ative a Cloud Asset API.

    Ative a API

    É necessário ativar a API no projeto ou na organização em que você quer para analisar as políticas de permissão existentes.

  2. Instale e inicialize a CLI gcloud. Para um instalação atual, atualize para a versão mais recente com o comando:

    gcloud components update
    

Funções exigidas

Para ter as permissões necessárias para analisar as políticas de permissão e conceder acesso aos repositórios do Artifact Registry, faça o seguinte: peça ao administrador para conceder a você papéis do IAM no projeto, na pasta ou na organização em que você quer analisar em busca de permissões:

Para mais informações sobre como conceder papéis, consulte Gerenciar acesso.

Esses papéis predefinidos têm as permissões necessárias para analisar as políticas de permissão e conceder acesso aos repositórios do Artifact Registry. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As seguintes permissões são necessárias para analisar as políticas de permissão e conceder acesso aos repositórios do Artifact Registry:

  • cloudasset.assets.analyzeIamPolicy
  • cloudasset.assets.searchAllResources
  • cloudasset.assets.searchAllIamPolicies
  • Para analisar políticas com papéis personalizados do IAM: iam.roles.get
  • Para usar a Google Cloud CLI para analisar políticas: serviceusage.services.use
  • Para conceder papéis em um repositório do Artifact Registry: artifactregistry.repositories.setIamPolicy

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Usar a ferramenta de mapeamento

As verificações da ferramenta de mapeamento permitem políticas para um Container Registry especificado nome do host, como gcr.io.

A ferramenta verifica se há conjuntos de permissões que estão em os papéis do Cloud Storage e os associa aos papéis do Artifact Registry. Para comparar as permissões do Cloud Storage para os papéis do Artifact Registry, consulte Mapeamentos de papéis.

Para usar a ferramenta de mapeamento de funções:

  1. Execute a ferramenta de mapeamento:

    gcloud beta artifacts docker upgrade print-iam-policy HOSTNAME \
        --project=PROJECT_ID > POLICY_FILENAME
    

    Substitua os seguintes valores:

    • HOSTNAME é o nome do host do Container Registry que você quer a ferramenta para analisar:

      • gcr.io
      • asia.gcr.io
      • eu.gcr.io
      • us.gcr.io
    • PROJECT_ID é o ID do projeto do Google Cloud. com o host de registro que você está analisando.

    • POLICY_FILE é o nome do arquivo da política, no formato YAML. que a ferramenta retornará.

    O comando de exemplo a seguir analisa o bucket de armazenamento para gcr.io em o projeto my-project para as políticas de permissão que são aplicadas diretamente à do bucket ou são herdados do ID da organização pai 101231231231 e seus descendentes.

    gcloud beta artifacts docker upgrade print-iam-policy gcr.io \
        --project=my-project > gcr-io-policy.yaml
    

    O comando retorna um arquivo de política no formato YAML com o papel do Artifact Registry vinculações, com base nas políticas de permissão do bucket de armazenamento. Se o o projeto pai do bucket de armazenamento estiver em uma organização, a política inclui principais que têm acesso concedido no nível da pasta ou no nível da organização.

    Por exemplo, o exemplo a seguir inclui vinculações de papéis do Artifact Registry para:

    • Cloud Build, Compute Engine e Container Registry agentes de serviços. Os agentes de serviço agem em nome serviços do Google Cloud.
    • A conta de usuário user@example.com
    • A conta serviço gerenciado pelo usuário deploy@my-project.iam.gserviceaccount.com:
    bindings:
    - members:
      - service-3213213213213@gcp-sa-cloudbuild.iam.gserviceaccount.com
      - user:user@example.com
      role: roles/artifactregistry.repoAdmin
    - members:
      - serviceAccount:deploy@my-project.iam.gserviceaccount.com
      - serviceAccount:service-1231231231231@@compute-system.iam.gserviceaccount.com
      - serviceAccount:service-1231231231231@containerregistry.iam.gserviceaccount.com
      role: roles/artifactregistry.reader
    
  2. Remova a linha referente ao agente de serviço do Container Registry da política já que essa conta de serviço não exige acesso ao seu Artifact Registry repositórios. O sufixo do endereço de e-mail do agente de serviço é containerregistry.iam.gserviceaccount.com:

    No exemplo de política da etapa anterior, a linha com o prefixo O agente de serviço do Container Registry é:

    - serviceAccount:service-1231231231231@containerregistry.iam.gserviceaccount.com
    
  3. Revise as outras vinculações de papéis para confirmar se elas são adequadas.

    O Artifact Registry tem outros papéis predefinidos que você pode para alguns principais. Por exemplo, o Artifact Registry O administrador de repositório "create-on-push" permite que um principal crie repositórios gcr.io no Artifact Registry, mas não permite que eles criem em outros repositórios do Artifact Registry.

  4. Adicione vinculações de papéis para os principais que estejam faltando no arquivo de política.

    Os seguintes principais podem estar faltando no arquivo de política retornado:

    • Principais com papéis personalizados e esses papéis personalizados não têm conjuntos de permissões que a ferramenta usou para mapear papéis.
    • Principais que receberam acesso em uma pasta ou organização pai se você não tem permissão para acessar uma pasta ou organização mãe.
  5. Aplique as vinculações de política aos repositórios do Artifact Registry.

    gcloud artifacts repositories set-iam-policy REPOSITORY FILENAME \
        --project=PROJECT_ID \
        --location=LOCATION
    

    Substitua os seguintes valores:

    • REPOSITORY é o nome do repositório.
    • POLICY_FILENAME é o nome do arquivo de política que você são aplicadas ao repositório.
    • PROJECT_ID é o ID do projeto.
    • LOCATION é o local regional ou multirregional do repositório.

    O exemplo a seguir para o projeto my-project aplica a política em o arquivo gcr-io-policy.yaml para o repositório chamado gcr.io no us multirregional:

    gcloud artifacts repositories set-iam-policy gcr.io gcr-io-policy.yaml \
        --project=my-project \
        --location=us
    

    Se quiser aplicar vinculações de papéis a um recurso de nível superior, edite o um projeto, uma pasta ou uma política da organização atual com vinculações que você quer adicionar.

Mapeamentos de funções

A tabela a seguir mostra quais papéis predefinidos do Artifact Registry devem ser concedidos para usuários do Container Registry, dependendo da Cloud Storage permissões que eles têm.

Permissões necessárias na função Papel no Artifact Registry
storage.objects.get
storage.objects.list
Leitor do Artifact Registry
storage.buckets.get
storage.objects.get
storage.objects.list
storage.objects.create
Gravador do Artifact Registry
storage.buckets.get
storage.objects.get
storage.objects.list
storage.objects.create
storage.objects.delete
Administrador de repositórios do Artifact Registry
storage.buckets.get
storage.objects.get
storage.objects.list
storage.objects.create
storage.buckets.create
Administrador do Artifact Registry