Basic Jenkins Information
Access
Username + Password
가장 일반적인 Jenkins 로그인 방법은 사용자 이름과 비밀번호를 사용하는 것입니다.
Cookie
인증된 쿠키가 도난당하면, 이를 사용하여 사용자의 세션에 접근할 수 있습니다. 쿠키는 보통 JSESSIONID.*로 불립니다. (사용자는 모든 세션을 종료할 수 있지만, 먼저 쿠키가 도난당했음을 알아야 합니다).
SSO/Plugins
Jenkins는 플러그인을 사용하여 타사 SSO를 통해 접근 가능하도록 구성할 수 있습니다.
Tokens
사용자는 토큰을 생성하여 CLI 또는 REST API를 통해 애플리케이션이 자신을 대리하여 접근할 수 있도록 할 수 있습니다.
SSH Keys
이 구성 요소는 Jenkins를 위한 내장 SSH 서버를 제공합니다. 이는 Jenkins CLI의 대체 인터페이스이며, 모든 SSH 클라이언트를 사용하여 이 방식으로 명령을 호출할 수 있습니다. (문서에서 발췌)
Authorization
/configureSecurity에서 Jenkins의 인증 방법을 구성할 수 있습니다. 여러 가지 옵션이 있습니다:
누구나 모든 것을 할 수 있음: 익명 접근조차 서버를 관리할 수 있습니다.
레거시 모드: Jenkins <1.164와 동일합니다. "admin" 역할이 있으면 시스템에 대한 전체 제어 권한이 부여되며, 그 외 (익명 사용자를 포함하여) 읽기 권한만 부여됩니다.
로그인한 사용자는 모든 것을 할 수 있음: 이 모드에서는 모든 로그인한 사용자가 Jenkins에 대한 전체 제어 권한을 갖습니다. 유일하게 전체 제어 권한이 없는 사용자는 익명 사용자로, 읽기 권한만 부여됩니다.
매트릭스 기반 보안: 테이블에서 누가 무엇을 할 수 있는지 구성할 수 있습니다. 각 열은 권한을 나타내고, 각 행은 사용자 또는 그룹/역할을 나타냅니다. 여기에는 인증되지 않은 사용자를 나타내는 특별한 사용자 'anonymous'와 모든 인증된 사용자를 나타내는 'authenticated'가 포함됩니다.
프로젝트 기반 매트릭스 인증 전략: 이 모드는 각 프로젝트에 대해 추가 ACL 매트릭스를 정의할 수 있는 "매트릭스 기반 보안"의 확장입니다.
역할 기반 전략: 역할 기반 전략을 사용하여 인증을 정의할 수 있습니다.
/role-strategy에서 역할을 관리합니다.
Security Realm
/configureSecurity에서 보안 영역을 구성할 수 있습니다. 기본적으로 Jenkins는 몇 가지 다른 보안 영역을 지원합니다:
서블릿 컨테이너에 위임: Jenkins 컨트롤러를 실행하는 서블릿 컨테이너(예: Jetty)에 인증을 위임합니다.
Jenkins 자체 사용자 데이터베이스: 외부 시스템에 위임하는 대신 Jenkins의 자체 내장 사용자 데이터 저장소를 사용하여 인증합니다. 기본적으로 활성화되어 있습니다.
LDAP: 구성된 LDAP 서버에 모든 인증을 위임하여 사용자와 그룹을 포함합니다.
유닉스 사용자/그룹 데이터베이스: Jenkins 컨트롤러의 기본 유닉스 OS 수준 사용자 데이터베이스에 인증을 위임합니다. 이 모드는 인증에 유닉스 그룹을 재사용할 수 있도록 합니다.
플러그인은 Jenkins를 기존의 ID 시스템에 통합하는 데 유용할 수 있는 추가 보안 영역을 제공할 수 있습니다. 예를 들어:
Jenkins Nodes, Agents & Executors
문서에서 발췌한 정의:
Nodes는 빌드 에이전트가 실행되는 머신입니다. Jenkins는 디스크 공간, 임시 공간, 스왑 공간, 시계 시간/동기화 및 응답 시간을 모니터링합니다. 이러한 값이 구성된 임계값을 벗어나면 노드는 오프라인 상태가 됩니다.
Agents는 Jenkins 컨트롤러를 대신하여 작업 실행을 관리하며, 실행기를 사용합니다. 에이전트는 Java를 지원하는 모든 운영 체제를 사용할 수 있습니다. 빌드 및 테스트에 필요한 도구는 에이전트가 실행되는 노드에 설치됩니다. 도구는 직접 설치하거나 컨테이너(Docker 또는 Kubernetes)에서 설치할 수 있습니다. 각 에이전트는 호스트 머신에서 자체 PID를 가진 프로세스입니다.
Executor는 작업 실행 슬롯으로, 에이전트의 스레드입니다. 노드의 실행기 수는 한 번에 해당 노드에서 실행할 수 있는 동시 작업 수를 정의합니다. 즉, 이는 한 번에 해당 노드에서 실행할 수 있는 동시 파이프라인 stages 수를 결정합니다.
Jenkins Secrets
Encryption of Secrets and Credentials
문서에서 발췌한 정의: Jenkins는 AES를 사용하여 비밀과 자격 증명, 해당 암호화 키를 보호합니다. 이러한 암호화 키는 $JENKINS_HOME/secrets/에 저장되며, 해당 키를 보호하는 마스터 키도 함께 저장됩니다. 이 디렉토리는 Jenkins 컨트롤러가 실행되는 운영 체제 사용자만 읽기 및 쓰기 권한을 가지도록 구성해야 합니다(예: chmod 값 0700 또는 적절한 파일 속성 사용). 마스터 키(암호학 용어로 "키 암호화 키"라고도 함)는 **$JENKINS_HOME/secrets/master.key**에 암호화되지 않은 상태로 Jenkins 컨트롤러 파일 시스템에 저장되며, 해당 파일에 직접 접근할 수 있는 공격자에게는 보호되지 않습니다. 대부분의 사용자와 개발자는 Secret API를 통해 일반 비밀 데이터를 암호화하거나 자격 증명 API를 통해 간접적으로 이러한 암호화 키를 사용합니다. 암호화에 관심이 있는 사람들을 위해, Jenkins는 PKCS#5 패딩 및 랜덤 IV를 사용하여 AES를 암호 블록 체인(CBC) 모드로 사용하여 CryptoConfidentialKey 인스턴스를 암호화하며, 이는 $JENKINS_HOME/secrets/에 해당 CryptoConfidentialKey ID에 해당하는 파일 이름으로 저장됩니다. 일반적인 키 ID는 다음과 같습니다:
hudson.util.Secret: 일반 비밀에 사용됨;com.cloudbees.plugins.credentials.SecretBytes.KEY: 일부 자격 증명 유형에 사용됨;jenkins.model.Jenkins.crumbSalt: CSRF 보호 메커니즘에 사용됨;
Credentials Access
자격 증명은 글로벌 제공자 (/credentials/)에 범위가 지정되어 모든 구성된 프로젝트에서 접근할 수 있거나, 특정 프로젝트 (/job/<project-name>/configure)에 범위가 지정되어 해당 특정 프로젝트에서만 접근할 수 있습니다.
문서에 따르면: 범위 내의 자격 증명은 파이프라인에 제한 없이 제공됩니다. 빌드 로그에서 우발적인 노출을 방지하기 위해, 자격 증명은 일반 출력에서 마스킹되므로, env (Linux) 또는 set (Windows)의 호출이나 환경 또는 매개변수를 출력하는 프로그램은 빌드 로그에서 자격 증명을 노출하지 않습니다.
따라서 공격자가 자격 증명을 유출하려면 예를 들어 base64로 인코딩해야 합니다.
References
Last updated
