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 generalmente se llama JSESSIONID.*. (Un usuario puede terminar todas sus sesiones, pero primero necesitaría averiguar que una cookie fue robada).
SSO/Plugins
Jenkins puede ser configurado usando plugins para ser accesible a través de SSO de terceros.
Tokens
Los usuarios pueden generar tokens para dar acceso a aplicaciones para suplantarlos a través de 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 "admin", se te otorgará control total sobre el sistema, y de lo contrario (incluyendo a los usuarios anónimos) tendrás acceso de lectura.
Los 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 Proyectos: Este modo es una extensión de "seguridad basada en matriz" que permite definir una matriz ACL adicional para ser definida para cada proyecto por separado.
Estrategia Basada en Roles: Permite definir autorizaciones usando una estrategia basada en roles. Administra los roles en
/role-strategy.
Reino de Seguridad
En /configureSecurity es posible configurar el reino de seguridad. Por defecto, Jenkins incluye soporte para algunos reinos 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 la propia base de datos de usuarios integrada 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 OS de Unix en el controlador de Jenkins. Este modo también permitirá reutilizar grupos de Unix para autorización.
Los plugins pueden proporcionar reinos de seguridad adicionales que pueden ser útiles para incorporar Jenkins en sistemas de identidad existentes, 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 en busca de espacio en disco, espacio temporal libre, intercambio libre, tiempo/sincronización del reloj y tiempo de respuesta. Un nodo se desconecta si alguno de estos valores sale del umbral configurado.
Agentes gestionan la ejecución de tareas en nombre del controlador de Jenkins utilizando ejecutores. Un agente puede usar cualquier sistema operativo que soporte Java. Las herramientas requeridas para construcciones y pruebas se instalan en el nodo donde se ejecuta el agente; pueden ser instaladas 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 ser ejecutadas 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
Cifrado de Secretos y Credenciales
Definición de la documentación: Jenkins utiliza AES para cifrar y proteger secretos, credenciales y sus respectivas claves de cifrado. Estas claves de cifrado se almacenan en $JENKINS_HOME/secrets/ junto con la clave maestra utilizada para proteger dichas claves. Este directorio debe ser configurado para que solo el usuario del sistema operativo bajo el cual 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 cifrado de clave" en jerga criptográfica) se almacena _sin cifrar_ 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 utilizarán estas claves de cifrado indirectamente a través de la API Secret para cifrar datos secretos genéricos o a través de la API de credenciales. Para los curiosos sobre criptografía, Jenkins utiliza AES en modo de encadenamiento de bloques (CBC) con relleno PKCS#5 y IVs aleatorios para cifrar 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: utilizado para secretos genéricos;com.cloudbees.plugins.credentials.SecretBytes.KEY: utilizado para algunos tipos de credenciales;jenkins.model.Jenkins.crumbSalt: utilizado por el mecanismo de protección CSRF; y
Acceso a Credenciales
Las credenciales pueden ser escaladas a proveedores globales (/credentials/) que pueden ser accedidos por cualquier proyecto configurado, o pueden ser escaladas a proyectos específicos (/job/<project-name>/configure) y, por lo tanto, solo accesibles desde el proyecto específico.
De acuerdo con la documentación: Las credenciales que están en el ámbito están disponibles para la 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ían en el registro de construcción a usuarios que de otro modo no tendrían acceso a las credenciales.
Por eso, para exfiltrar las credenciales, un atacante necesita, por ejemplo, codificarlas en base64.
Referencias
Last updated
