🔐 쿠버네티스, 아무나 들어올 수 없다! - 인증과 인가 파헤치기

안녕하세요! 쿠버네티스(Kubernetes)의 세계를 항해하는 여러분을 위한 등대가 되어드릴게요. 🧭 오늘은 복잡해 보이지만 아주 중요한 쿠버네티스의 인증(Authentication)과 인가(Authorization) 체계에 대해 쉽고 상세하게 알아보려고 합니다.

쿠버네티스 클러스터는 수많은 컨테이너와 중요한 애플리케이션들이 모여있는 소중한 공간이죠. 이곳에 아무나 들어와서 마음대로 조작하게 둘 순 없겠죠? 그래서 쿠버네티스는 엄격한 출입 통제 시스템을 갖추고 있답니다.

이 시스템은 크게 두 단계로 나뉩니다.

1. 인증 (Authentication) 👤: "당신은 누구신가요?" 신원을 확인하는 단계입니다.
2. 인가 (Authorization) 🔑: "당신이 이 작업을 할 권한이 있나요?" 신원이 확인된 사용자가 특정 행동을 할 수 있는지 허가하는 단계입니다.

오늘 포스팅에서는 두 번째 단계인 인가(Authorization), 즉 "무엇을 할 수 있는가?"에 대한 다양한 방법들을 집중적으로 살펴보겠습니다!

 

 

---

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

"당신은 '개발자' 역할이니, '개발 서버'에만 들어갈 수 있습니다."

가장 널리 사용되고 쿠버네티스가 공식적으로 추천하는 방식입니다. 조직 내에서 개인에게 역할을 부여하고, 그 역할에 따라 할 수 있는 일(권한)을 미리 정해두는 방식이죠.

🏢 회사에 비유해 볼까요?

• 사용자(User): 회사 직원 🧑‍💼
• 역할(Role): '인사팀', '개발팀', '디자인팀' 같은 직무 🏷️
• 권한(Permission): '인사팀'은 직원 정보 열람 가능, '개발팀'은 개발 서버 접근 가능 🔑
• 리소스(Resource): 직원 정보 파일, 개발 서버 💻

이처럼 RBAC는 사용자에게 직접 권한을 하나하나 주는 게 아니라, '역할(Role)'이라는 중간 단계를 두어 권한을 묶어서 관리합니다. 덕분에 권한 관리가 훨씬 수월하고 직관적이죠. 예를 들어 새로운 개발자가 입사하면, 그에게 '개발팀' 역할을 부여하기만 하면 필요한 모든 권한이 한 번에 주어집니다.

RBAC는 쿠버네티스에서 Role, ClusterRole, RoleBinding, ClusterRoleBinding이라는 객체들을 통해 구현됩니다.

---

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

"당신은 '한국'에서 접속했고, '관리자' 그룹에 속해 있으며, 시간은 '업무 시간'이니, '모든 서버'에 접근할 수 있습니다."

ABAC는 RBAC보다 한 단계 더 나아가, 다양한 속성(Attribute)들을 조합해서 만든 정책(Policy)에 따라 접근을 허용하는 매우 유연하고 강력한 방식입니다.

여기서 말하는 속성은 정말 다양할 수 있어요.

• 사용자 속성: 사용자의 이름, 역할, 소속 그룹, 보안 등급 등
• 리소스 속성: 파일의 종류, 민감도, 소유자 등
• 환경 속성: 접속 시간, 접속 위치(IP 주소), 사용 기기 등

🎬 영화관에 비유해 볼까요? '19세 이상 관람가' 영화를 보려면, [나이: 19세 이상] 이라는 사용자 속성과 [영화 등급: 19세] 라는 리소스 속성이 모두 충족되어야만 입장이 가능한 것과 같아요.

ABAC는 이처럼 여러 조건을 동적으로 조합할 수 있어서 매우 세밀한 제어가 가능하지만, 정책을 만들고 관리하기가 RBAC에 비해 복잡하다는 단점이 있습니다.

