하드닝 가이드 - 인증 메커니즘

하드닝 가이드 - 인증 메커니즘 (Hardening Guide - Authentication Mechanisms)

쿠버네티스의 인증 옵션과 그 보안 속성에 대한 정보를 다뤄요.

적절한 인증 메커니즘을 선택하는 것은 클러스터 보안에서 매우 중요한 측면입니다. 쿠버네티스는 여러 내장 메커니즘을 제공하며, 각각 장단점이 있어요. 클러스터에 가장 적합한 인증 메커니즘을 고를 때 이를 신중하게 고려해야 합니다.

일반적으로 사용자 관리를 단순화하고 사용자가 더 이상 필요하지 않은 클러스터에 대한 접근을 유지하는 경우를 막기 위해, 가능한 한 적은 수의 인증 메커니즘을 활성화하는 것이 권장돼요.

쿠버네티스는 클러스터 안에 내장 사용자 데이터베이스가 없다는 점을 아는 것이 중요해요. 대신 구성된 인증 시스템에서 사용자 정보를 가져와서 그것을 기반으로 권한 부여 결정을 내립니다. 따라서 사용자 접근을 감사하려면 구성된 모든 인증 소스의 자격 증명을 검토해야 합니다.

여러 사용자가 쿠버네티스 API에 직접 접근하는 프로덕션 클러스터에서는 OIDC 같은 외부 인증 소스를 사용하는 것이 권장됩니다. 아래에서 설명하는 클라이언트 인증서와 서비스 계정 토큰 같은 내부 인증 메커니즘은 이 사용 사례에 적합하지 않아요.

X.509 클라이언트 인증서 인증 (X.509 client certificate authentication)

쿠버네티스는 시스템 컴포넌트에 [X.509 클라이언트 인증서] 인증을 활용합니다. 예를 들어 kubelet이 API 서버에 인증할 때 그렇죠. 이 메커니즘은 사용자 인증에도 사용할 수 있지만, 몇 가지 제한으로 인해 프로덕션 사용에는 적합하지 않을 수 있어요.

클라이언트 인증서는 개별적으로 폐기할 수 없어요. 한번 손상되면 공격자가 만료될 때까지 인증서를 사용할 수 있습니다. 이 위험을 완화하려면 클라이언트 인증서로 만든 사용자 인증 자격 증명에 짧은 수명을 구성하는 것이 권장됩니다.
인증서를 무효화해야 하면 인증 기관(certificate authority)을 다시 키잉(re-key)해야 하는데, 이는 클러스터에 가용성 위험을 초래할 수 있어요.
클러스터에 생성된 클라이언트 인증서의 영구 기록이 없어요. 따라서 추적해야 하면 발급된 모든 인증서를 기록해야 합니다.
클라이언트 인증서 인증에 사용되는 개인 키는 비밀번호로 보호할 수 없어요. 키가 담긴 파일을 읽을 수 있는 사람은 누구든 그것을 사용할 수 있습니다.
클라이언트 인증서 인증을 사용하려면 클라이언트가 개입하는 TLS 종료 지점 없이 API 서버에 직접 연결해야 하므로 네트워크 아키텍처가 복잡해질 수 있어요.
그룹 데이터는 클라이언트 인증서의 O 값에 내장되어 있어, 인증서 수명 동안 사용자의 그룹 멤버십을 변경할 수 없습니다.

정적 토큰 파일 (Static token file)

쿠버네티스는 컨트롤 플레인 노드 디스크에 있는 [정적 토큰 파일]에서 자격 증명을 로드하는 것을 허용하지만, 여러 이유로 프로덕션 서버에는 이 방식을 권장하지 않아요.

자격 증명이 컨트롤 플레인 노드 디스크에 평문으로 저장되어 보안 위험이 될 수 있어요.
어떤 자격 증명을 변경해도 적용되려면 API 서버 프로세스 재시작이 필요하며, 이는 가용성에 영향을 줄 수 있습니다.
사용자가 자격 증명을 로테이션할 수 있는 메커니즘이 없어요. 자격 증명을 로테이션하려면 클러스터 관리자가 디스크의 토큰을 수정하고 사용자에게 배포해야 합니다.
무차별 대입(brute-force) 공격을 막을 수 있는 잠금(lockout) 메커니즘이 없어요.

부트스트랩 토큰 (Bootstrap tokens)

[부트스트랩 토큰]은 노드를 클러스터에 조인하는 데 사용되며, 여러 이유로 사용자 인증에는 권장되지 않아요.

일반적인 사용에 적합하지 않은 하드코딩된 그룹 멤버십을 가지므로 인증 목적에는 부적합합니다.
부트스트랩 토큰을 수동으로 생성하면 공격자가 추측할 수 있는 약한 토큰이 생길 수 있어 보안 위험이 됩니다.
무차별 대입 공격을 막는 잠금 메커니즘이 없어 공격자가 토큰을 추측하거나 깨기 쉬워져요.

