Traduzir papéis e permissões do Cloud Source Repositories para o Secure Source Manager

Este guia mostra aos usuários do Cloud Source Repositories (CSR) como os controles de acesso dele são traduzidos para o Secure Source Manager (SSM). Para seguir este guia, você precisa conhecer o IAM e o CSR e ter um entendimento básico do SSM.

Modelos de recursos

O CSR tem um recurso Google Cloud que é filho de um projeto:

  • Um repositório, projects/<var>project</var>/repositories/<var>repo</var>

O SSM tem dois recursos que são filhos regionalizados de um projeto:

  • Uma instância, projects/<var>project</var>/locations/<var>location</var>/instances/<var>instance</var>
  • Um repositório, que é o equivalente mais direto a um repositório de CSR e precisa ser anexado a (mas não é filho de) uma instância do SSM no mesmo projeto e local, projects/<var>project</var>/locations/<var>location</var>/repositories/<var>repo</var>

O SSM tem outros recursos, mas eles são modelados como filhos do repositório. Este guia os considera parte do repositório.

Papéis

O CSR tem três funções: roles/source.reader, roles/source.writer e roles/source.admin. É possível vincular as funções de leitor e gravador a um repositório ou projeto. Só vincule a função de administrador a um projeto porque a permissão source.repos.create se aplica apenas ao escopo do projeto.

O SSM tem 11 papéis para principais de usuário, um aumento significativo em comparação com o Cloud Source Repositories. É possível agrupar essas funções em duas categorias (além de uma função de superusuário).

O papel de superusuário (roles/securesourcemanager.admin) concede todas as permissões do SSM. É necessário vincular essa função a um projeto porque as permissões de instância não se aplicam se você as vincular a um repositório, e as permissões de repositório não se aplicam se você as vincular a uma instância.

Papéis da instância do SSM

As funções de instância concedem permissões para acessar a interface do Secure Source Manager e se conectar a ela usando o Git. É necessário conceder aos usuários pelo menos uma função de instância para permitir que eles acessem repositórios na instância. É possível vincular esses papéis a um recurso de instância ou a um projeto.

Papel Permissões
roles/securesourcemanager.instanceAccessor Acessar uma instância e os repositórios dela. Necessário para que as funções no nível do repositório sejam eficazes.
roles/securesourcemanager.instanceManager Gerenciar configurações no nível da instância.
roles/securesourcemanager.instanceOwner Controle total sobre as configurações de instância.
roles/securesourcemanager.instanceRepoCreator Crie repositórios em uma instância.
roles/securesourcemanager.sshKeyUser Gerenciar chaves SSH para autenticação em uma instância. Não concede acesso à instância por conta própria.

Papéis do repositório do SSM

As funções de repositório concedem permissões em repositórios dentro de uma instância do Secure Source Manager. É possível vincular esses papéis a um recurso de repositório ou a um projeto, exceto o repoCreator, que precisa ser vinculado a um projeto.

Papel Permissões
roles/securesourcemanager.repoAdmin Controle total sobre um repositório, incluindo configurações e acesso de usuários.
roles/securesourcemanager.repoPullRequestApprover Aprovar solicitações de envio em um repositório.
roles/securesourcemanager.repoReader Ler o conteúdo do repositório e ver solicitações de envio e problemas.
roles/securesourcemanager.repoWriter Ler e gravar conteúdo do repositório e gerenciar solicitações de envio e problemas.
roles/securesourcemanager.repoCreator Crie novos repositórios em um projeto.

Como mapear papéis de CSR para o SSM

Para usar o SSM de maneira eficaz, você precisa de pelo menos duas funções: uma função de instância e uma função de repositório. Não há um mapeamento 1:1 de uma função de CSR para uma função de SSM. Essas receitas fornecem acesso equivalente apenas para controle de origem, não para recursos do SSM, como solicitações de pull, problemas ou gerenciamento de instâncias.

No CSR, é possível criar repositórios em vários projetos. No Secure Source Manager, todos os repositórios em uma instância pertencem ao mesmo projeto da instância. Se você vincular qualquer papel no nível do projeto no Secure Source Manager, vai conceder as permissões desse papel a todos os repositórios nessa instância. Se você precisar conceder permissões apenas a repositórios específicos, use vinculações no nível do repositório.

Mapeamento de source.reader

Se você vinculou essa função no nível do repositório, vincule securesourcemanager.repoReader no recurso do repositório e securesourcemanager.instanceAccessor na instância do host para recriar o mesmo nível de acesso. Se você vinculou a função no nível do projeto, a vinculação de repoReader e instanceAccessor no nível do projeto concede acesso de leitura a todos os repositórios na instância.

Mapeamento de source.writer

Se você vinculou essa função no nível do repositório, vincule securesourcemanager.repoWriter no recurso do repositório e securesourcemanager.instanceAccessor na instância do host para recriar o mesmo nível de acesso. Se você vinculou a função no nível do projeto, a vinculação de repoWriter e instanceAccessor no nível do projeto concede acesso de gravação a todos os repositórios na instância.

Mapeamento de source.admin

Você só vincula essa função no nível do projeto. É possível recriar a política vinculando uma combinação de securesourcemanager.instanceAccessor, securesourcemanager.repoAdmin, securesourcemanager.instanceRepoCreator e securesourcemanager.repoCreator no nível do projeto. Essa combinação de papéis concede permissão para criar repositórios em qualquer instância do projeto e concede aos administradores permissões para todos os repositórios em qualquer instância do projeto. Para conceder todas as permissões do SSM da mesma forma que source.admin concedeu todas as permissões do CSR, vincule o papel de superusuário, securesourcemanager.admin, no nível do projeto.

Diferenças entre SSM e CSR

Esta seção descreve as principais mudanças na forma como o Secure Source Manager lida com papéis e permissões em comparação com o Cloud Source Repositories.

Concessão de papel implícita

Quando você cria um recurso de repositório, o principal de chamada recebe automaticamente a função repoAdmin no recurso recém-criado.

Novos tipos de recursos

O SSM tem mais recursos que o CSR, e eles são modelados como novos tipos de recursos. Esses recursos incluem regras de proteção de ramificação, hooks, problemas e solicitações de pull, além de comentários sobre problemas e solicitações de pull. Esses recursos são filhos do recurso de repositório. Os papéis do repositório incluem permissões para esses recursos. Por exemplo, repoAdmin e repoWriter fornecem acesso de gravação, enquanto repoReader concede apenas acesso de leitura.

Papéis refinados

O SSM inclui papéis refinados que oferecem controles de acesso específicos.

  • roles/securesourcemanager.repoPullRequestApprover concede apenas a permissão para aprovar solicitações de envio. Use essa função com repoReader e instanceAccessor para permitir que um usuário acesse uma instância, navegue pelo repositório e aprove solicitações de pull sem modificar outros dados.
  • roles/securesourcemanager.repoCreator concede apenas a permissão para criar repositórios em um projeto. Como os repositórios precisam ser anexados a uma instância, você também precisa ter roles/securesourcemanager.instanceRepoCreator para anexar um repositório a uma instância. Use roles/securesourcemanager.repoCreator com instanceRepoCreator para conceder permissões para criar repositórios e anexá-los a uma instância.

A seguir