Basic Jenkins Information
Acesso
Nome de Usuário + Senha
A maneira mais comum de fazer login no Jenkins é com um nome de usuário ou uma senha.
Cookie
Se um cookie autorizado for roubado, ele pode ser usado para acessar a sessão do usuário. O cookie geralmente é chamado de JSESSIONID.*. (Um usuário pode encerrar todas as suas sessões, mas ele precisaria descobrir primeiro que um cookie foi roubado).
SSO/Plugins
O Jenkins pode ser configurado usando plugins para ser acessível via SSO de terceiros.
Tokens
Usuários podem gerar tokens para dar acesso a aplicativos para se passarem por eles via CLI ou REST API.
Chaves SSH
Este componente fornece um servidor SSH embutido para o Jenkins. É uma interface alternativa para o Jenkins CLI, e comandos podem ser invocados dessa forma usando qualquer cliente SSH. (Dos docs)
Autorização
Em /configureSecurity é possível configurar o método de autorização do Jenkins. Existem várias opções:
Qualquer um pode fazer qualquer coisa: Até mesmo o acesso anônimo pode administrar o servidor.
Modo legado: Igual ao Jenkins <1.164. Se você tiver o papel "admin", terá controle total sobre o sistema, e caso contrário (incluindo usuários anônimos) terá acesso de leitura.
Usuários logados podem fazer qualquer coisa: Nesse modo, todo usuário logado tem controle total do Jenkins. O único usuário que não terá controle total é o usuário anônimo, que só terá acesso de leitura.
Segurança baseada em matriz: Você pode configurar quem pode fazer o quê em uma tabela. Cada coluna representa uma permissão. Cada linha representa um usuário ou um grupo/papel. Isso inclui um usuário especial 'anônimo', que representa usuários não autenticados, bem como 'autenticado', que representa todos os usuários autenticados.
Estratégia de Autorização de Matriz Baseada em Projeto: Este modo é uma extensão da "Segurança baseada em matriz" que permite que uma matriz ACL adicional seja definida para cada projeto separadamente.
Estratégia Baseada em Papéis: Permite definir autorizações usando uma estratégia baseada em papéis. Gerencie os papéis em
/role-strategy.
Realm de Segurança
Em /configureSecurity é possível configurar o realm de segurança. Por padrão, o Jenkins inclui suporte para alguns Realms de Segurança diferentes:
Delegar para o contêiner de servlet: Para delegar a autenticação a um contêiner de servlet executando o controlador Jenkins, como Jetty.
Banco de dados de usuários do próprio Jenkins: Use o próprio banco de dados de usuários embutido do Jenkins para autenticação em vez de delegar para um sistema externo. Isso é habilitado por padrão.
LDAP: Delegue toda a autenticação para um servidor LDAP configurado, incluindo usuários e grupos.
Banco de dados de usuários/grupos Unix: Delega a autenticação para o banco de dados de usuários em nível de sistema operacional Unix subjacente no controlador Jenkins. Este modo também permitirá o reuso de grupos Unix para autorização.
Plugins podem fornecer realms de segurança adicionais que podem ser úteis para incorporar o Jenkins em sistemas de identidade existentes, como:
Jenkins Nodes, Agents & Executors
Definições dos docs:
Nodes são as máquinas nas quais os agents de build são executados. O Jenkins monitora cada node anexado para espaço em disco, espaço temporário livre, swap livre, tempo/sincronização do relógio e tempo de resposta. Um node é colocado offline se algum desses valores ultrapassar o limite configurado.
Agents gerenciam a execução de tarefas em nome do controlador Jenkins usando executors. Um agent pode usar qualquer sistema operacional que suporte Java. Ferramentas necessárias para builds e testes são instaladas no node onde o agent é executado; elas podem ser instaladas diretamente ou em um contêiner (Docker ou Kubernetes). Cada agent é efetivamente um processo com seu próprio PID na máquina host.
Um executor é um slot para execução de tarefas; efetivamente, é um thread no agent. O número de executors em um node define o número de tarefas simultâneas que podem ser executadas nesse node ao mesmo tempo. Em outras palavras, isso determina o número de stages de Pipeline simultâneos que podem ser executados nesse node ao mesmo tempo.
Segredos do Jenkins
Criptografia de Segredos e Credenciais
Definição dos docs: O Jenkins usa AES para criptografar e proteger segredos, credenciais e suas respectivas chaves de criptografia. Essas chaves de criptografia são armazenadas em $JENKINS_HOME/secrets/ junto com a chave mestre usada para proteger essas chaves. Este diretório deve ser configurado para que apenas o usuário do sistema operacional no qual o controlador Jenkins está sendo executado tenha acesso de leitura e gravação a este diretório (ou seja, um valor chmod de 0700 ou usando atributos de arquivo apropriados). A chave mestre (às vezes referida como "chave de criptografia de chave" no jargão criptográfico) é armazenada _sem criptografia_ no sistema de arquivos do controlador Jenkins em $JENKINS_HOME/secrets/master.key o que não protege contra atacantes com acesso direto a esse arquivo. A maioria dos usuários e desenvolvedores usará essas chaves de criptografia indiretamente via API Secret para criptografar dados secretos genéricos ou através da API de credenciais. Para os curiosos em criptografia, o Jenkins usa AES no modo de encadeamento de blocos de cifra (CBC) com preenchimento PKCS#5 e IVs aleatórios para criptografar instâncias de CryptoConfidentialKey que são armazenadas em $JENKINS_HOME/secrets/ com um nome de arquivo correspondente ao id do CryptoConfidentialKey. Ids de chave comuns incluem:
hudson.util.Secret: usado para segredos genéricos;com.cloudbees.plugins.credentials.SecretBytes.KEY: usado para alguns tipos de credenciais;jenkins.model.Jenkins.crumbSalt: usado pelo mecanismo de proteção CSRF; e
Acesso a Credenciais
As credenciais podem ser escopadas para provedores globais (/credentials/) que podem ser acessados por qualquer projeto configurado, ou podem ser escopadas para projetos específicos (/job/<project-name>/configure) e, portanto, acessíveis apenas pelo projeto específico.
De acordo com os docs: As credenciais que estão no escopo são disponibilizadas para o pipeline sem limitação. Para evitar exposição acidental no log de build, as credenciais são mascaradas da saída regular, então uma invocação de env (Linux) ou set (Windows), ou programas que imprimem seu ambiente ou parâmetros não as revelarão no log de build para usuários que não teriam acesso às credenciais de outra forma.
É por isso que, para exfiltrar as credenciais, um atacante precisa, por exemplo, codificá-las em base64.
Referências
Last updated
