Basic Gitea Information
Estructura Básica
La estructura básica del entorno de Gitea es agrupar repos por organización(es), cada una de ellas puede contener varios repositorios y varios equipos. Sin embargo, ten en cuenta que al igual que en github, los usuarios pueden tener repos fuera de la organización.
Además, un usuario puede ser miembro de diferentes organizaciones. Dentro de la organización, el usuario puede tener diferentes permisos sobre cada repositorio.
Un usuario también puede ser parte de diferentes equipos con diferentes permisos sobre diferentes repos.
Y finalmente, los repositorios pueden tener mecanismos de protección especiales.
Permisos
Organizaciones
Cuando se crea una organización se crea un equipo llamado Owners y el usuario es puesto dentro de él. Este equipo dará acceso de administrador sobre la organización, esos permisos y el nombre del equipo no pueden ser modificados.
Los administradores de la organización (owners) pueden seleccionar la visibilidad de la organización:
Pública
Limitada (solo usuarios registrados)
Privada (solo miembros)
Los administradores de la organización también pueden indicar si los administradores de repos pueden agregar y/o eliminar acceso para equipos. También pueden indicar el número máximo de repos.
Al crear un nuevo equipo, se seleccionan varias configuraciones importantes:
Se indica los repos de la organización a los que los miembros del equipo podrán acceder: repos específicos (repos donde se agrega el equipo) o todos.
También se indica si los miembros pueden crear nuevos repos (el creador obtendrá acceso de administrador a él)
Los permisos que los miembros del repo tendrán:
Acceso de Administrador
Acceso Específico:
Equipos y Usuarios
En un repo, el administrador de la organización y los administradores del repo (si la organización lo permite) pueden gestionar los roles dados a colaboradores (otros usuarios) y equipos. Hay 3 posibles roles:
Administrador
Escritura
Lectura
Autenticación en Gitea
Acceso Web
Usando nombre de usuario + contraseña y potencialmente (y recomendado) un 2FA.
Claves SSH
Puedes configurar tu cuenta con una o varias claves públicas permitiendo que la clave privada relacionada realice acciones en tu nombre. http://localhost:3000/user/settings/keys
Claves GPG
No puedes suplantar al usuario con estas claves pero si no las usas, podría ser posible que te descubran por enviar commits sin una firma.
Tokens de Acceso Personal
Puedes generar un token de acceso personal para dar acceso a una aplicación a tu cuenta. Un token de acceso personal da acceso completo a tu cuenta: http://localhost:3000/user/settings/applications
Aplicaciones Oauth
Al igual que los tokens de acceso personal, las aplicaciones Oauth tendrán acceso completo a tu cuenta y a los lugares a los que tu cuenta tiene acceso porque, como se indica en los docs, los scopes aún no son compatibles:
Claves de Despliegue
Las claves de despliegue pueden tener acceso de solo lectura o escritura al repo, por lo que podrían ser interesantes para comprometer repos específicos.
Protecciones de Ramas
Las protecciones de ramas están diseñadas para no dar control completo de un repositorio a los usuarios. El objetivo es poner varios métodos de protección antes de poder escribir código dentro de alguna rama.
Las protecciones de ramas de un repositorio se pueden encontrar en https://localhost:3000/<orgname>/<reponame>/settings/branches
No es posible establecer una protección de rama a nivel de organización. Por lo tanto, todas deben ser declaradas en cada repo.
Diferentes protecciones pueden aplicarse a una rama (como a master):
Deshabilitar Push: Nadie puede hacer push a esta rama
Habilitar Push: Cualquiera con acceso puede hacer push, pero no force push.
Lista Blanca de Push Restringido: Solo los usuarios/equipos seleccionados pueden hacer push a esta rama (pero no force push)
Habilitar Lista Blanca de Merge: Solo los usuarios/equipos en la lista blanca pueden fusionar PRs.
Habilitar Verificaciones de Estado: Requiere que las verificaciones de estado pasen antes de fusionar.
Requerir Aprobaciones: Indica el número de aprobaciones requeridas antes de que un PR pueda ser fusionado.
Restringir Aprobaciones a Lista Blanca: Indica los usuarios/equipos que pueden aprobar PRs.
Bloquear Merge en Revisiones Rechazadas: Si se solicitan cambios, no se puede fusionar (incluso si las otras verificaciones pasan)
Bloquear Merge en Solicitudes de Revisión Oficiales: Si hay solicitudes de revisión oficiales, no se puede fusionar
Descartar Aprobaciones Obsoletas: Cuando hay nuevos commits, las aprobaciones antiguas serán descartadas.
Requerir Commits Firmados: Los commits deben estar firmados.
Bloquear Merge si el Pull Request está Desactualizado
Patrones de Archivos Protegidos/No Protegidos: Indica patrones de archivos para proteger/no proteger contra cambios
Como puedes ver, incluso si lograste obtener algunas credenciales de un usuario, los repos pueden estar protegidos evitando que hagas push de código a master por ejemplo para comprometer la pipeline de CI/CD.
Last updated
