Use equipes, funções e usuários para gerenciar o acesso a repositórios
Se você se lembrar do primeiro guia deste caminho de aprendizagem, lembrará que definimos a hierarquia básica de componentes estruturais do GitHub Enterprise Cloud (GHEC). Na parte superior, fica a conta corporativa, que pode conter uma ou mais organizações. Cada organização pode então conter qualquer número de equipes às quais seus membros podem ser atribuídos. As equipes e as funções dos membros ficam na parte inferior dessa hierarquia estrutural e fornecem os controles mais refinados em relação aos recursos e ao acesso dos membros individuais.
É por meio desses componentes que é possível espelhar mais precisamente sua estrutura interna no GHEC. Vamos ver mais de perto como eles funcionam e as opções disponíveis.
As equipes da HelloFresh e da Philips ofereceram uma maneira perfeita de automatizar permissões e empoderar desenvolvedores.
Neste guia, você aprenderá:
Como usar equipes para conceder permissões para grupos de usuários para facilitar a colaboração, a comunicação e simplificar o gerenciamento de acesso
Quais funções padrão estão disponíveis no nível da organização e quais permissões elas concedem
Quais funções padrão estão disponíveis no nível de repositório, as permissões que elas concedem e como criar funções de repositório personalizadas
Convidando e atribuindo usuários a organizações
Os usuários precisam receber acesso às organizações para obter acesso ao conteúdo. As empresas que usam Enterprise Managed Users (usuários gerenciados pela empresa, EMUs) precisam atribuir usuários às organizações. Já as empresas que não usam EMUs convidam usuários para participar das organizações, e esse convite precisa ser aceito.
A melhor forma de gerenciar a participação de usuários na suas organizações é adicioná-los a equipes. Assim, você pode usar automações como grupo do SCIM (System for Cross-domain Identity Management, sistema para gerenciamento de identidades entre domínios) (para EMU) ou organização do SCIM (não EMU) para gerenciar a participação na organização. Usar automações para gerenciar organizações significa que você não precisa lembrar de remover usuários manualmente para garantir que seu acesso e licença sejam removidos caso o usuário deixe a organização. A única coisa que você precisa fazer é se certificar que o usuário foi removido de todas as atribuições, o que também o remove da organização e revoga sua licença (contanto que seja a última organização da qual o usuário é membro na empresa).
Usamos um monorepo, então, em vez de usar equipes para controle de acesso, as usamos como um mecanismo de comunicação. É muito comum que nossos desenvolvedores marquem equipes quando querem feedback sobre algo ou para alertá-las sobre uma correção importante, por exemplo. Em outras empresas, você frequentemente verá pull requests com apenas o remetente marcado, mas frequentemente marcamos várias equipes em nossas pull requests para visibilidade. Isso ajuda as equipes a se manterem informadas e as incentivam a manter suas equipes atualizadas.
Para o gerenciamento de acesso sem SCIM, o proprietário da organização pode convidar um usuário para uma organização não EMU diretamente. Os convites manuais expiram se não forem aceito dentro de sete dias, mas podem ser reenviados ou cancelados, se necessário. Os usuários convidados manualmente precisam ser removidos manualmente quando deixarem a organização. Também é possível criar uma automação própria para removê-los. O convite manual não tem um processo de desprovisionamento integrado.
Use equipes para conceder permissões
As permissões podem ser concedidas a equipes e indivíduos. Quando possível, as empresas devem conceder permissões usando equipes, já que a assinatura pode ser sincronizada com grupos de provedor de identidade (IdP). É possível automatizar a criação dessas permissões usando webhooks e a API do GitHub.
Nossos desenvolvedores não precisam mais esperar que a equipe de TI forneça acesso manualmente. Sincronizamos nossos usuários e grupos do Azure Active Directory com o GitHub e usamos o Terraform para fornecer acesso aos repositórios. Se os usuários precisarem de acesso a um repositório, por exemplo, eles geram uma pull request e nossa automação de infraestrutura como código cuida do resto.
Funções empresariais
Toda conta de usuário em uma empresa é um membro da empresa. No nível empresarial, existem duas funções administrativas que podem ser atribuídas. Cada uma delas é vinculada à uma função comercial e fornece permissões para a realização de tarefas específicas na empresa.
Proprietários da empresa podem acessar e gerenciar todas as configurações da empresa e ver todos os membros e colaboradores externos de cada organização pertencente à empresa.
Gerentes de cobrança podem acessar e gerenciar apenas as configurações de cobrança da empresa.
As empresas que usam EMUs devem provisionar todos os novos membros da empresa, incluindo os com função administrativa, e fazer todas as mudanças e atribuições pelo IdP. Mesmo os proprietários de empresas e de organizações não podem adicionar novos membros ou proprietários à empresa usando GitHub.
Para empresas padrão, as funções administrativas podem ser atribuídas a membros empresariais existentes no GitHub.com e novos membros podem ser convidados por e-mail ou por nome de usuário da conta do GitHub. Todos os usuários, incluindo administradores, precisam entrar com uma conta do GitHub.com para aceitar o convite de função administrativa.
Funções da organização
Membro
O membro da organização é a função padrão e não administrativa de uma organização. Os membros têm um número de permissões por padrão, incluindo a capacidade de criar repositórios e quadros de projeto, embora essas permissões possam ser alteradas por política da empresa ou da organização.
Proprietário da organização
Os proprietários da organização têm acesso administrativo completo de uma organização, incluindo acesso e controle completos sobre todos os repositórios da organização. Essa função deve ser restringida apenas ao número de usuários necessários para atender às suas necessidades comerciais, já que os proprietários da organização possuem permissões para realizar ações confidenciais ou possivelmente destrutivas. No entanto, deve sempre haver mais de um proprietário da organização em cada organização para fins de contingência, caso um deles esteja indisponível, deixe a empresa ou perca o acesso. Os proprietários da organização podem promover outros membros da organização à função de proprietário da organização.
Como operamos em uma única organização do GitHub para promover innersource, permitimos que as equipes gerenciem suas próprias permissões de repositórios e não exigimos nada no nível organizacional. Claro, também aconselhamos enfaticamente que sigam o princípio de menos privilégios ao fornecer apenas o nível de acesso mínimo necessário. Usamos o IssueOps para conceder acesso just-in-time a administradores de organizações do GitHub para que eles não possam fazer alterações acidentalmente sem perceber o que estão fazendo.
Colaborador externo
Um colaborador externo tem acesso a um ou mais repositórios da organização, mas não é um membro da organização. Geralmente, consultores ou funcionários temporários ocupam essa função. Os colaboradores externos são convidados diretamente por repositório usando a conta do GitHub ou o endereço de e-mail. É possível escolher o nível de acesso concedido a cada colaborador externo para cada repositório ao qual ele é adicionado. Os administradores podem restringir a capacidade de convidar colaboradores por política de empresa ou de organização.
Empresas que usam EMUs não podem adicionar colaboradores externos porque todos os usuários devem ser provisionados do IdP conectado.
Gerenciador de segurança
Gerenciador de segurança é uma função no nível da organização que os proprietários da organização podem atribuir a qualquer equipe em uma organização. Quando aplicada, a função fornece permissões a todos os membros da equipe para gerenciar configurações e alertas de segurança em toda a organização, bem como permissões de leitura a todos os repositórios da organização.
Se a organização tem uma equipe de segurança, é possível usar a função de gerenciador de segurança para dar aos membros da equipe o mínimo de acesso necessário à organização. Ela também pode ser útil para auditores e outras pessoas que precisem desse acesso somente leitura com visibilidade às informações de segurança.
Gerente de cobrança
Os gerentes de cobrança são usuários que podem visualizar e gerenciar as informações e configurações de cobrança de uma organização específica. Essa é uma opção útil para empresas que possuem várias organizações em que você pode não querer conceder direitos completos de gerente de cobrança empresarial a alguns usuários, mas pode querer conceder acesso no nível de determinadas organizações.
Gerente do GitHub App
Por padrão, apenas os proprietários da organização podem gerenciar as configurações dos registros do GitHub App de propriedade de uma organização. Para permitir que usuários adicionais gerenciem os registros do GitHub App de propriedade de uma organização, um proprietário pode conceder permissões de gerente do GitHub App.
Quando um usuário recebe a função de gerente do GitHub App, ele pode receber acesso para gerenciar as configurações de alguns ou todos os registros do GitHub App, mas ele não pode instalar ou desinstalar GitHub Apps em uma organização.
Mantenedor de equipe
Quem possui a função de mantenedor de equipe pode gerenciar a participação na equipe e definir algumas configurações da equipe, como o nome e o avatar. Os proprietários da organização podem atribuir a função de mantenedor de equipe a usuários que já fazem parte da equipe.
As equipes que usam grupos de IdP para automatizar a participação não podem, por padrão, ter mantenedores. O escopo de trabalho de um mantenedor é muito limitado quando não é possível atualizar manualmente a integração do usuário à equipe. Os proprietários da organização podem alterar as configurações das equipes gerenciadas em grupo pelo IdP quando necessário.
Funções e permissões de repositório
O GitHub fornece três tipos diferentes de permissões de repositório padrão:
A permissão de Leitura permite que todos os membros da organização vejam o repositório, façam clones e colaborem em problemas. Os usuários também podem criar fork do repositório se essa função for permitida na sua empresa.
A permissão de Gravação permite que todos os membros da organização efetuem push de código no repositório. Ela não necessariamente permite que os membros efetuem push no branch padrão ou aprovem suas próprias alterações. Os controles de capacidade de mesclagem devidamente configurados controlam como os membros podem modificar o código.
A permissão de Administrador permite que todos os membros da organização administrem o repositório. Devido à sua natureza extremamente permissiva, essa permissão não deve ser usada como padrão.
O GitHub fornece um conjunto de funções de repositório, incluindo Leitura, Triagem, Gravação, Manutenção e Administrador, que podem ser explicitamente concedidas a indivíduos ou equipes. As funções de Triagem e Manutenção geralmente são mais úteis em comunidades de código aberto do que em empresas. Se for necessário ter funções adicionais, explore as funções de repositório personalizadas, que discutiremos abaixo.
Auditoria e gerenciamento do acesso ao repositório
Cada repositório administrado no GitHub tem uma visão geral da visibilidade do repositório, a visibilidade base e o acesso direto, bem como uma exibição detalhada de cada equipe ou pessoa com acesso ao repositório. Essa visualização permite buscar e filtrar equipes e usuários individuais, convidar novas equipes ou pessoas, alterar a função de cada pessoa ou equipe no repositório ou remover o acesso ao repositório.
A visão geral pode ajudar a realizar a auditoria do acesso ao repositório, integrar ou remover prestadores de serviços ou funcionários e responder com eficácia a incidentes de segurança.
Se uma pessoa recebeu acesso ou permissões conflitantes a um repositório, um aviso será exibido na página de acesso ao repositório. O acesso conflitante pode ocorrer quando atribuições diretas ou funções personalizadas concedem acesso específico a um usuário que ele de outra forma não receberia por meio da equipe ou de funções e permissões herdadas. Quando um usuário tem acesso conflitante, um ícone de aviso é exibido na tela de acesso ao repositório com "Mixed roles" ao lado da listagem de usuários da pessoa. Para ver a fonte do acesso conflitante, coloque o cursor do mouse sobre o ícone de aviso ou clique no indicador “Mixed roles” (funções mistas). Não é necessário “consertar” um acesso conflitante. Essa informação está presente apenas para seu conhecimento, para que o acesso conflitante não cause confusão sobre o motivo pelo qual um usuário tem determinadas permissões.
Quando diferentes níveis de acesso são fornecidos por caminhos diferentes, como integração à equipe e as permissões básicas de uma organização, o acesso mais alto substitui cada permissão específica. Por exemplo: se um proprietário da organização fornece uma função que usa a função herdada "Read" a um membro da organização, e depois um proprietário da organização define a permissão básica da organização para "Write", essa função personalizada terá permissão de escrita, bem como quaisquer permissões adicionais incluídas na função personalizada. Esses diferentes níveis de acesso podem fazer com que a sinalização de acesso conflitante seja exibida na visão geral de acesso ao repositório, conforme descrito anteriormente.
Funções de repositório personalizadas
É possível criar até cinco funções de repositório personalizadas por organização para obter controle mais granular sobre as permissões concedidas no nível de repositório. As funções de repositório personalizadas herdam as permissões de uma função padrão: Leitura, Triagem, Gravação, Manutenção ou Administrador. É possível personalizar a função atribuindo permissões adicionais.
Após criar uma função personalizada, qualquer pessoa com acesso de administrador a um repositório pode atribuir essa nova função a um indivíduo ou equipe.
A seguir: Acesso programático e integrações com o GitHub Enterprise Cloud
Integrar o GHEC com os diversos sistemas de uma empresa exige uma abordagem em camadas e bem planejada. A seguir, vamos explorar as diversas maneiras de acessar programaticamente a API do GitHub para integrar seus sistemas existentes sem dificuldades.