Basic Jenkins Information
Acceso
Nombre de Usuario + Contraseña
La forma más común de iniciar sesión en Jenkins es con un nombre de usuario o una contraseña.
Cookie
Si una cookie autorizada es robada, puede ser utilizada para acceder a la sesión del usuario. La cookie usualmente se llama JSESSIONID.*. (Un usuario puede terminar todas sus sesiones, pero primero tendría que darse cuenta de que una cookie fue robada).
SSO/Plugins
Jenkins puede ser configurado usando plugins para ser accesible vía SSO de terceros.
Tokens
Los usuarios pueden generar tokens para dar acceso a aplicaciones para que los suplanten vía CLI o REST API.
Claves SSH
Este componente proporciona un servidor SSH integrado para Jenkins. Es una interfaz alternativa para el Jenkins CLI, y los comandos pueden ser invocados de esta manera usando cualquier cliente SSH. (De la documentación)
Autorización
En /configureSecurity es posible configurar el método de autorización de Jenkins. Hay varias opciones:
Cualquiera puede hacer cualquier cosa: Incluso el acceso anónimo puede administrar el servidor.
Modo legado: Igual que Jenkins <1.164. Si tienes el rol de "admin", se te otorgará control total sobre el sistema, y de lo contrario (incluyendo usuarios anónimos) tendrás acceso de lectura.
Usuarios registrados pueden hacer cualquier cosa: En este modo, cada usuario registrado obtiene control total de Jenkins. El único usuario que no tendrá control total es el usuario anónimo, que solo obtiene acceso de lectura.
Seguridad basada en matriz: Puedes configurar quién puede hacer qué en una tabla. Cada columna representa un permiso. Cada fila representa un usuario o un grupo/rol. Esto incluye un usuario especial 'anónimo', que representa a usuarios no autenticados, así como 'autenticado', que representa a todos los usuarios autenticados.
Estrategia de Autorización Basada en Matriz por Proyecto: Este modo es una extensión de la "seguridad basada en matriz" que permite definir una matriz ACL adicional para cada proyecto por separado.
Estrategia Basada en Roles: Permite definir autorizaciones usando una estrategia basada en roles. Gestiona los roles en
/role-strategy.
Realm de Seguridad
En /configureSecurity es posible configurar el realm de seguridad. Por defecto, Jenkins incluye soporte para algunos Realms de Seguridad diferentes:
Delegar al contenedor de servlets: Para delegar la autenticación a un contenedor de servlets que ejecuta el controlador de Jenkins, como Jetty.
Base de datos de usuarios propia de Jenkins: Usa el almacén de datos de usuarios integrado de Jenkins para la autenticación en lugar de delegar a un sistema externo. Esto está habilitado por defecto.
LDAP: Delegar toda la autenticación a un servidor LDAP configurado, incluyendo tanto usuarios como grupos.
Base de datos de usuarios/grupos de Unix: Delegar la autenticación a la base de datos de usuarios a nivel de sistema operativo Unix en el controlador de Jenkins. Este modo también permitirá reutilizar los grupos de Unix para la autorización.
Los plugins pueden proporcionar realms de seguridad adicionales que pueden ser útiles para incorporar Jenkins en sistemas de identidad existentes, tales como:
Nodos, Agentes y Ejecutores de Jenkins
Definiciones de la documentación:
Nodos son las máquinas en las que se ejecutan los agentes de construcción. Jenkins monitorea cada nodo adjunto para espacio en disco, espacio temporal libre, espacio de intercambio libre, tiempo/sincronización del reloj y tiempo de respuesta. Un nodo se desconecta si alguno de estos valores se sale del umbral configurado.
Agentes gestionan la ejecución de tareas en nombre del controlador de Jenkins usando ejecutores. Un agente puede usar cualquier sistema operativo que soporte Java. Las herramientas necesarias para las construcciones y pruebas se instalan en el nodo donde se ejecuta el agente; pueden instalarse directamente o en un contenedor (Docker o Kubernetes). Cada agente es efectivamente un proceso con su propio PID en la máquina host.
Un ejecutor es un espacio para la ejecución de tareas; efectivamente, es un hilo en el agente. El número de ejecutores en un nodo define el número de tareas concurrentes que pueden ejecutarse en ese nodo al mismo tiempo. En otras palabras, esto determina el número de stages de Pipeline concurrentes que pueden ejecutarse en ese nodo al mismo tiempo.
Secretos de Jenkins
Encriptación de Secretos y Credenciales
Definición de la documentación: Jenkins usa AES para encriptar y proteger secretos, credenciales y sus respectivas claves de encriptación. Estas claves de encriptación se almacenan en $JENKINS_HOME/secrets/ junto con la clave maestra utilizada para proteger dichas claves. Este directorio debe configurarse para que solo el usuario del sistema operativo en el que se ejecuta el controlador de Jenkins tenga acceso de lectura y escritura a este directorio (es decir, un valor de chmod de 0700 o usando atributos de archivo apropiados). La clave maestra (a veces referida como "clave de encriptación de clave" en jerga criptográfica) se almacena _sin encriptar_ en el sistema de archivos del controlador de Jenkins en $JENKINS_HOME/secrets/master.key, lo que no protege contra atacantes con acceso directo a ese archivo. La mayoría de los usuarios y desarrolladores usarán estas claves de encriptación indirectamente a través de la API de Secret para encriptar datos secretos genéricos o a través de la API de credenciales. Para los curiosos de la criptografía, Jenkins usa AES en modo de encadenamiento de bloques de cifrado (CBC) con padding PKCS#5 e IVs aleatorios para encriptar instancias de CryptoConfidentialKey que se almacenan en $JENKINS_HOME/secrets/ con un nombre de archivo correspondiente a su id de CryptoConfidentialKey. Los ids de clave comunes incluyen:
hudson.util.Secret: usado para secretos genéricos;com.cloudbees.plugins.credentials.SecretBytes.KEY: usado para algunos tipos de credenciales;jenkins.model.Jenkins.crumbSalt: usado por el mecanismo de protección CSRF; y
Acceso a Credenciales
Las credenciales pueden ser delimitadas a proveedores globales (/credentials/) que pueden ser accedidos por cualquier proyecto configurado, o pueden ser delimitadas a proyectos específicos (/job/<project-name>/configure) y por lo tanto solo accesibles desde el proyecto específico.
Según la documentación: Las credenciales que están en el ámbito están disponibles para el pipeline sin limitaciones. Para prevenir la exposición accidental en el registro de construcción, las credenciales son enmascaradas de la salida regular, por lo que una invocación de env (Linux) o set (Windows), o programas que imprimen su entorno o parámetros no las revelarán en el registro de construcción a usuarios que de otro modo no tendrían acceso a las credenciales.
Es por eso que para exfiltrar las credenciales un atacante necesita, por ejemplo, codificarlas en base64.
Referencias
Last updated
