Project-based Authorization

작성일: 2026. 3. 30.

프로젝트 단위 권한 관리는 Jenkins를 다중 팀 환경에서 안전하게 운영하기 위한 기본 전략입니다.

왜 필요한가

• 팀 A가 팀 B 파이프라인을 수정하거나 실행하는 사고를 방지합니다.
• 운영/개발/QA 권한을 분리해 변경 책임을 명확하게 관리할 수 있습니다.
• 감사 로그에서 누가 어떤 프로젝트에 접근했는지 쉽게 추적할 수 있습니다.

권장 구성

1. 프로젝트별 그룹(예: proj-a-dev, proj-a-admin)을 먼저 설계합니다.
2. 폴더/잡 단위로 Read, Build, Configure 권한을 최소 권한으로 부여합니다.
3. 공용 라이브러리 잡은 읽기 권한만 넓게 열고, 수정 권한은 운영 그룹으로 제한합니다.
4. 권한 템플릿을 문서화해 신규 프로젝트 생성 시 같은 규칙을 재사용합니다.

운영 체크리스트

• 퇴사/이동 인원 권한 회수 자동화 여부
• 관리자 권한 계정 사용 최소화
• 폴더 상속 권한과 개별 잡 권한 충돌 점검
• 분기별 접근 권한 리뷰

Jenkins에서의 적용 방식

폴더(Folder)로 팀·제품·환경(dev/stage/prod)을 나누고, 폴더 단위 ACL을 거는 방식이 가장 흔합니다. CloudBees Folder Plugin 등으로 계층을 만들면 상위 폴더 권한을 상속받아 운영 부담을 줄일 수 있습니다.

Role-based Authorization Strategy 플러그인을 쓰면 정규식 패턴(예: ^team-alpha/.*)으로 잡 경로와 매칭해 롤을 묶어 줄 수 있어, 잡이 늘어나도 권한 설정이 반복되지 않습니다.

설계 전에 정할 것

• 누가 잡을 만들고 삭제할 수 있는가(폴더 관리자 vs 일반 개발자)
• 크리덴셜은 폴더 스코프로 제한할 것인가, 전역으로 둘 것인가
• 파이프라인 스크립트 수정 권한과 빌드 실행 권한을 분리할 것인가
• 읽기 전용 대시보드용 계정이 필요한가

트러블슈팅

• 예상과 다른 권한이 보일 때: 상위 폴더·전역 롤·상속 설정을 역순으로 확인합니다.
• 빌드는 되는데 로그/아티팩트가 안 보일 때: 해당 잡의 Workspace 관련 권한과 플러그인별 권한을 점검합니다.

원문: Project-based Authorization

목록으로