CNCF 블로그에 게시된 자료는 Kubernetes 클러스터에 대한 접근 제어를 네트워크 및 스토리지와 함께 기본 설정 목록의 일부로 다룰 것을 권장합니다. 특히 자체 호스팅 환경에서는 관리형 Kubernetes 서비스와 달리 일반적으로 즉시 사용할 수 있는 IAM 또는 SSO 통합을 제공하지 않기 때문입니다. 핵심 아이디어는 Keycloak과 같은 OIDC 호환 ID 공급자를 사용하고, 클라이언트를 공유 키를 보유한 비밀 클라이언트가 아니라 PKCE를 사용하는 공개 클라이언트로 등록하는 것입니다.
많은 로컬 클러스터에서 접근은 고정된 클라이언트 인증서 또는 한 번 발급되는 장기 수명의 토큰에 의존합니다. 직원이 퇴사하거나 역할이 변경되거나 해당 데이터를 보유한 장치를 잃은 뒤에도 이러한 데이터는 유효한 상태로 남습니다. 또한 접근 권한을 폐기하려면 인증서 파일이나 토큰의 모든 사본을 찾아야 하며, 장치와 사용자가 여러 명인 경우 이 작업이 완전히 수행되었음을 보장하기 어렵습니다. 사람 수가 늘고 권한 수준이 달라지면 파일 배포와 관리가 지속적인 운영 작업으로 변합니다.
OIDC를 사용하면 무엇이 달라지는가?
권한을 인증서 파일에 연결하는 대신 사용자의 계정과 ID 공급자 그룹의 구성원 자격에 연결합니다. 통합은 서로 연관된 세 당사자로 구성됩니다. kubectl 도구와 kubelogin 또는 kubectl oidc-login 플러그인, 사용자를 인증하고 ID 토큰을 발급하는 ID 공급자, 그리고 토큰을 검증하고 사용자 이름과 그룹을 추출한 뒤 허용되는 작업을 Kubernetes RBAC가 결정하도록 하는 kube-apiserver입니다.
kubectl은 로그인 절차를 시작하기 위해 먼저 API 서버에 연결하지 않습니다. exec-credential 플러그인이 ID 공급자의 브라우저를 통한 로그인을 시작한 다음 ID 토큰을 kubectl에 반환하고, kubectl은 이를 베어러 토큰 자격 증명으로 전송합니다. API 서버는 ID 공급자의 공개 서명 키를 사용해 토큰을 검증합니다. 자료에 따르면 서버는 필요할 때 해당 키를 가져오는 경우를 제외하면 ID 공급자와 지속적으로 연결할 필요가 없습니다.
클라이언트가 공개 클라이언트여야 하는 이유
비밀 클라이언트는 키를 발급하고 이를 kubelogin 플러그인의 설정에 추가한 뒤 접근이 필요한 모든 장치에 배포합니다. 자료는 모든 클라이언트에 배포해야 하는 키는 더 이상 실제 비밀이 아니라 교체가 어려운 고정 공유 자격 증명이라고 봅니다. 명령줄 애플리케이션과 네이티브 애플리케이션에서는 비밀이 없는 공개 클라이언트에 PKCE(Proof Key for Code Exchange)를 활성화하는 것이 가장 적절한 선택입니다.
클라이언트는 로컬에서 무작위 값을 생성하고 초기 로그인 요청에 그 값의 해시를 보낸 다음, 권한 부여 코드를 액세스 토큰으로 교환할 때 원래 값을 보유하고 있음을 증명합니다. 따라서 권한 부여 코드만 가로챈 사람은 절차를 완료할 수 없습니다. 자료에 제시된 Keycloak 설정은 클라이언트 인증을 비활성화하고, 표준 흐름을 활성화하며, 직접 액세스 권한 부여를 비활성화하고, S256을 사용한 PKCE를 강제합니다. 또한 리디렉션 URI와 웹 출처를 127.0.0.1 및 localhost와 같은 loopback 주소로 제한합니다.
기본 설정 단계
- Keycloak의 클라이언트 범위에 그룹 구성원 매퍼를 추가하여 ID 토큰 안에 groups라는 이름의 클레임이 표시되도록 합니다.
- oidc-issuer-url, oidc-client-id, oidc-username-claim, oidc-groups-claim과 같은 플래그를 사용하여 kube-apiserver를 설정합니다.
- ID 공급자가 공개적으로 신뢰할 수 있는 기관에서 서명하지 않은 인증서를 사용하는 경우 oidc-ca-file을 추가하여 API 서버가 TLS 연결을 검증하고 서명 키를 가져올 수 있도록 합니다.
- 인증서나 고정 토큰을 포함하는 대신 kubectl oidc-login을 통한 exec-credential 항목을 사용하도록 kubeconfig를 수정하며, 비밀 필드는 추가하지 않습니다.
- ID 공급자 그룹을 Kubernetes RBAC 역할에 연결합니다. 예를 들어 platform-viewer 그룹을 view 역할에 연결할 수 있습니다.
실제 효과와 한계
이 연결을 설정하면 접근 권한 변경은 클러스터를 수정하거나 kubeconfig를 다시 배포하는 대신 ID 공급자 내부에서 수행됩니다. 사용자를 그룹에 추가하거나 그룹에서 제거하면 됩니다. 사용자가 다음에 발급받는 토큰에는 새로운 그룹 구성원 자격이 포함되므로 연결된 RBAC 규칙이 적용됩니다. 자료는 최초 로그인 시 브라우저가 열리고, 이후 kubelogin이 캐시된 토큰이 만료될 때까지 이를 재사용한 다음 새 브라우저 절차 없이 갱신 토큰을 사용한다고 설명합니다. 실제 ID와 그룹은 kubectl auth whoami 명령으로 확인할 수 있습니다.
그렇다고 통합에 운영상의 요구 사항이 없는 것은 아닙니다. 그룹 클레임을 정확히 설정하고, ID 공급자의 인증서를 검증하며, 리디렉션 URI를 제한하고, RBAC 역할이 필요한 권한을 반영하는지 확인해야 합니다. 또한 자료는 설정 시간이나 운영 비용에 대한 독립적인 측정치를 제시하지 않고, 전체 플랫폼을 마이그레이션하는 것이 아니라 한 번의 업무 시간 내에 준비가 완료될 수 있다고 추정합니다.
가장 중요한 보안 및 관리상의 이점은 Kubernetes 로그가 실제 사용자 ID와 연결된다는 점입니다. cluster-admin과 같은 일반 계정을 사용하는 로그는 요청을 실행한 사람을 구분하지 못하지만, OIDC를 통해 발생한 각 요청에는 사용자 이름과 연결된 그룹이 포함됩니다. 이는 자료의 세부 사항에 근거한 편집적 해석입니다. 개선점은 로그인 방식에만 있는 것이 아니라 작업을 수행한 사람에게 행동을 귀속할 수 있는 가능성에 있으며, 권한 부여와 철회를 분산된 자격 증명 파일을 찾는 작업이 아니라 중앙 집중식 ID 관리 절차로 만든다는 데 있습니다.