Basic Gitea Information
Estrutura Básica
A estrutura básica do ambiente Gitea é agrupar repositórios por organização(ões), cada uma delas pode conter vários repositórios e várias equipes. No entanto, observe que, assim como no github, os usuários podem ter repositórios fora da organização.
Além disso, um usuário pode ser membro de diferentes organizações. Dentro da organização, o usuário pode ter diferentes permissões sobre cada repositório.
Um usuário também pode fazer parte de diferentes equipes com diferentes permissões sobre diferentes repositórios.
E, finalmente, os repositórios podem ter mecanismos de proteção especiais.
Permissões
Organizações
Quando uma organização é criada, uma equipe chamada Owners é criada e o usuário é colocado dentro dela. Esta equipe dará acesso de administrador sobre a organização, essas permissões e o nome da equipe não podem ser modificados.
Os administradores da org (proprietários) podem selecionar a visibilidade da organização:
Pública
Limitada (apenas usuários logados)
Privada (apenas membros)
Os administradores da org também podem indicar se os administradores do repositório podem adicionar e/ou remover acesso para equipes. Eles também podem indicar o número máximo de repositórios.
Ao criar uma nova equipe, várias configurações importantes são selecionadas:
É indicado os repositórios da org que os membros da equipe poderão acessar: repositórios específicos (repositórios onde a equipe é adicionada) ou todos.
Também é indicado se os membros podem criar novos repositórios (o criador terá acesso de administrador a ele)
As permissões que os membros do repositório terão:
Acesso de Administrador
Acesso Específico:
Equipes e Usuários
Em um repositório, o administrador da org e os administradores do repositório (se permitido pela org) podem gerenciar os papéis atribuídos a colaboradores (outros usuários) e equipes. Existem 3 possíveis papéis:
Administrador
Escrever
Ler
Autenticação do Gitea
Acesso Web
Usando nome de usuário + senha e potencialmente (e recomendado) um 2FA.
Chaves SSH
Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a chave privada relacionada execute ações em seu nome. http://localhost:3000/user/settings/keys
Chaves GPG
Você não pode se passar pelo usuário com essas chaves, mas se você não as usar, pode ser possível que você seja descoberto por enviar commits sem uma assinatura.
Tokens de Acesso Pessoal
Você pode gerar um token de acesso pessoal para dar a um aplicativo acesso à sua conta. Um token de acesso pessoal dá acesso total à sua conta: http://localhost:3000/user/settings/applications
Aplicações Oauth
Assim como os tokens de acesso pessoal, as aplicações Oauth terão acesso completo à sua conta e aos lugares onde sua conta tem acesso porque, como indicado na documentação, os escopos ainda não são suportados:
Chaves de Implantação
As chaves de implantação podem ter acesso somente leitura ou gravação ao repositório, então podem ser interessantes para comprometer repositórios específicos.
Proteções de Branch
As proteções de branch são projetadas para não dar controle completo de um repositório aos usuários. O objetivo é colocar vários métodos de proteção antes de poder escrever código em algum branch.
As proteções de branch de um repositório podem ser encontradas em https://localhost:3000/<orgname>/<reponame>/settings/branches
Não é possível definir uma proteção de branch no nível da organização. Portanto, todas elas devem ser declaradas em cada repositório.
Diferentes proteções podem ser aplicadas a um branch (como ao master):
Desativar Push: Ninguém pode fazer push para este branch
Ativar Push: Qualquer pessoa com acesso pode fazer push, mas não push forçado.
Whitelist de Push Restrito: Apenas usuários/equipes selecionados podem fazer push para este branch (mas sem push forçado)
Ativar Lista de Merge: Apenas usuários/equipes da lista branca podem fazer merge de PRs.
Ativar verificações de status: Exigir que as verificações de status passem antes de fazer merge.
Exigir aprovações: Indicar o número de aprovações necessárias antes que um PR possa ser mesclado.
Restringir aprovações a lista branca: Indicar usuários/equipes que podem aprovar PRs.
Bloquear merge em revisões rejeitadas: Se forem solicitadas alterações, não pode ser mesclado (mesmo que as outras verificações passem)
Bloquear merge em solicitações de revisão oficiais: Se houver solicitações de revisão oficiais, não pode ser mesclado
Dispensar aprovações antigas: Com novos commits, as aprovações antigas serão dispensadas.
Exigir Commits Assinados: Os commits devem ser assinados.
Bloquear merge se a solicitação de pull estiver desatualizada
Padrões de arquivos protegidos/não protegidos: Indicar padrões de arquivos para proteger/não proteger contra alterações
Como você pode ver, mesmo se conseguir obter algumas credenciais de um usuário, os repositórios podem estar protegidos evitando que você envie código para o master, por exemplo, comprometendo o pipeline CI/CD.
Última actualización
