Cómo se gestionan los permisos en Gitlab

Contenido

Gestión de permisos en gitlab

Para la gestión de permisos en Gitlab se ha optado por la implementación de un modelo de autogestión. Este cambio está pensado para otorgar mayor autonomía y flexibilidad a los distintos equipos de desarrollo.

Los principales objetivos que persigue este cambio son:

  • Autonomía: Permitir a los equipos gestionar sus propios permisos, facilitando la incorporación o bajas de recursos de manera directa.
  • Responsabilidad: Fomentar un sentido de responsabilidad y propiedad sobre los grupos/repositorios, mejorando la colaboración y la productividad.
  • Eficiencia: Reducir la carga administrativa centralizada, permitiendo una gestión de permisos más rápida, adaptada a las necesidades específicas de cada equipo, minimizando las solicitudes de soporte.

En este escenario, los Directores de Proyectos (en adelante DP) serán responsables de asignar roles y permisos a los miembros del equipo según sea necesario. Podrán delegar esta asignación en otros roles, bajo su responsabilidad.

En este modelo, el DP solo necesitará crear una primera petición para la creación de un grupos para cada sistema de información y/o servicio de apoyo del que sea responsable, que se situará en la raíz de Gitlab.

¿Cómo solicito la creación del grupo raíz para un Sistema de Información o Servicio de Apoyo?

En primer lugar, denominamos “grupo raíz", al grupo que representa a un Sistema de Información o Servicio de Apoyo, gestionado por un propietario (normalmente el DP) a partir del cual, se desarrollará toda la estructura lógica del repositorio.

Solo los DP podrán realizar este tipo de peticiones, aunque podrán delegar la administración a quien consideren oportuno, teniendo en cuenta que esa persona o personas deben tener cierto conocimiento de los componentes que integran el sistema y los implicados en el mismo, además de conocimiento básico de cómo funcionan los repositorios de tipo Git y sistemas de gestión de productos tipo GitLab.

Los sistemas que pueden subirse al repositorio de código serán aquellos dentro del alcance, ver ¿Qué es el Repositorio de Código asociado a la Plataforma Pre-Cloud y cómo se usa?

A los subgrupos del grupo raíz (y siguientes), por simplicidad, lo referenciaremos a lo largo del documento como “grupos”

Estas peticiones deben realizarse vía NAOS, por el Director del Proyecto, a la Oficina de Impulso DevSecOps .

La categorización que debe emplearse es la siguiente:

Operación: Realizar petición

  • Servicio:  DSO - Impulso DevSecOps
  • Componente: Soporte de las herramientas de apoyo DevSecOps
  • Elemento: (Sin determinar)

En el asunto de la petición, se indicará:

[GITLAB] Creación grupo raíz para SI-'Nombre del sistema'

En la descripción, se detallará la solicitud. La nomenclatura del grupo raíz para el Sistema de Información o el Servicio de Apoyo correspondiente, deberán seguir las pautas indicadas en el documento “Nomenclatura en el repositorio de código"

Como la petición tiene que venir del DP del Sistema de Información o Servicio de Apoyo, se le asignará el rol de Owner al SOLICITANTE de la petición. A partir de ese momento es responsabilidad total y absoluta de dicha persona para gestionar dicho grupo raíz y todo su contenido, así como sus accesos.

Importante: Si tienes cualquier duda durante el proceso, no dudes en contactar con la Oficina de Impulso de DevSecOps  para que te acompañe durante todo el proceso.

¿Cómo solicito el alta de un usuario en Gitlab?

 

El aprovisionamiento de la cuenta de GITLAB está automatizada. Cualquier usuario que visite el dominio de Gitlab a través de su VPN y que disponga de un usuario LDAP, debe realizar un primer inicio de sesión (será fallido) en la herramienta usando su usuario LDAP. Es importante que el usuario actualice su perfil con su email y seleccione “Update profile settings” para que los cambios tengan efecto. 

Posteriormente, el usuario recibirá un email de confirmación. Una vez confirmado, el usuario podrá acceder a la instancia, aunque solo verá los grupos/proyectos internos. Para acceder a un grupo/proyecto privado, debe ser invitado por el responsable del grupo/proyecto en cuestión. 

¿Cómo gestiono los accesos a los grupos / subgrupos / proyectos? 

Existen dos roles principales que podrán invitar a nuevos miembros a un grupo o proyecto: 

  • Owner 

  • Mainteiner 

