[KCSA]Kubernetes 인증 메커니즘 하드닝 가이드

 

🔐 Kubernetes 인증 메커니즘 하드닝 가이드

→ 안전한 클러스터 운영을 위한 인증 방식 선택법!

---

🧭 인증 구성 시 기본 원칙

• 가능한 적은 수의 인증 방식만 활성화하자
  → 인증 방식이 많을수록 관리 복잡 + 보안 취약점 증가
• Kubernetes는 자체 사용자 DB를 갖고 있지 않음
  → 외부 인증 시스템을 통해 사용자 정보를 받아옴
• 여러 인증 소스를 쓰는 경우, 모든 소스에서 사용자 액세스를 감사(Audit) 해야 함

---

🌐 프로덕션에서 추천되는 방식

• 사용자들이 직접 kubectl 등으로 API에 접근하는 경우: → 외부 인증 시스템 사용 (예: OIDC) 추천
• 클러스터 내부 기능(컨트롤러, 서비스 등)에는 내장 인증도 사용 가능

---

🔒 인증 방식별 설명 및 보안 주의사항

---

1️⃣ X.509 클라이언트 인증서

• 시스템 컴포넌트(kubelet 등)에 주로 사용됨
• 생성한 인증서를 폐기할 수 없음 → 유출 시 위험
• 그룹 정보가 인증서에 하드코딩됨 → 중간에 바꾸기 어려움
• 프라이빗 키는 비밀번호 보호 안 됨
• TLS 종단이 중간에 있으면 작동 불가 → 복잡한 네트워크 환경엔 부적합

✅ 단기용 인증서로 설정하거나, 자동 만료되게 설정해야 조금 더 안전

---

2️⃣ Static Token File (정적 토큰 파일)

• 컨트롤 플레인 노드 디스크에 텍스트로 저장
• 사용자가 직접 비밀번호 변경 불가
• 변경하려면 API 서버 재시작 필요 → 운영에 리스크
• 절대 프로덕션 환경에선 사용하지 말 것!

---

3️⃣ Bootstrap Token

• 노드 조인용으로 설계됨
• 그룹이 고정돼 있고, 보안 기능 부족
• 추측 공격에 취약하고, 잠금(lockout) 기능 없음
  → 사용자 인증 용도로는 부적합

---

4️⃣ ServiceAccount Secret Token

• Kubernetes <1.23까지는 기본 인증 방식
• 수동으로 삭제 전까지 유효기간 없음
• 해당 네임스페이스의 Secret을 읽을 수 있는 사람은 이 토큰을 볼 수 있음
• RBAC 그룹 지정이 어려움

⚠️ 사용자 인증보다는 서비스 간 인증용으로 제한해서 사용해야 함

---

5️⃣ TokenRequest API Token

• 단기 사용에 적합한 토큰 발급 방식
• 주로 서비스 간 인증용
• 사용자 인증으로는 회수(revoke) 불가 + 배포 관리 어려움

✅ 짧은 만료 시간(short TTL) 설정 권장

---

6️⃣ OIDC (OpenID Connect) 토큰 인증 ✅

• 외부 인증 시스템(SSO, OAuth2 등)과 연동 가능
• 프로덕션 사용자 인증에 가장 널리 쓰임
• 단점:
  • 일부 클라우드 제공자는 특정 OIDC만 지원
  • 클러스터 내 OIDC 연동 시스템은 고권한이므로 격리 필요
  • 토큰 유출 방지를 위해 짧은 수명 설정

---

7️⃣ Webhook Token 인증

• 외부 인증 시스템과 웹훅으로 연동 가능
• 클러스터 또는 외부에서 인증 요청 처리
• 단점:
  • Webhook 설정은 API 서버 파일 시스템 접근 필요
    → 관리형 Kubernetes에서는 사용 어려울 수 있음
  • 클러스터 내 인증 Webhook은 격리된 환경에서 운영해야 함

---

8️⃣ Authenticating Proxy

• 프록시 서버가 사용자 인증을 수행한 후
  Kubernetes API에 사용자 정보를 담아 요청
• 보안 주의점:
  • 프록시 ↔️ API 서버 간 TLS 필수
  • 프록시가 설정한 헤더를 공격자가 조작할 경우 권한 탈취 가능 → 반드시 헤더 보안 유지 필요

---

✅ 요약 비교

인증 방식 사용자 인증에 적합? 장점 단점/위험

X.509 인증서	❌	간단함	폐기 어려움, 그룹 변경 불가
Static Token File	❌	빠르게 적용 가능	보안 취약, 회전 불가
Bootstrap Token	❌	노드 조인에만 적합	추측 공격 취약
ServiceAccount Token	❌	내부 워크로드 인증에 적합	유효기간 없음, 유출 위험
TokenRequest	🔸	짧은 수명, 자동화 가능	사용자 인증용으로는 어려움
OIDC	✅	외부 IDP 연동, 안전함	클러스터 내 구성 요소 격리 필요
Webhook 인증	✅	외부 인증 서비스 연동 가능	설정 복잡, 관리형 클러스터에선 어려움
Proxy 인증	✅	기존 인증 인프라 재사용	헤더 위조 공격 주의

---

🧠 마무리 조언

• 실제 사용자 인증엔 OIDC + 최소한의 인증 방식만 활성화하는 게 가장 안전
• 클러스터 내 인증 처리 구성요소는 꼭 격리해서 운영할 것
• 토큰, 인증서는 항상 짧은 수명 + 자동 회전 전략이 필요
• 인증 방식은 많을수록 복잡하고 위험하니, 정기 점검과 감사 로그 설정도 필수!