Basic Jenkins Information
Acesso
Nome de Usuário + Senha
A forma 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 primeiro precisaria descobrir 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 integrado para o Jenkins. É uma interface alternativa para o Jenkins CLI, e comandos podem ser invocados dessa maneira usando qualquer cliente SSH. (Dos documentos)
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: Mesmo o acesso anônimo pode administrar o servidor.
Modo legado: O mesmo que o Jenkins <1.164. Se você tiver a função de "admin", terá controle total sobre o sistema, e caso contrário (incluindo usuários anônimos), terá acesso somente leitura.
Usuários logados podem fazer qualquer coisa: Neste modo, cada usuário logado tem controle total do Jenkins. O único usuário que não terá controle total é o usuário anônimo, que terá apenas acesso somente 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 definir matrizes ACL adicionais para cada projeto separadamente.
Estratégia Baseada em Função: Permite definir autorizações usando uma estratégia baseada em função. Gerencie as funções em
/role-strategy.
Reino de Segurança
Em /configureSecurity é possível configurar o reino de segurança. Por padrão, o Jenkins inclui suporte para alguns Reinos de Segurança diferentes:
Delegar ao contêiner servlet: Para delegar autenticação a um contêiner servlet executando o controlador Jenkins, como Jetty.
Banco de dados de usuários próprio do Jenkins: Use o banco de dados de usuários integrado do Jenkins para autenticação em vez de delegar para um sistema externo. Isso é habilitado por padrão.
LDAP: Delega 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 do Unix no nível do sistema operacional subjacente no controlador Jenkins. Este modo também permitirá o reuso de grupos Unix para autorização.
Os plugins podem fornecer reinos de segurança adicionais que podem ser úteis para incorporar o Jenkins em sistemas de identidade existentes, como:
Nós, Agentes e Executores do Jenkins
Definições dos documentos:
Nós são as máquinas em que os agentes de build são executados. O Jenkins monitora cada nó anexado quanto ao espaço em disco, espaço temporário livre, swap livre, tempo/sincronização do relógio e tempo de resposta. Um nó é retirado offline se algum desses valores ultrapassar o limite configurado.
Agentes gerenciam a execução de tarefas em nome do controlador Jenkins usando executores. Um agente pode usar qualquer sistema operacional que suporte Java. As ferramentas necessárias para builds e testes são instaladas no nó onde o agente é executado; elas podem ser instaladas diretamente ou em um contêiner (Docker ou Kubernetes). Cada agente é efetivamente um processo com seu próprio PID na máquina host.
Um executor é um slot para a execução de tarefas; efetivamente, é uma thread no agente. O número de executores em um nó define o número de tarefas concorrentes que podem ser executadas nesse nó ao mesmo tempo. Em outras palavras, isso determina o número de estágios de Pipeline concorrentes que podem ser executados nesse nó ao mesmo tempo.
Segredos do Jenkins
Criptografia de Segredos e Credenciais
Definição dos documentos: 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/ juntamente com a chave mestra usada para proteger tais 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 mestra (às vezes referida como "chave de criptografia de chave" em jargão criptográfico) é armazenada _não criptografada_ 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 por meio da API Secret para criptografar dados secretos genéricos ou por meio da API de credenciais. Para os curiosos sobre criptografia, o Jenkins usa AES no modo de encadeamento de blocos (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 seu id CryptoConfidentialKey. Os 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 limitadas a provedores globais (/credentials/) que podem ser acessadas por qualquer projeto configurado, ou podem ser limitadas a projetos específicos (/job/<nome-do-projeto>/configure) e, portanto, só acessíveis a partir do projeto específico.
De acordo com a documentação: As credenciais que estão no escopo são disponibilizadas para o pipeline sem limitações. Para evitar exposição acidental no log de compilação, as credenciais são mascaradas na 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 revelariam no log de compilação para usuários que não teriam acesso às credenciais de outra forma.
Por isso, para extrair as credenciais, um atacante precisa, por exemplo, codificá-las em base64.
Referências
Última actualización