ServiceAccount 시크릿 토큰 (ServiceAccount secret tokens)

[서비스 계정 시크릿]은 클러스터 안에서 실행되는 워크로드가 API 서버에 인증할 수 있게 하는 옵션으로 사용할 수 있어요. Kubernetes < 1.23에서는 이것이 기본 옵션이었지만, TokenRequest API 토큰으로 대체되고 있습니다. 이 시크릿을 사용자 인증에 사용할 수는 있지만, 일반적으로 여러 이유로 부적합합니다.

만료를 설정할 수 없어 관련 서비스 계정이 삭제될 때까지 유효하게 남아 있어요.
인증 토큰은 정의된 네임스페이스의 시크릿을 읽을 수 있는 모든 클러스터 사용자에게 보입니다.
서비스 계정은 임의의 그룹에 추가할 수 없어, 사용되는 곳에서 RBAC 관리를 복잡하게 만듭니다.

TokenRequest API 토큰 (TokenRequest API tokens)

TokenRequest API는 API 서버나 서드파티 시스템에 대한 서비스 인증용 단기 자격 증명을 생성하는 유용한 도구예요. 그러나 폐기 방법이 없고 자격 증명을 사용자에게 안전하게 배포하는 것이 까다로울 수 있어 사용자 인증에는 일반적으로 권장되지 않아요.

TokenRequest 토큰을 서비스 인증에 사용할 때는 손상된 토큰의 영향을 줄이기 위해 짧은 수명을 구현하는 것이 권장됩니다.

OpenID Connect 토큰 인증 (OpenID Connect token authentication)

쿠버네티스는 [OpenID Connect (OIDC)]를 사용해 외부 인증 서비스를 쿠버네티스 API와 통합하는 것을 지원합니다. 쿠버네티스를 identity provider와 통합하는 데 사용할 수 있는 소프트웨어는 매우 다양해요. 그러나 쿠버네티스에서 OIDC 인증을 사용할 때는 다음 하드닝 조치를 고려하는 것이 중요합니다.

OIDC 인증을 지원하기 위해 클러스터에 설치된 소프트웨어는 높은 권한으로 실행되므로 일반 워크로드와 격리되어야 해요.
일부 쿠버네티스 관리 서비스는 사용할 수 있는 OIDC 프로바이더가 제한됩니다.
TokenRequest 토큰과 마찬가지로, OIDC 토큰도 손상된 토큰의 영향을 줄이기 위해 짧은 수명을 가져야 합니다.

Webhook 토큰 인증 (Webhook token authentication)

[Webhook 토큰 인증]은 외부 인증 프로바이더를 쿠버네티스에 통합하는 또 다른 옵션이에요. 이 메커니즘은 클러스터 안이나 외부에서 실행되는 인증 서비스를 webhook으로 인증 결정을 위해 접촉할 수 있게 해줍니다. 이 메커니즘의 적합성은 인증 서비스에 사용되는 소프트웨어에 크게 의존할 가능성이 높으며, 쿠버네티스별 고려 사항도 있다는 점에 주의하는 것이 중요해요.

Webhook 인증을 구성하려면 컨트롤 플레인 서버 파일시스템에 대한 접근이 필요합니다. 즉 프로바이더가 특별히 제공하지 않는 한 Managed Kubernetes에서는 불가능하다는 뜻이에요. 또한 이 접근을 지원하기 위해 클러스터에 설치된 소프트웨어는 높은 권한으로 실행되므로 일반 워크로드와 격리되어야 합니다.

인증 프록시 (Authenticating proxy)

외부 인증 시스템을 쿠버네티스에 통합하는 또 다른 옵션은 [인증 프록시(authenticating proxy)]를 사용하는 것입니다. 이 메커니즘에서 쿠버네티스는 프록시에서 특정 헤더 값이 설정된 요청을 받을 것으로 기대합니다. 이 헤더는 권한 부여 목적으로 할당할 사용자 이름과 그룹 멤버십을 나타내요. 이 메커니즘을 사용할 때 고려할 특정 사항이 있다는 점에 유의하세요.

첫째, 트래픽 가로채기나 스니핑 공격의 위험을 완화하기 위해 프록시와 쿠버네티스 API 서버 사이에 안전하게 구성된 TLS를 사용해야 합니다. 이는 프록시와 쿠버네티스 API 서버 사이의 통신이 안전함을 보장합니다.

둘째, 요청의 헤더를 수정할 수 있는 공격자가 쿠버네티스 리소스에 대한 무단 접근을 얻을 수 있다는 점을 인지하는 것이 중요해요. 따라서 헤더가 제대로 보호되고 변조될 수 없음을 보장해야 합니다.

하드닝 가이드 - 인증 메커니즘