[Jenkins] 관리자 계정 생성 및 권한 분리 (보안 마스터 가이드)

인프라 구축 초기에는 보통 최고 관리자(admin) 계정 하나로 모든 개발자가 돌려 쓰는 경우가 많습니다. "우리는 작은 스타트업이라 괜찮아"라고 생각할 수 있지만, 팀 규모가 커지고 다양한 프로젝트가 맞물리기 시작하면 이는 시한폭탄과 다름없습니다. 누군가 실수로 다른 팀의 빌드 설정을 지워버리거나, 인턴 개발자가 실수로 운영 서버 배포 버튼을 눌러버리는 대형 사고(Human Error)가 발생하기 십상이기 때문입니다. 이번 [Jenkins 실무 완벽 가이드] 포스팅에서는 대규모 엔터프라이즈 환경에서 필수적으로 적용하는 Role-based Authorization(역할 기반 권한 관리) 전략을 통해 완벽한 보안 환경을 구축하는 방법을 3,000자에 걸쳐 깊이 있게 딥다이브 해보겠습니다.

🚨 1. 왜 권한 분리(Authorization Strategy)가 필수적인가?

Jenkins는 기본적으로 코드를 클론(Clone)받고, 쉘 스크립트를 실행하며, 타 서버로 SSH 접속까지 할 수 있는 막강한 권한을 가진 시스템입니다. 만약 인증(Authentication)과 권한 인가(Authorization)가 제대로 되어 있지 않다면, 사내망에 접속할 수 있는 누구나 젠킨스에 들어와 악성 코드를 심거나 데이터베이스 비밀번호 같은 환경변수(Credentials)를 탈취할 수 있습니다.

기본 설치 상태에서 제공되는 'Logged-in users can do anything(로그인한 사용자는 모든 것을 할 수 있음)' 설정이나 'Matrix-based security(매트릭스 기반 보안)'는 5명 이하의 소규모 팀에서는 유효할지 몰라도, 수십 명의 개발자가 백엔드, 프론트엔드, 데이터팀으로 나뉘어 일하는 실무 환경에서는 권한 관리가 기하급수적으로 복잡해집니다. 따라서 특정 '그룹(역할)'을 만들고 사용자를 그 그룹에 매핑시키는 Role-based 접근 제어 방식(RBAC)이 가장 강력한 권장 사항입니다.

🧩 2. Role-based Authorization Strategy 플러그인 설치 및 활성화

강력한 역할 기반 권한 분리를 위해서는 먼저 공식 플러그인을 설치해야 합니다.

1. Jenkins 메인 대시보드에서 좌측의 [Jenkins 관리(Manage Jenkins)] -> [플러그인 관리(Manage Plugins)]로 이동합니다.
2. Available(설치 가능) 탭을 클릭하고 검색창에 Role-based Authorization Strategy를 검색하여 체크한 뒤 설치(Install without restart)를 진행합니다.
3. 설치가 완료되면 다시 [Jenkins 관리] -> [Security(보안 설정)] 메뉴로 들어갑니다.
4. Authorization(권한 부여) 섹션을 찾습니다. 기본값으로 되어있던 설정을 방금 설치한 Role-Based Strategy 라디오 버튼으로 변경하고 하단의 저장(Save)을 누릅니다.

⚠️ 주의사항: 이 설정을 저장하는 순간 기존의 권한 룰이 모두 초기화되고 새로운 룰이 적용됩니다. 본인이 현재 로그인한 admin 계정이 락아웃(Lockout)되는 불상사를 막기 위해, 즉시 다음 단계인 역할 생성으로 넘어가 최고 관리자 권한부터 할당해야 합니다.

⚙️ 3. 역할(Role)의 3가지 유형 완벽 이해하기

권한 전략을 `Role-Based Strategy`로 변경했다면, 메인 대시보드의 [Jenkins 관리] 메뉴 하단에 [Manage and Assign Roles]라는 새로운 톱니바퀴 아이콘이 생겼을 것입니다. 이 메뉴로 들어가면 역할을 생성하는 곳(Manage Roles)과, 생성된 역할을 유저에게 부여하는 곳(Assign Roles)으로 나뉩니다. 먼저 역할을 생성해 보겠습니다.

Manage Roles 창에는 세 가지 유형의 Role 탭이 존재합니다.

