Basic Jenkins Information
Acceso
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 suele llamarse JSESSIONID.*. (Un usuario puede terminar todas sus sesiones, pero primero tendría que descubrir que se robó una cookie).
SSO/Plugins
Jenkins se puede configurar utilizando 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 CLI de Jenkins, y los comandos se pueden invocar de esta manera utilizando 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 heredado: Igual que Jenkins <1.164. Si tienes el rol de "admin", se te otorgará control total sobre el sistema, y de lo contrario (incluidos los usuarios anónimos) tendrás acceso de lectura.
Los usuarios conectados pueden hacer cualquier cosa: En este modo, cada usuario conectado 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 los usuarios no autenticados, así como 'autenticado', que representa a todos los usuarios autenticados.
Estrategia de autorización de matriz basada en proyectos: 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 utilizando una estrategia basada en roles. Gestiona los roles en
/role-strategy.
Reino de seguridad
En /configureSecurity es posible configurar el reino de seguridad. Por defecto, Jenkins incluye soporte para varios Reinos de Seguridad diferentes:
Delegar al contenedor servlet: Para delegar la autenticación a un contenedor servlet que ejecuta el controlador Jenkins, como Jetty.
Base de datos de usuarios propia de Jenkins: Utiliza la propia base de datos de usuarios integrada de Jenkins para la autenticación en lugar de delegar en un sistema externo. Esto está habilitado por defecto.
LDAP: Delega toda la autenticación a un servidor LDAP configurado, incluidos usuarios y grupos.
Base de datos de usuarios/grupos Unix: Delega la autenticación al nivel de base de datos de usuarios Unix subyacente en el controlador Jenkins. Este modo también permitirá reutilizar los grupos Unix para la 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 para el espacio en disco, espacio temporal libre, intercambio libre, tiempo/reloj sincronizado y tiempo de respuesta. Un nodo se desconecta si alguno de estos valores supera el umbral configurado.
Agentes gestionan la ejecución de tareas en nombre del controlador Jenkins mediante ejecutores. Un agente puede utilizar cualquier sistema operativo que admita Java. Las herramientas requeridas 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 la cantidad de tareas concurrentes que se pueden ejecutar en ese nodo al mismo tiempo. En otras palabras, esto determina la cantidad 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 utiliza 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 está ejecutando el controlador Jenkins tenga acceso de lectura y escritura a este directorio (es decir, un valor chmod de 0700 o utilizando atributos de archivo apropiados). La clave maestra (a veces denominada "clave de encriptación de clave" en la jerga criptográfica) se almacena _sin encriptar_ en el sistema de archivos del controlador 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 encriptación indirectamente a través de la API Secret para encriptar datos secretos genéricos o a través de la API de credenciales. Para los curiosos de la criptografía, Jenkins utiliza AES en modo de cifrado por bloques encadenados (CBC) con relleno 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: 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 estar limitadas a proveedores globales (/credentials/) que pueden ser accedidos por cualquier proyecto configurado, o pueden estar limitadas a proyectos específicos (/job/<nombre-del-proyecto>/configure) y por lo tanto solo accesibles desde el proyecto específico.
Según la documentación: Las credenciales que están en el alcance están disponibles para el pipeline sin limitaciones. Para prevenir la exposición accidental en el registro de construcción, las credenciales están enmascaradas en 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 otra manera no tendrían acceso a las credenciales.
Por eso, para extraer las credenciales, un atacante necesita, por ejemplo, codificarlas en base64.
Referencias
Última actualización
