Basic Gitea Information
Basic Structure
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, repositórios podem ter mecanismos de proteção especiais.
Permissions
Organizations
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.
Admins da organização (owners) podem selecionar a visibilidade da organização:
Pública
Limitada (apenas usuários logados)
Privada (apenas membros)
Admins da organização também podem indicar se os admins 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 organização 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:
Teams & Users
Em um repositório, o admin da organização e os admins do repositório (se permitido pela organização) podem gerenciar os papéis dados a colaboradores (outros usuários) e equipes. Existem 3 possíveis papéis:
Administrador
Escrita
Leitura
Gitea Authentication
Web Access
Usando nome de usuário + senha e potencialmente (e recomendado) um 2FA.
SSH Keys
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
GPG Keys
Você não pode se passar pelo usuário com essas chaves, mas se você não usá-las, pode ser possível que você seja descoberto por enviar commits sem uma assinatura.
Personal Access Tokens
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
Oauth Applications
Assim como os tokens de acesso pessoal, aplicações Oauth terão acesso completo à sua conta e aos lugares que sua conta tem acesso porque, conforme indicado na documentação, escopos ainda não são suportados:
Deploy keys
Deploy keys podem ter acesso de leitura ou escrita ao repositório, então podem ser interessantes para comprometer repositórios específicos.
Branch Protections
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 dentro de 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):
Disable Push: Ninguém pode fazer push para este branch
Enable Push: Qualquer pessoa com acesso pode fazer push, mas não forçar o push.
Whitelist Restricted Push: Apenas usuários/equipes selecionados podem fazer push para este branch (mas não forçar o push)
Enable Merge Whitelist: Apenas usuários/equipes na lista de permissões podem mesclar PRs.
Enable Status checks: Requer verificações de status antes de mesclar.
Require approvals: Indica o número de aprovações necessárias antes que um PR possa ser mesclado.
Restrict approvals to whitelisted: Indica usuários/equipes que podem aprovar PRs.
Block merge on rejected reviews: Se mudanças forem solicitadas, não pode ser mesclado (mesmo se os outros cheques passarem)
Block merge on official review requests: Se houver solicitações de revisão oficial, não pode ser mesclado
Dismiss stale approvals: Quando novos commits, aprovações antigas serão descartadas.
Require Signed Commits: Commits devem ser assinados.
Block merge if pull request is outdated
Protected/Unprotected file patterns: Indica padrões de arquivos para proteger/desproteger contra mudanças
Como você pode ver, mesmo que você consiga obter algumas credenciais de um usuário, repositórios podem estar protegidos evitando que você faça push de código para o master por exemplo para comprometer o pipeline CI/CD.
Last updated