• Global roles (전역 역할): 젠킨스 시스템 전체에 미치는 권한입니다. 전체 관리자 설정(Administer)이나 최소한 젠킨스를 볼 수 있는 권한(Overall Read) 등을 부여합니다.
• Item roles (아이템/프로젝트 역할): 폴더나 파이프라인(Job) 단위로 권한을 제어합니다. 가장 많이 쓰이며 정규표현식(Regex)을 이용해 특정 패턴의 Job에만 권한을 할당할 수 있습니다.
• Node roles (노드 역할): 빌드를 수행하는 Agent(Node) 머신들에 대한 제어 권한입니다. (보통 인프라 관리자만 통제하므로 잘 쓰지 않습니다.)

🛡️ 4. 실무 적용: Global Role 및 Item Role 설계하기

실무에서는 보통 다음과 같이 권한을 세밀하게 분할합니다. 아래 설정법을 그대로 따라 하시면 완벽한 권한 분리 아키텍처가 완성됩니다.

Step 1. Global roles 설계:

• admin (최고 관리자): Overall의 Administer를 포함한 모든 체크박스에 체크합니다.
• developer (일반 개발자): 젠킨스에 로그인해서 화면을 볼 수만 있어야 하므로 Overall의 Read 항목 하나만 체크합니다. (이 권한이 없으면 로그인해도 빈 화면만 보입니다.)

Step 2. Item roles 설계 (정규표현식 활용):

개발자들이 자신이 속한 파트의 잡(Job)만 보이게 하고, 타 팀의 잡은 아예 보이지 않게 감추는 실무 필살기입니다.

• frontend-dev (프론트엔드 개발자 그룹): Role to add에 입력 후, Pattern 칸에 ^frontend-.* 라고 입력합니다. 이는 Job의 이름이 'frontend-'로 시작하는 모든 프로젝트를 의미합니다. Job의 Read(조회), Build(빌드), Workspace(소스보기) 권한만 부여하고 Delete(삭제)나 Configure(설정 변경) 권한은 주지 않습니다.
• backend-dev (백엔드 개발자 그룹): Pattern 칸에 ^backend-.* 라고 입력하고 동일한 권한을 부여합니다.

👥 5. 사용자(User) 생성 및 역할 할당(Assign Roles)

역할이라는 '틀'을 만들었으니, 이제 실제 사람(계정)을 만들어 그 틀에 끼워 넣을 차례입니다.

1. [Jenkins 관리] -> [Manage Users] -> [Create User]에서 프론트엔드 개발자 A를 위한 계정 `user_fe`, 백엔드 개발자 B를 위한 계정 `user_be`를 각각 생성합니다.
2. 다시 [Manage and Assign Roles] -> [Assign Roles]로 들어갑니다.
3. Global roles 매핑: 방금 만든 `user_fe`, `user_be`를 추가하고, 이들에게 아까 만들어둔 `developer` 체크박스에 체크합니다. (admin 계정은 반드시 `admin`에 체크가 되어 있어야 합니다!)
4. Item roles 매핑: `user_fe` 계정을 추가하고 `frontend-dev` 역할에 체크합니다. `user_be` 계정을 추가하고 `backend-dev` 역할에 체크합니다.

🎯 6. 마무리 및 테스트

모든 저장이 끝났다면 테스트를 위해 새로운 Job을 두 개 만들어 봅니다. 하나는 frontend-web-deploy, 다른 하나는 backend-api-deploy라는 이름으로 대충 생성합니다.

이제 시크릿 모드(혹은 다른 브라우저)를 열어 user_fe 계정으로 로그인해 보십시오. 대시보드에는 오직 frontend-web-deploy Job 하나만 보일 것이며, 좌측 메뉴에 'Jenkins 관리'나 '설정(Configure)' 같은 위험한 메뉴는 싹 사라져 있을 것입니다. 오직 [Build Now] 버튼만 누를 수 있는 완벽한 통제 환경이 만들어졌습니다.

지금까지 Role-based Authorization Strategy 플러그인을 활용하여 실무 엔터프라이즈 환경에 걸맞은 완벽한 권한 분리 모델을 설계하는 방법에 대해 3,000자 분량으로 상세히 알아보았습니다. 보안 통제가 확실해졌으니, 다음 5단계 포스팅에서는 개발자가 코드를 푸시하면 젠킨스가 이를 감지하여 자동으로 빌드를 돌려주는 'Github Webhook과의 자동화 연동'이라는 CI/CD의 꽃을 피워보도록 하겠습니다!