🔐 쿠버네티스 문을 여는 열쇠들! - 다양한 인증(Authentication) 방법 총정리

안녕하세요! 지난번 포스팅에서 쿠버네티스의 '인가(Authorization)' 방식들을 살펴보며 클러스터 보안의 중요성을 강조했었죠. 오늘은 그 첫 단계인 '인증(Authentication)'에 대해 깊이 파고들어 볼 시간입니다! 🔑

 

"당신은 누구인가요?" 🤔 쿠버네티스 API 서버는 클러스터에 접근하려는 모든 사용자와 프로세스에게 이 질문을 던집니다. 그리고 그 질문에 대한 답변, 즉 신원을 증명하는 다양한 '열쇠'들이 존재하죠.

 

지금부터 쿠버네티스 클러스터의 문을 여는 다채로운 인증 방법들을 함께 알아보겠습니다! 🚀

 

---

📜 1. X.509 클라이언트 인증서 (X.509 Client Certs)

"나는 내가 발급받은 신분증이 있으니 믿어줘!"

가장 흔하고 강력한 인증 방식 중 하나입니다. 여러분의 주민등록증이나 운전면허증처럼, 고유한 디지털 신분증을 통해 신원을 증명하는 방식이죠.

쿠버네티스 클러스터는 자체적으로 인증 기관(Certificate Authority, CA)을 가지고 있어요. 이 CA가 사용자의 요청에 따라 X.509 형식의 클라이언트 인증서를 발급해 줍니다. 이 인증서에는 사용자의 정보(예: ID, 그룹)가 포함되어 있죠.

클라이언트(사용자 또는 kubectl 같은 도구)가 API 서버에 요청을 보낼 때, 이 발급받은 클라이언트 인증서를 함께 제시합니다. API 서버는 자신의 CA로 이 인증서가 유효한지, 누가 발급했는지 등을 확인하여 신원을 인증하죠. ✅

장점:

• 매우 강력한 보안 💪
• 자동화된 시스템에서 사용하기 용이 ⚙️
• 한번 설정해두면 편리하게 사용 가능

단점:

• 인증서 발급 및 관리가 다소 복잡할 수 있음 📝
• 인증서 유효 기간 만료 시 갱신 필요 ⏳

대부분의 쿠버네티스 클러스터는 기본적으로 이 방식을 사용하며, kubeconfig 파일에 이 인증서 정보가 담겨있어 kubectl이 API 서버와 통신할 때 활용됩니다.

---

📄 2. 정적 토큰 파일 (Static Token File)

"여기 파일에 적힌 비밀번호를 보여줄게!"

이름 그대로, 미리 정의된 사용자 이름과 토큰(비밀번호 같은 문자열)이 담긴 파일을 사용하여 인증하는 방식입니다.

클러스터를 시작할 때, API 서버에 --token-auth-file 옵션을 통해 특정 파일의 경로를 알려줍니다. 이 파일 안에는 각 사용자(또는 서비스)의 ID, UID, 그룹, 그리고 토큰이 한 줄씩 기록되어 있어요.

<token>,<user-name>,<user-id>,<group1>,<group2>...

사용자가 API 서버에 요청을 보낼 때, HTTP 헤더에 Authorization: Bearer <token> 형식으로 토큰을 포함시켜 보냅니다. API 서버는 전달받은 토큰이 정적 토큰 파일에 있는 토큰과 일치하는지 확인하여 인증을 수행합니다. 👍

장점:

• 설정이 간단하고 구현하기 쉬움 👶
• 작은 규모의 클러스터나 테스트 환경에 적합

단점:

• 보안에 취약할 수 있음 (토큰이 파일에 평문으로 저장될 위험) ⚠️
• 토큰을 변경하거나 관리하기 어려움 😵‍💫
• 대규모 환경에서는 비효율적

💡 참고: 요즘에는 잘 사용되지 않는 레거시(legacy) 방식으로 간주됩니다.

---

📨 3. 요청에 Bearer 토큰 포함 (Putting a Bearer Token in a Request)

"내가 이 토큰을 가지고 있으니, 나를 '소유자'로 인정해줘!"