---

🤖 Node Authorization: 노드 인가

"1번 노드야, 너는 너에게 할당된 파드(Pod) 정보만 가져갈 수 있어. 다른 노드 정보는 안돼!"

이름에서 알 수 있듯이, 노드(Node)에 특화된 인가 모드입니다. 정확히는 각 노드에서 실행되는 에이전트인 kubelet이 API 서버에 보내는 요청을 허가하는 특별한 목적의 기능이죠.

클러스터의 각 노드에서 일하는 일꾼 kubelet은 자신의 노드에 어떤 파드를 띄워야 하는지, 필요한 설정값(Secret, ConfigMap)은 무엇인지 등을 알기 위해 중앙 관리소인 API 서버와 계속 통신해야 합니다. 📞

이때 Node Authorization은 kubelet이 자신과 관련된 리소스에만 접근하도록 권한을 엄격하게 제한하는 역할을 합니다. 만약 A 노드의 kubelet이 전혀 상관없는 B 노드의 정보를 빼내려고 시도하면, Node Authorization이 "접근 불가! 🛡️"라며 요청을 차단해 버리죠. 이는 클러스터의 보안을 한층 더 강화해 주는 중요한 기능입니다.

---

Webhook Mode: 웹훅 모드

"이 사용자가 이 작업을 할 수 있는지 잘 모르겠네... 저기 외부 전문가에게 한번 물어보고 올게!"

쿠버네티스의 인가 결정을 내부에서 처리하지 않고, 외부의 다른 시스템에게 물어보는(위임하는) 방식입니다.

'Webhook'은 특정 이벤트가 발생했을 때 지정된 URL로 HTTP 요청을 보내는 것을 의미해요. 인가 과정에서는 다음과 같이 동작합니다.

1. 사용자가 API 서버에 특정 작업을 요청합니다. 🙋
2. 쿠버네티스 API 서버는 Webhook 모드로 설정된 외부 서비스 URL로 "이 사용자가 이 작업을 하려는데, 허가해도 될까요?" 라는 질문을 담아 HTTP 요청을 보냅니다. ➡️ 外部 서비스
3. 요청을 받은 외부 서비스는 자체적인 로직(예: 회사 내부 인증 시스템과 연동)에 따라 권한을 확인하고, "네, 괜찮아요(allow)" 또는 "아니요, 안돼요(deny)" 라고 응답합니다. ✅ / ❌
4. API 서버는 외부 서비스의 응답을 받고 최종적으로 사용자의 요청을 처리하거나 거부합니다.

이 방식은 이미 회사에 구축된 복잡한 인증/인가 시스템이 있거나, 쿠버네티스의 기본 인가 모델만으로는 구현하기 어려운 특별한 규칙을 적용하고 싶을 때 매우 유용하게 사용할 수 있습니다.

---

✨ 마무리하며

오늘은 쿠버네티스 클러스터를 안전하게 지키는 문지기, 인가(Authorization)의 다양한 방법들에 대해 알아보았습니다.

• RBAC: 역할 기반으로 가장 표준적이고 관리하기 쉬운 방법
• ABAC: 여러 속성을 조합해 세밀하고 동적인 제어가 가능한 방법
• Node Authorization: Kubelet의 권한을 제한해 노드 보안을 강화하는 방법
• Webhook Mode: 외부 시스템에 인가 결정을 위임하는 유연한 방법

어떤 방식을 선택할지는 여러분의 환경과 보안 요구사항에 따라 달라집니다. 하지만 대부분의 경우, RBAC로 시작하여 필요에 따라 다른 방식을 조합하는 것이 가장 좋은 출발점이 될 거예요.

여러분의 쿠버네티스 클러스터를 더욱 안전하고 견고하게 만드시길 바랍니다! 💪

 

태그: 쿠버네티스, Kubernetes, 인증, 인가, 보안, RBAC, ABAC, NodeAuthorization, Webhook, K8s, DevOps