제로 트러스트 아키텍처 SAML 2.0 SSO 연동으로 DevOps 툴 접근제어JenKins

Gitlab, Github, Jenkins 등 DevOps, CI/CD을 위한 툴이 많습니다. 하지만 대부분의 툴들은 계정들을 자체적으로 생성해 쓰게 되는데 이른바 "admin" 같은 계정을 만들어 사용자들은 패스워드를 공유하며 하나의 계정을 돌려 쓰게 됩니다.

 

이러다 보니 누가 언제 admin 이란 계정으로 들어가 어떤 작업을 했는지 추적이 불가능하며 아무렇게 방치되는 패스워드는 해킹의 노출에 심각하게 방치되어 있습니다. 

 

그렇다면 일일히 사용자마다 개별 계정을 만들어 주면 되지 않을까라고 생각할 수 있지만 사용자가 가지고 있는 devops 툴 계정이 몇 개나 늘어날지 그리고  계정들이 똑같은 아이디/패스워드로 관리된다면? 퇴사하거나 부서 이동한 사용자의 계정을 제거하지 못하고 방치된다면? 

 

늘 염두해둬야 합니다. 해킹사고의 대부분의 원인은 사람의 실수라는 것을 그리고 이러한 형태의 사고를 방지하기 위해서 SSO 연동이 필요합니다. 

 

정리하자면 

 

1. 공용계정 사용을 피하기 위해

2 사용자들에게 복수의 계정 관리에 대한 부담을 줄이기 위해

3. 사용자의 다수의 계정이 동일한 패스워드 패턴 사용을 방지하기 위해

4. 계정 관리(입사,퇴사,부서이동으로 인한 계정 정보 관리)를 손쉽게 하기 위해

 

SAML 2.0 연동을 위해서는 이 기능을 제공해 줄 소스가 있어야 합니다. 오픈소스로는 keycloak이나 여러 상용 솔루션들이 존재합니다. 이번에는 상용솔루션을 통해 Jenkins SAML 2.0 연동에 대해 소개하고자 합니다.

 

(UI 가 차이날 뿐 모든 형태의 SAML 2.0 SSO는 같은 구조입니다)

 

 

SAML 2.0 IDP 역할을 해주는 솔루션과 연동해 AD 계정으로 젠킨스에 로그인이 가능하게 됩니다. 연동 방식은 IDP와 SP 간 상호 XML 메타데이터를 주고받아 신뢰관계를 형성해주는 작업만 해주면 됩니다. 

 

일반적인 젠킨스 로그인 화면입니다. SAML 2.0 연동 후에는 Login with IDP 라는 옵션이 추가되게 됩니다.

 

그러면 Login with IDP 를 눌러보겠습니다. 

 

젠킨스 로그인 화면이 아닌 IDP의 로그인 화면이 뜨게 됩니다. 이제 AD계정으로 로그인을 하겠습니다. 

 

원래 admin 이라는 초기 계정 하나뿐이었지만 admin@bizhubcen.com이라는 AD 계정을 통해 젠킨스에 로그인하게 되었습니다. 하지만 연동된 모든 AD 계정이 로그인이 가능한 것은 아닙니다. AD 또는 SAML 2.0 연동한 솔루션에서 접근 권한을 부여해야지만 실제로 로그인이 가능합니다. 

 

로그인 권한이 없는 계정으로 로그인 시 접근 거부당하게 됩니다.

 

다시 한번 정리하자면 아래와 같습니다. 

 

1. 사용자가 젠킨스에 로그인 하고자 할 때 본인의 AD 계정을 통해 젠킨스 로그인이 가능하다.

2. 권한이 없는 사용자의 경우 로그인 시 접근 거부당하게 된다.

3. 운영자는 AD 또는 연동한 IDP 에서 접근 권한을 부여/소멸할 수 있다.

 

이렇게 젠킨스등의 devops 툴과 AD와의 연동 방식에 대해 알아봤습니다. 사실 단순히 이렇게 연동하는 것은 의미가 없습니다. 로그인 한 모든 사용자가 admin 권한을 가지고 있기 때문입니다. 그래서 역할 또는 프로젝트 별로 사용자들이 적절한 권한을 가질 수 있는 정책을 적용하는 것이 SAML 2.0 연동의 목적입니다. 

 

다음 편에서는 역할별 프로젝트별로 권한을 나누어 적용하는 것에 대해 알아보겠습니다.