Los usuarios con dichos roles tendrán autonomía para invitar a nuevos miembros a los proyectos del grupo al que pertenecen. 

Los usuarios con rol Maintainer existentes en un grupo serán responsables de los proyectos y grupos adicionales que creen, ya que al crear un nuevo grupo se le asigna directamente el rol Owner dentro del mismo. Al añadir nuevos miembros al grupo o proyecto se deberá asignar un rol (inferior o igual a maintainer) y una fecha de expiración (¿se debe asignar una temporalidad a los acceso?). Esta forma de trabajar aumenta la independencia de los equipos al no tener que abrir peticiones de soporte cada vez que se quiera agregar un nuevo usuario al proyecto o cambiarle el rol. 

Los usuarios que se asignan al grupo correspondiente al Sistema de Información (SI) o Servicio de Apoyo (SA) tendrán acceso a los proyectos o grupos  de este SI/SA (ya que el rol se hereda). Si fuera necesario, se podría dar solo acceso a un proyecto concreto o dar diferentes roles (permisos) al usuario en los grupos y proyectos existentes en la estructura. 

Cuando se agrega un miembro a un grupo, el usuario hereda la membresía y el nivel de permisos del grupo padre. Este modelo permite el acceso a grupos anidados si el usuario tiene ya permisos en un grupo padre.

¿Cómo cambio el nivel de acceso a un grupo / proyecto? 

Si se desea modificar el rol de un usuario en el repositorio Gitlab, es responsabilidad del propio equipo de trabajo llevar a cabo este proceso. Como se mencionó anteriormente, los usuarios del equipo con roles de maintainer u owner (si el grupo/s y/o proyectos ha sido creado por un usuario maintainer de ese grupo) tienen la capacidad y deben encargarse de esta tarea. Este usuario maintainer puede asignar rol maintainer o inferior a otros usuarios. 

¿Se debe asignar una temporalidad a los accesos? 

Las directrices a tener en cuenta respecto a la duración de los roles asignados a los usuarios de la plataforma son las siguientes: 

  • Temporalidad de asignación: la fecha de expiración debe asignarse en función del tiempo estrictamente necesario, evitando asignaciones innecesariamente prolongadas. 

  • Revisión y renovación: se sugiere realizar revisiones periódicas de las asignaciones de roles. Al programar revisiones regulares, se puede garantizar que los usuarios mantengan únicamente los roles necesarios para sus responsabilidades actuales 

  • Notificaciones de expiración: GitLab enviará automáticamente una alerta por correo electrónico cuando falten 7 días para que el acceso de un usuario a un grupo o proyecto expire. Estas notificaciones servirán como recordatorio para los usuarios y administradores, permitiendo una acción oportuna para renovar o ajustar los roles según sea necesario. 

En caso de desconocer la duración que debería asignarse, se utilizarán los siguientes valores predeterminados: 

  • Maintainer: 2 años. 

  • Resto de roles: 1 año. 

Estos períodos se contarán en años naturales a partir de la fecha en que se realiza la asignación. Por ejemplo, si la acción la estamos realizando el 06/06/2021, la fecha de expiración por defecto para un "Developer" será "06/06/2022". Para los años bisiestos, las altas dadas el 29 de febrero expirarán el 1 de marzo del siguiente año. 

Desde la Oficina de Impulso DevSecOps, se implementarán mecanismos que verifiquen que los usuarios asignados a grupos/proyectos poseen una fecha de expiración y en caso contrario, tomar acciones correctoras, que pueden incluir la asignación automática de una fecha o el cambio de visibilidad a un rol con permisos más restrictivos.  

¿Cómo realizo la baja de un usuario? 

Dependiendo del tipo de baja se procederá conforme a las siguientes casuísticas: 

Baja de un grupo, subgrupo o proyecto. 

Será responsabilidad del mantainer/owner del grupo o proyecto restringir al usuario o usuarios en cuestión del lugar que corresponda. 

En caso de que el causante de la baja sea el ÚNICO Owner en el grupo raíz, este debe realizar una nueva asignación Owner. El nuevo Owner será el responsable de dar la baja al anterior. 

Baja general de la instancia de Gitlab (Bloqueo del usuario) 

Estas peticiones deben realizarse vía NAOS, por el Director del Proyecto, a la Oficina de Impulso DevSecOps

