Permisos y config files en Jenkins
Cómo están organizados los permisos de jenkins.sils.tech, qué puede ver y hacer cada uno, y dónde están los config files. Vigente desde el 19/10/2026.
Login
Se entra con la cuenta de GitLab (botón de login de Jenkins → gitlab.sils.tech). No hay usuarios locales.
Los permisos se asignan por grupo de GitLab. Jenkins compara el nombre del grupo, así que:
- Hay que ser miembro directo del grupo (
SILSv2oproducto). Ser miembro de un subgrupo (por ejemplosilsv2/devs) no alcanza. - Si te agregan a un grupo, cerrá sesión en Jenkins y volvé a entrar para que tome el cambio.
Organización de los jobs
| Carpeta | Contenido |
|---|---|
KEEPER | Todos los jobs de Keeper (antes estaban sueltos en la raíz). |
PRODUCTO | Jobs de producto (SilsX, dashboard-k2, TERA, etc.). |
playground | Pruebas. Solo admin. |
Las URLs de los jobs de Keeper ahora llevan el prefijo KEEPER/, por ejemplo https://jenkins.sils.tech/job/KEEPER/job/apis/. Los webhooks de GitLab ya apuntan a las rutas nuevas.
Quién puede qué
| Quién | Ve | Puede |
|---|---|---|
Miembros del grupo GitLab SILSv2 | Carpeta KEEPER y todo su contenido | Ver jobs y logs, buildear, cancelar, ver workspace, configurar, crear y borrar jobs, editar y borrar builds, administrar los config files de KEEPER |
Miembros del grupo GitLab producto | Carpeta PRODUCTO y todo su contenido | Lo mismo, sobre PRODUCTO y sus config files |
| Miembros de los dos grupos | Ambas carpetas | Lo anterior en ambas |
| Cualquier otro usuario de GitLab | Nada (puede loguearse pero no ve jobs) | — |
Admin (francusa) | Todo | Configuración de Jenkins, plugins, agentes, credenciales, config files globales, permisos |
Todos los usuarios con acceso pueden además crear y editar vistas (las pestañas del dashboard).
Para pedir acceso: que te agreguen como miembro del grupo de GitLab que corresponda.
Roles en Jenkins (para admins)
Se configuran en Manage Jenkins → Manage and Assign Roles (plugin Role-based Authorization Strategy):
| Rol | Tipo | Patrón | Asignado a | Permisos |
|---|---|---|---|---|
admin | Global | — | francusa | Overall/Administer |
devs | Global | — | grupos SILSv2, producto | Overall/Read, View/* |
keeper-devs | Item | KEEPER(/.*)? | grupo SILSv2 | Job: Read, Build, Cancel, Workspace, Configure, Create, Delete · Run: Update, Delete |
producto-devs | Item | PRODUCTO(/.*)? | grupo producto | Ídem |
Config files
Los config files (plugin Config File Provider) son los archivos .env, .npmrc, service accounts, etc. que los pipelines usan con configFileProvider / configFile(fileId: '...').
Dónde están
| Scope | Dónde encontrarlos | Quién los edita | Cantidad |
|---|---|---|---|
Carpeta KEEPER | Entrar a la carpeta KEEPER → Config Files (menú izquierdo) | Miembros de SILSv2 | ~280 |
Carpeta PRODUCTO | Entrar a la carpeta PRODUCTO → Config Files | Miembros de producto | ~155 |
| Global | Manage Jenkins → Managed files | Solo admin | 12 |
Los globales son los que comparten jobs de las dos carpetas: credenciales de GCP por ambiente (sils-des, sils-stage, sils-ypf), npmrcConfigFile, jmxremoteCreds, los * RULES COMPLETE KILOMETROS y algunos de playground. Si necesitás cambiar uno, pedíselo al admin.
Cómo los encuentra un job
Cuando un pipeline pide configFile(fileId: 'abc-123'), Jenkins busca ese ID en este orden:
- En la carpeta del job y sus carpetas padre (por ejemplo
KEEPER/apis/dev→KEEPER/apis→KEEPER). - Si no lo encuentra, en los globales.
Consecuencias:
- Un job de
KEEPERno ve los config files dePRODUCTO(y viceversa). - Si creás en una carpeta un config file con el mismo ID que uno global, el de la carpeta tiene prioridad para los jobs de esa carpeta.
- Al crear un config file nuevo, hacelo en la carpeta de tu proyecto (no hace falta admin).
Seguridad
- Quien puede configurar jobs en una carpeta puede leer cualquier config file de esa carpeta desde un pipeline. Los permisos de carpeta separan
KEEPERdePRODUCTO, pero dentro de una carpeta no hay forma de ocultar un config file a quien configura jobs. - No pongas secretos en el log del build (
cat,echo,printenv). - Los API tokens de Jenkins no cargan los grupos de GitLab: un script que use
usuario:tokensolo tiene los permisos asignados a ese usuario por nombre (por defecto, ninguno). Si una automatización necesita acceso, pedí al admin que asigne el usuario al rol correspondiente.