이것은 특정 인증 방식이라기보다는 토큰을 API 서버에 전달하는 일반적인 방법입니다. 'Bearer'라는 단어는 "이 토큰을 소유한 사람이 바로 그 사용자임을 증명한다"는 의미를 내포하고 있어요. 🤝

앞서 설명한 '정적 토큰 파일'이나 뒤에서 설명할 '부트스트랩 토큰', '서비스 어카운트 토큰', 'OpenID Connect 토큰', 'Webhook 토큰' 등 다양한 종류의 토큰들이 바로 이 'Bearer 토큰' 형태로 HTTP 요청 헤더에 담겨 전달됩니다.

요청 예시:

GET /api/v1/pods
Authorization: Bearer <여기_에_인증_토큰_입력>

API 서버는 이 Authorization 헤더에서 토큰을 추출하여, 설정된 여러 인증 모듈(정적 토큰 파일, OIDC 등) 중 하나를 통해 토큰의 유효성을 검증하게 됩니다.

---

🚀 4. 부트스트랩 토큰 (Bootstrap Tokens)

"새로 클러스터에 합류할 노드야, 이 일회용 비밀번호로 일단 들어와서 기본적인 설정은 해!"

쿠버네티스 클러스터를 처음 구축하거나 새로운 노드를 클러스터에 합류시킬 때 임시적으로 사용되는 토큰입니다. 🏗️

새로운 노드(kubelet)가 클러스터에 가입하려면 API 서버와 통신해야 하는데, 이때 Node Authorization과 같은 인가 방식이 적용되기 전까지는 인증할 방법이 필요하죠. 부트스트랩 토큰은 바로 이 초기 설정(bootstrap) 단계에서 kubelet이 API 서버에 자신의 신원을 임시로 증명하고, 필요한 인증서(X.509)를 발급받을 수 있도록 도와줍니다.

특징:

• 짧은 유효 기간 ⏰ (보통 24시간)
• 일회성 또는 제한적인 용도로 사용
• kubeadm 같은 클러스터 구축 도구에서 주로 활용

클러스터에 노드가 성공적으로 합류하고 나면, 부트스트랩 토큰은 더 이상 사용되지 않거나 만료됩니다. 보안을 위해 최소한의 권한만 부여하며, 주로 kube-system 네임스페이스에 Secret 형태로 저장됩니다.

---

🤖 5. 서비스 어카운트 토큰 (Service Account Tokens)

"나는 '데이터베이스 연결' 서비스야. 이 토큰으로 데이터베이스에 접근할 수 있게 해줘!"

이름에서 알 수 있듯이, 사람이 아닌 '서비스'나 '파드(Pod)'가 API 서버와 통신할 때 사용되는 인증 토큰입니다. ⚙️

쿠버네티스 클러스터 내에서 실행되는 애플리케이션(파드)이 클러스터 API에 접근하여 정보를 조회하거나 리소스를 생성, 수정, 삭제해야 할 때가 많습니다. 예를 들어, 모니터링 파드가 클러스터의 상태를 확인하거나, 배포 자동화 파드가 새로운 서비스를 배포하는 경우 등이요.

이때 각 파드는 기본적으로 특정 서비스 어카운트(Service Account)와 연결됩니다. 그리고 이 서비스 어카운트에는 해당 파드가 API 서버에 인증할 수 있는 서비스 어카운트 토큰이 자동으로 생성되어 파드 내부에 시크릿(Secret) 형태로 마운트됩니다.

파드 내의 애플리케이션은 이 토큰을 사용하여 API 서버에 요청을 보낼 수 있게 됩니다.

장점:

• 클러스터 내부 워크로드(파드)의 안전한 API 접근 가능 👍
• RBAC와 연동하여 세밀한 권한 제어 가능 (서비스 어카운트에 RoleBinding 적용)
• 토큰 관리가 쿠버네티스 내부에서 이루어져 편리

---

🌐 6. OpenID Connect 토큰 (OpenID Connect Tokens)

"나, 구글/Azure/Salesforce에서 인증받은 사용자야! 믿어도 돼!"

요즘 웹 서비스에서 많이 사용되는 외부 아이덴티티 제공자(Identity Provider, IdP)를 통해 사용자를 인증하는 방식입니다. 🆔