La categorización que debe emplearse es la siguiente:  

  • Operación: Realizar petición
  • Servicio:  DSO - Impulso DevSecOps
  • Componente: Soporte de las herramientas de apoyo DevSecOps
  • Elemento: (Sin determinar)

En el asunto de la petición se indicará: 

GITLAB] Bloqueo usuario nombre usuario 

En la descripción, se detallarán los motivos que ocasionan el bloqueo. 

¿Puedo mover un grupo / proyecto de lugar? 

Es posible realizar una transferencia de un proyecto a un grupo distinto siempre y cuando quien realiza la acción sea owner de dicho proyecto y tenga como mínimo rol maintainer en el grupo que lo desea mover. 

Si se desease realizar una transferencia de un grupo y todos los proyectos contenidos en los mismos a otro sistema, solo sería posible realizarlo si posee rol owner tanto en el grupo origen y destino. 

En caso de no poder proceder al no cumplirse las condiciones anteriores, se deberá abrir petición NAOS, en la cual se indicará el nombre del proyecto que se desea mover junto con el grupo en el que se encuentra y a qué Sistema de Información se debe de mover, es decir, el grupo al cual se desea realizar la transferencia indicando el motivo. Dicha acción se realizará previo estudio y aprobación. 

¿Es posible la eliminación de un grupo? 

Si, es posible realizar está acción. Solo la persona con el rol Owner puede realizarla, bajo su total y absoluta responsabilidad. 

Roles y permisos de usuario

Roles

A continuación, se describen los roles existentes en el repositorio de código tomando como base GitLab, con una descripción simplificada de sus acciones básicas. La configuración precisa y los permisos asociados pueden variar en función de la configuración del proyecto y la versión del repositorio utilizada:

RolDescripción
OwnerEste rol es el que asignamos a los responsables (Directores de Proyecto) del Sistema de Información. Tiene control total sobre el proyecto y los permisos de todos los demás roles, incluyendo la capacidad de eliminar el proyecto y administrar los permisos de usuario.
MaintainerEste rol permite a los usuarios gestionar el código, aprobar o rechazar solicitudes de fusión, así como realizar tareas de mantenimiento del proyecto.
DeveloperEste rol permite a los usuarios gestionar el código y enviar solicitudes de fusión, pero no puede aprobar o rechazar dichas solicitudes.
ReporterEste rol permite a los usuarios hacer comentarios e informar de problemas, pero no puede hacer cambios directos en el código.
GuestEste rol permite a los usuarios ver el proyecto y los archivos, pero no puede hacer cambios.

 

Permisos de usuario

A continuación, se van a detallar algunas de las acciones que pueden realizar sobre el repositorio cada uno de los roles definidos para la estrategia de ramificación a seguir:

  • Gestión de subgrupos: crear, borrar y editar grupos hijos del grupo raíz.​
  • Gestión de miembros del proyecto: crear, borrar y editar usuarios en el proyecto.​
  • Gestión del proyecto: crear, borrar y editar proyectos.​
  • Gestión de ramas: crear, borrar y editar las ramas de un proyecto.​
  • Gestión de tags: crear, borrar y editar tags en el proyecto.​ Modificaciones en ramas: hacer commit y push sobre una rama.​
  • Fusiones en todas las ramas: Realizar merge en todas las ramas, incluye merge de los conflictos en una fusión. ​
  • Crear y aprobar solicitudes de fusión (MR): crear y aprobar Merge request.​
  • Permiso de lectura: solo tiene permiso de lectura en el proyecto. Así que solo podrá ver las ramas, pero no realizar cambios sobre ellas. 

En la siguiente tabla se puede observar la relación de permisos existentes con el rol del usuario.

 GuestReporterDeveloperMaintainerOwner
Invitar usuarios a grupos    X
Crear subgrupos   XX
Eliminar subgrupos    X
Invitar usuarios a subgrupos    X
Invitar usuarios a proyecto   XX
Gestión del proyecto   XX
Gestión de ramas*  XXX
Gestión de tags  XXX
Fusiones en todas las ramas   XX
Crear solicitudes de fusión (MR)  XXX
Aprobar solicitudes de fusión(MR)   X**X
Permisos de lecturaX***XXXX

* Sólo en las ramas feature y hotfix

** Sólo en la rama pru

*** Sólo en proyectos públicos

Índice