안녕하세요! 오늘은 쿠버네티스(Kubernetes) 환경에서 어떻게 사용자를 안전하고 효율적으로 관리할 수 있는지, 그 핵심 열쇠인 OIDC(OpenID Connect)와 Keycloak을 활용한 인증 흐름을 상세하게 파헤쳐 보겠습니다.
이 다이어그램은 사용자가 kubectl 명령어를 사용하기 위해 Keycloak이라는 IdP(Identity Provider)를 통해 인증하고, 쿠버네티스 API 서버가 이를 검증하여 권한을 부여하는 전체 과정을 보여줍니다. 복잡해 보이지만, 한 단계씩 따라가다 보면 생각보다 간단하답니다! 😉

자, 그럼 시작해볼까요?
전체 그림 살펴보기 🧐
이 그림에는 네 가지 주요 구성 요소가 등장합니다.
- 🧑💻 사용자 (User): kubectl 명령어를 실행하여 쿠버네티스 클러스터와 상호작용하려는 개발자 또는 운영자입니다.
- 🔑 Keycloak: 중앙에서 사용자 계정을 관리하고 인증을 처리하는 IdP(Identity Provider) 입니다. OIDC 프로토콜을 지원하여 안전한 토큰을 발급해 줍니다.
- ⚙️ Kubectl CLI: 사용자가 쿠버네티스와 소통하기 위해 사용하는 커맨드 라인 인터페이스(Command Line Interface) 도구입니다.
- 🤖 Kubernetes API Server: 쿠버네티스 클러스터의 모든 요청을 처리하는 두뇌와 같은 역할을 합니다. 사용자가 정말로 이 작업을 수행할 권한이 있는지 확인하는 문지기이기도 하죠.
이제 이 구성 요소들이 어떻게 상호작용하는지 1번부터 9번까지의 흐름을 따라가 보겠습니다.
1️⃣ 단계: IdP에 로그인하기 (Log in to IdP)
사용자 ➡️ Keycloak
모든 것은 사용자가 인증을 받는 것에서 시작됩니다. 쿠버네티스에 직접 아이디와 비밀번호를 입력하는 것이 아니라, 중앙 인증 서버인 Keycloak에 먼저 로그인을 시도합니다. 웹 브라우저를 통해 Keycloak 로그인 페이지가 열리고, 사용자는 자신의 아이디와 비밀번호(또는 MFA, 소셜 로그인 등 설정된 방식)를 입력하여 본인임을 증명합니다.
2️⃣ 단계: 토큰 발급받기 (Provide tokens)
Keycloak ➡️ 사용자
사용자의 정보가 올바르다면, Keycloak은 성공적으로 인증되었다는 의미로 세 가지 종류의 토큰을 발급하여 사용자에게 전달합니다.
- ID Token (id_token): 사용자의 신원 정보(이름, 이메일, 소속 그룹 등)가 담겨있는 JWT(JSON Web Token)입니다. 쿠버네티스 인증에서는 바로 이 ID 토큰이 핵심적인 역할을 합니다.
- Access Token (access_token): 특정 API(이 경우 Keycloak 자체의 API 등)에 접근할 권한이 부여되었음을 나타내는 토큰입니다.
- Refresh Token (refresh_token): ID 토큰과 Access 토큰은 수명이 짧습니다. 이 토큰들이 만료되었을 때, 사용자가 다시 로그인할 필요 없이 새로운 토큰을 발급받기 위해 사용되는 특별한 토큰입니다.
3️⃣ 단계: kubectl 명령어 실행하기
사용자 ➡️ Kubectl
이제 사용자는 쿠버네티스와 대화할 준비가 되었습니다. Keycloak으로부터 받은 ID 토큰을 사용하여 kubectl 명령어를 실행합니다. 방법은 두 가지입니다.
- --token 플래그 사용: kubectl get pods --token=<ID_TOKEN_값> 처럼 매번 명령어에 토큰을 직접 붙여서 보내는 방식입니다. 임시로 사용할 때는 편리하지만, 매번 입력해야 해서 번거롭습니다.
- kubeconfig 파일에 추가: ~/.kube/config 파일에 사용자 정보와 함께 발급받은 토큰들을 설정해두는 방식입니다. 이렇게 하면 한 번 설정으로 토큰이 만료되기 전까지는 평소처럼 kubectl get pods와 같이 간단하게 명령어를 사용할 수 있습니다. 일반적으로 이 방법을 더 많이 사용합니다.
4️⃣ 단계: API 서버에 요청 전달 (Authorization: Bearer...)
Kubectl ➡️ Kubernetes API Server
kubectl은 사용자의 명령과 ID 토큰을 가지고 쿠버네티스 API 서버에 HTTPS 요청을 보냅니다. 이때 ID 토큰은 HTTP Authorization 헤더에 Bearer라는 접두사와 함께 담겨 전달됩니다. "이 토큰을 가진 사람이니, 이 사람의 요청을 처리해줘!"라는 의미죠.
🚨 쿠버네티스 API 서버의 시간: 인증과 인가 (5~7단계)
이제 공은 쿠버네티스 API 서버로 넘어왔습니다. API 서버는 요청을 받자마자 바로 처리하는 것이 아니라, 다음의 깐깐한 검증 절차를 거칩니다.
5️⃣ 단계: JWT 서명 검증 (Is JWT signature valid?)
가장 먼저, 이 토큰이 정말로 우리가 신뢰하는 Keycloak이 발급한 것이 맞는지, 그리고 중간에 누가 위변조하지는 않았는지 확인합니다. API 서버는 미리 설정된 Keycloak의 공개키(Public Key)를 사용하여 ID 토큰의 서명을 검증합니다. 만약 서명이 유효하지 않다면, 해당 요청은 즉시 거부됩니다. 🛡️
6️⃣ 단계: JWT 만료 시간 확인 (Has the JWT expired?)
서명이 유효하더라도 토큰이 영원히 사용될 수는 없습니다. 토큰 안에는 exp (Expiration Time)라는 만료 시간이 기록되어 있습니다. API 서버는 현재 시간이 이 exp 시간을 지났는지 확인합니다. 만약 토큰이 만료되었다면, 이 또한 거부됩니다. ⏳
7️⃣ 단계: 사용자 인가 (User authorized?)
자, 이제 API 서버는 이 요청을 보낸 사용자가 '누구' 인지 확실히 알게 되었습니다 (➡️ 인증, Authentication).
하지만 그 사용자가 '이 작업을 수행할 권한' 이 있는지는 별개의 문제입니다 (➡️ 인가, Authorization). API 서버는 ID 토큰 안에 들어있는 사용자 정보(예: username, groups 클레임)를 추출합니다. 그리고 이 정보를 바탕으로 쿠버네티스의 RBAC(Role-Based Access Control) 정책, 즉 Role, ClusterRole, RoleBinding, ClusterRoleBinding을 확인하여 해당 사용자가 get pods와 같은 요청된 작업을 수행할 권한이 있는지 검사합니다.
만약 권한이 없다면, "Error from server (Forbidden): ..." 과 같은 익숙한 에러 메시지를 반환하며 요청을 거부합니다. 🚫
8️⃣ 단계: 작업 수행 및 결과 반환
Kubernetes API Server ➡️ Kubectl
위의 5, 6, 7 단계의 모든 검증을 무사히 통과했다면, API 서버는 드디어 사용자의 요청(예: 파드 목록 조회)을 수행하고 그 결과를 kubectl에게 돌려줍니다.
9️⃣ 단계: 사용자에게 결과 표시
Kubectl ➡️ 사용자
마지막으로, kubectl은 API 서버로부터 받은 결과를 사용자의 터미널 화면에 예쁘게 출력해 줍니다. 🎉
정리하며 ✨
이처럼 Keycloak과 같은 OIDC 기반의 IdP를 사용하면 다음과 같은 큰 장점을 얻을 수 있습니다.
- 중앙 집중식 사용자 관리: 쿠버네티스 클러스터마다 사용자를 생성하고 관리할 필요 없이, Keycloak에서 모든 사용자 계정을 통합 관리할 수 있습니다.
- 강화된 보안 (SSO, MFA): Single Sign-On, 다중 요소 인증(MFA) 등 IdP가 제공하는 강력한 보안 기능을 쿠버네티스 인증에 그대로 적용할 수 있습니다.
- 표준 프로토콜 사용: OIDC는 업계 표준이므로, Keycloak뿐만 아니라 Okta, Google, Azure AD 등 다양한 IdP와 쉽게 연동할 수 있습니다.
이제 쿠버네티스에서 kubectl 명령어를 한 줄 입력했을 때, 그 뒤에서 얼마나 정교하고 안전한 인증/인가 과정이 일어나는지 이해되셨나요? 이 흐름을 이해하는 것은 안전한 쿠버네티스 클러스터를 구축하고 운영하는 데 매우 중요한 첫걸음이 될 것입니다. 👍
'클라우드 > 쿠버네티스' 카테고리의 다른 글
| 쿠버네티스 Secret, 자체 암호화만으로 충분할까? Vault를 연동하는 진짜 이유 🤫 (8) | 2025.08.30 |
|---|---|
| kubectl의 든든한 조력자, Krew를 소개합니다! 🚀 (1) | 2025.08.30 |
| 🔑 개발자라면 꼭 알아야 할 Keycloak: 통합 인증/인가의 모든 것 (2) | 2025.08.30 |
| 🐳 도커 이미지, 믿고 써도 될까? 공식 이미지와 일반 이미지의 서명 방식 파헤치기 (CA vs Notary) (1) | 2025.08.21 |
| 쿠버네티스와 도커, 컨테이너 데몬 모드(루트/비루트 권장 사항)는 왜 다를까? 🤔 (5) | 2025.08.21 |