여러분은 이미 매일 같이 이 방식을 사용하고 있을지도 모릅니다. 예를 들어, 어떤 웹사이트에 가입할 때 "구글 계정으로 로그인", "네이버 계정으로 로그인" 같은 버튼을 눌러본 적이 있을 거예요. OpenID Connect(OIDC)는 바로 이러한 방식의 표준 프로토콜입니다.

쿠버네티스 API 서버는 Azure Active Directory, Google, Salesforce와 같은 외부 OIDC 제공자와 연동하여 사용자 인증을 수행할 수 있습니다.

작동 방식:

1. 사용자가 kubectl 등으로 쿠버네티스 API에 접근을 시도합니다.
2. API 서버는 OIDC IdP로 사용자를 리다이렉트하여 로그인하도록 합니다.
3. 사용자는 IdP에서 로그인 과정을 거칩니다.
4. IdP는 로그인 성공 시 사용자에게 ID 토큰(JWT)을 발급하고 쿠버네티스 API 서버로 다시 리다이렉트합니다.
5. API 서버는 이 ID 토큰을 받아서 검증하고, 토큰 내의 정보(사용자 ID, 그룹 등)를 추출하여 인증을 완료합니다. ✅

장점:

• 기존에 사용하던 중앙 집중식 IdP(회사 SSO 시스템 등)와 연동하여 편리하게 인증 가능 💼
• 사용자 계정 관리를 한 곳에서 할 수 있어 효율적
• 보안성 높음 (토큰 유효성 검증 및 만료 처리)

---

🪝 7. Webhook 토큰 (Webhook Token)

"이 토큰이 유효한지 외부 시스템에 물어보고 올게!"

이 방식은 토큰의 유효성을 쿠버네티스 API 서버 자체에서 판단하지 않고, 외부의 Webhook 서비스에게 판단을 위임하는 방식입니다. 📞

API 서버는 특정 토큰이 포함된 요청을 받으면, 미리 설정된 외부 Webhook 인증 서비스의 URL로 해당 토큰을 포함한 요청을 보냅니다. 외부 서비스는 자체적인 로직과 백엔드 시스템(예: LDAP, 사내 인증 DB)을 통해 이 토큰이 유효한지 검증한 후, 인증 결과를 API 서버에 다시 알려줍니다.

장점:

• 쿠버네티스가 지원하지 않는 복잡하거나 커스텀된 인증 로직을 적용 가능 🧩
• 기존의 복잡한 인증 인프라를 그대로 활용할 수 있음
• 유연성이 매우 높음

단점:

• 외부 Webhook 서비스의 구현 및 관리가 필요 🛠️
• 네트워크 지연이나 외부 서비스의 장애가 발생할 경우 인증에 영향을 줄 수 있음

---

✨ 마무리하며

오늘은 쿠버네티스 클러스터로 들어오는 다양한 '인증(Authentication)' 방법들을 알아보았습니다.

• X.509 클라이언트 인증서: 강력한 디지털 신분증 방식
• 정적 토큰 파일: 간단하지만 보안에 취약한 레거시 방식
• Bearer 토큰: 토큰을 전달하는 일반적인 형식
• 부트스트랩 토큰: 클러스터 초기 구성 시 임시적으로 사용
• 서비스 어카운트 토큰: 파드(애플리케이션)가 API 서버와 통신할 때 사용
• OpenID Connect 토큰: 외부 IdP를 통한 중앙 집중식 인증
• Webhook 토큰: 외부 서비스에 인증 결정을 위임하는 유연한 방식

이처럼 쿠버네티스는 다양한 인증 메커니즘을 제공하여, 여러분의 클러스터 환경과 보안 요구사항에 맞춰 최적의 방법을 선택할 수 있도록 돕습니다. 어떤 방식을 선택하든, 가장 중요한 것은 '최소 권한의 원칙'을 지키고, 사용하지 않는 토큰은 반드시 폐기하는 것임을 잊지 마세요! 🔒

다음 포스팅에서는 이 인증된 사용자가 '무엇을 할 수 있는지'를 결정하는 '인가(Authorization)'에 대해 더 자세히 다루어 보겠습니다. 😉

 

태그: 쿠버네티스, Kubernetes, 인증, Authentication, 보안, X509, 토큰, BearerToken, BootstrapToken, ServiceAccount, OpenIDConnect, OIDC, Webhook, K8s, DevOps