Basic Gitea Information
Estructura Básica
La estructura básica del entorno de Gitea es agrupar repositorios 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 repositorios 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 repositorios.
Y finalmente, los repositorios pueden tener mecanismos de protección especiales.
Permisos
Organizaciones
Cuando se crea una organización, se crea un equipo llamado Propietarios y el usuario se coloca dentro de él. Este equipo otorgará acceso de administrador sobre la organización, esos permisos y el nombre del equipo no se pueden modificar.
Los administradores de la organización (propietarios) pueden seleccionar la visibilidad de la organización:
Pública
Limitada (solo usuarios conectados)
Privada (solo miembros)
Los administradores de la organización también pueden indicar si los administradores del repositorio pueden agregar o eliminar acceso para equipos. También pueden indicar el número máximo de repositorios.
Al crear un nuevo equipo, se seleccionan varias configuraciones importantes:
Se indica los repositorios de la organización a los que los miembros del equipo podrán acceder: repositorios específicos (repos donde se agrega el equipo) o todos.
También se indica si los miembros pueden crear nuevos repositorios (el creador obtendrá acceso de administrador a él)
Los permisos que tendrán los miembros del repositorio:
Acceso de Administrador
Acceso Específico:
Equipos y Usuarios
En un repositorio, el administrador de la organización y los administradores del repositorio (si la organización lo permite) pueden administrar los roles asignados a colaboradores (otros usuarios) y equipos. Hay 3 roles posibles:
Administrador
Escritura
Lectura
Autenticación de 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 que permiten 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 confirmaciones sin firma.
Tokens de Acceso Personal
Puedes generar un token de acceso personal para dar a una aplicación acceso a tu cuenta. Un token de acceso personal otorga 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 tiene acceso tu cuenta, ya que, como se indica en la documentación, aún no se admiten los ámbitos:
Claves de Implementación
Las claves de implementación pueden tener acceso de solo lectura o escritura al repositorio, por lo que podrían ser interesantes para comprometer repositorios 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 en alguna rama.
Las protecciones de rama 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 declararse en cada repositorio.
Se pueden aplicar diferentes protecciones a una rama (como a master):
Desactivar Push: Nadie puede hacer push a esta rama
Habilitar Push: Cualquiera con acceso puede hacer push, pero no push forzado.
Lista blanca de Push restringida: Solo usuarios/equipos seleccionados pueden hacer push a esta rama (pero no push forzado)
Habilitar Lista blanca de Merge: Solo 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 se pueda fusionar un PR.
Restringir aprobaciones a lista blanca: Indica usuarios/equipos que pueden aprobar PRs.
Bloquear fusión en revisiones rechazadas: Si se solicitan cambios, no se puede fusionar (incluso si pasan las otras verificaciones)
Bloquear fusión 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 se descartarán.
Requerir commits firmados: Los commits deben estar firmados.
Bloquear fusión si la solicitud de extracción está desactualizada
Patrones de archivos protegidos/no protegidos: Indica patrones de archivos para proteger/desproteger contra cambios
Como puedes ver, incluso si logras obtener algunas credenciales de un usuario, los repositorios pueden estar protegidos evitando que envíes código a master, por ejemplo, para comprometer la canalización CI/CD.
Última actualización
