클라우드와 쿠버네티스, 왜 ABAC보다 RBAC을 사랑할까? 💖

https://www.authx.com/blog/rbac-vs-abac/

 

안녕하세요! 👋 클라우드와 쿠버네티스의 세계를 탐험하는 여러분을 위해 오늘은 조금 딱딱할 수 있는 '권한 관리'에 대해 이야기해보려고 합니다. 그중에서도 왜 수많은 전문가들이 속성 기반 접근 제어(ABAC)보다 역할 기반 접근 제어(RBAC)를 선호하는지, 그 이유를 쉽고 재미있게 파헤쳐 보겠습니다! 🚀

🤔 ABAC vs RBAC, 뭐가 다른데?

먼저 두 가지 권한 관리 모델의 기본 개념부터 확실히 알아볼까요?

속성 기반 접근 제어 (ABAC - Attribute-Based Access Control)

ABAC는 말 그대로 '속성'에 기반하여 접근 권한을 부여하는 방식입니다. 여기서 속성이란 굉장히 다양할 수 있어요.

• 사용자의 속성: 직책, 부서, 소속 국가 등
• 리소스의 속성: 데이터의 민감도, 파일 종류, 프로젝트 태그 등
• 환경적 속성: 접속 시간, 접속 위치(IP 주소), 사용 기기 등

예를 들어, "오전 9시부터 오후 6시 사이에, 한국 IP로 접속한 '개발팀' 소속의 '시니어 개발자'만 '프로덕션 데이터베이스'에 접근할 수 있다"와 같이 매우 세분화되고 동적인 정책을 만들 수 있다는 장점이 있습니다. 정말 똑똑하죠? 🧠

하지만 이 유연함은 곧 복잡함으로 이어집니다. 모든 속성을 정의하고, 수많은 정책들을 일관성 있게 관리하는 것은 여간 어려운 일이 아닙니다. 자칫 잘못하면 정책 충돌이 일어나거나, 성능에 부하를 줄 수도 있죠. 😫

역할 기반 접근 제어 (RBAC - Role-Based Access Control)

RBAC는 '역할(Role)'을 기반으로 권한을 관리하는, 우리에게 좀 더 친숙한 방식입니다.

1. 역할(Role) 생성: 먼저 '관리자', '개발자', '뷰어'와 같은 역할을 만듭니다.
2. 권한(Permission) 부여: 각 역할에 필요한 권한(예: 읽기, 쓰기, 삭제)을 부여합니다.
3. 사용자에게 역할 할당: 사용자에게 미리 정의된 역할을 할당합니다.

예를 들어, '개발자'라는 역할에는 '개발 서버의 Pod 로그 조회'와 '테스트 네임스페이스에 리소스 생성' 권한을 부여하고, 새로운 개발자가 입사하면 그에게 '개발자' 역할을 주기만 하면 되는 거죠. 참 간단하죠? 😄

🏆 클라우드와 쿠버네티스가 RBAC를 선택한 이유

그렇다면 왜 복잡하고 거대한 클라우드와 쿠버네티스 환경에서는 유연한 ABAC보다 비교적 단순한 RBAC를 주로 사용할까요? 여기에는 몇 가지 중요한 이유가 있습니다.

1. 관리의 용이성: "단순함이 최고야!" 👍

클라우드와 쿠버네티스 클러스터는 수많은 사용자와 서비스, 그리고 셀 수 없이 많은 리소스들로 구성됩니다. 이런 환경에서 ABAC를 사용해 개별 속성 기반으로 권한을 관리하려고 한다면, 정책의 수는 기하급수적으로 늘어날 것입니다. "A팀의 신입사원은 B 프로젝트의 테스트 DB에만 접근 가능", "C팀의 경력직은 D, E 프로젝트의 운영 서버 로그 조회 가능"... 상상만 해도 머리가 아찔하네요. 🤯

반면 RBAC는 '개발자', '운영자', '데이터 분석가'와 같은 몇 가지 표준화된 역할만 잘 정의해두면 새로운 사용자가 추가되거나 조직이 변경될 때 역할을 부여하거나 회수하는 것만으로 간단하게 권한 관리를 끝낼 수 있습니다. 이는 관리 비용을 획기적으로 줄여주고, 실수를 방지하는 데 큰 도움이 됩니다.

2. 예측 가능성과 일관성: "누가 뭘 할 수 있는지 한눈에!" 🧐

RBAC는 어떤 사용자가 어떤 역할을 가지고 있는지 명확하게 보여줍니다. '뷰어' 역할을 가진 사용자는 절대로 리소스를 수정하거나 삭제할 수 없다는 것이 명백하죠. 이처럼 역할 기반의 권한 체계는 시스템의 상태를 예측하기 쉽고, 보안 감사를 진행할 때도 매우 용이합니다.

ABAC의 경우, 다양한 속성들의 조합으로 권한이 결정되기 때문에 특정 사용자가 특정 리소스에 접근할 수 있는지 없는지를 직관적으로 파악하기 어렵습니다. 이는 보안 취약점으로 이어질 수 있는 '의도치 않은 권한 부여'의 위험을 높입니다.

3. 성능과 확장성: "빠르고 가볍게!" ⚡️

쿠버네티스의 API 서버는 모든 요청에 대해 권한 검사를 수행해야 합니다. ABAC는 매 요청마다 사용자, 리소스, 환경의 다양한 속성을 평가해야 하므로 복잡한 정책일수록 응답 시간이 길어지고 시스템에 부하를 줄 수 있습니다.

반면 RBAC는 사용자와 역할, 역할과 권한의 관계가 미리 정의되어 있어 훨씬 빠르고 효율적으로 권한 검사를 수행할 수 있습니다. 수천, 수만 개의 컨테이너가 동작하는 대규모 클러스터 환경에서는 이러한 성능 차이가 더욱 중요해집니다.

4. 쿠버네티스와의 찰떡궁합: "우린 원래 한 팀!" 🤝

쿠버네티스는 처음부터 RBAC를 핵심적인 보안 기능으로 채택하고, 기본으로 활성화해두었습니다. Role, ClusterRole, RoleBinding, ClusterRoleBinding과 같은 명확한 API 객체를 통해 사용자는 YAML 파일로 선언적으로 권한을 관리할 수 있습니다. 이는 쿠버네티스가 추구하는 '선언적 인프라(Declarative Infrastructure)' 철학과도 완벽하게 부합합니다.

✨ 하이브리드 접근: RBAC를 기본으로, ABAC를 양념으로!

물론 ABAC의 세밀한 제어 능력이 필요한 순간도 있습니다. 그래서 최근 클라우드 환경(AWS, GCP, Azure 등)에서는 RBAC를 기본 뼈대로 사용하면서, 특정 조건(예: 특정 태그가 달린 리소스에만 접근 허용, MFA 인증을 한 경우에만 민감한 작업 허용 등)을 추가할 수 있는 ABAC의 기능을 일부 도입하는 '하이브리드' 모델을 제공하고 있습니다.

즉, 'RBAC로 큰 틀에서의 접근 제어'를 하고, 'ABAC적인 요소를 활용해 예외적이거나 민감한 상황에 대한 세부 제어'를 추가하는 방식이 가장 이상적인 해결책으로 자리 잡고 있습니다.

맺음말

클라우드와 쿠버네티스에서 권한 관리는 시스템의 안정성과 보안을 위한 핵심 요소입니다. ABAC의 강력한 유연성도 매력적이지만, 대규모의 복잡한 환경에서는 관리의 용이성, 예측 가능성, 그리고 성능이라는 현실적인 가치를 제공하는 RBAC가 더 현명한 선택이 되는 경우가 많습니다.

오늘 이야기가 여러분의 클라우드 네이티브 여정에 작은 도움이 되었기를 바랍니다! 😊