Kubernetes API 접근 통제하기
Kubernetes API 접근 통제하기 (Controlling Access to the Kubernetes API)
이 페이지는 Kubernetes API에 대한 접근을 통제하는 방법에 대한 개요를 제공해요.
사용자는 kubectl, 클라이언트 라이브러리를 사용하거나 REST 요청을 만들어 Kubernetes API에 접근합니다. 사람 사용자와 Kubernetes 서비스 계정 모두 API 접근 권한을 부여받을 수 있어요.
요청이 API에 도달하면 다음 다이어그램에 설명된 여러 단계를 거칩니다.
전송 보안 (Transport security)
기본적으로 Kubernetes API 서버는 첫 번째 비-로컬호스트(non-localhost) 네트워크 인터페이스의 포트 6443에서 TLS로 보호된 상태로 수신 대기합니다. 일반적인 프로덕션 Kubernetes 클러스터에서 API는 포트 443에서 서비스됩니다. 포트는 --secure-port로, 수신 IP 주소는 --bind-address 플래그로 변경할 수 있어요.
API 서버는 인증서를 제시합니다. 이 인증서는 프라이빗 인증 기관(CA)으로 서명하거나, 일반적으로 인정받는 CA에 연결된 공개 키 인프라를 기반으로 할 수 있어요. 인증서와 해당 개인 키는 --tls-cert-file과 --tls-private-key-file 플래그로 설정할 수 있습니다.
클러스터가 프라이빗 인증 기관을 사용한다면, 클라이언트의 ~/.kube/config에 그 CA 인증서의 사본이 구성되어 있어야 합니다. 그래야 연결을 신뢰하고 중간에 가로채이지 않았다고 확신할 수 있어요.
이 단계에서 클라이언트는 TLS 클라이언트 인증서를 제시할 수 있습니다.
인증 (Authentication)
TLS가 설정되면 HTTP 요청은 인증(Authentication) 단계로 진행됩니다. 이는 다이어그램에서 단계 1로 표시됩니다.
클러스터 생성 스크립트 또는 클러스터 관리자는 API 서버가 하나 이상의 인증자(Authenticator) 모듈을 실행하도록 구성해요. 인증자에 대한 자세한 설명은 인증 문서에 있습니다.
인증 단계의 입력은 전체 HTTP 요청이지만, 일반적으로 헤더 및/또는 클라이언트 인증서를 검사합니다. 인증 모듈에는 클라이언트 인증서, 비밀번호, 평문 토큰, 부트스트랩 토큰, JSON 웹 토큰(서비스 계정용)이 포함됩니다.
여러 인증 모듈을 지정할 수 있으며, 그 경우 각각이 순서대로 시도되어 그중 하나가 성공할 때까지 진행합니다. 요청을 인증할 수 없으면 HTTP 상태 코드 401로 거부됩니다. 그렇지 않으면 사용자는 특정 username으로 인증되고, 그 사용자 이름은 이후 단계에서 결정에 사용할 수 있게 됩니다. 일부 인증자는 사용자의 그룹 구성원 자격도 제공하지만, 다른 인증자는 제공하지 않아요.
Kubernetes는 접근 통제 결정과 요청 로깅에 사용자 이름을 사용하지만, User 객체가 없고 API에 사용자 이름이나 사용자에 대한 다른 정보를 저장하지 않습니다.
권한 부여 (Authorization)
요청이 특정 사용자로부터 온 것으로 인증된 후에는 권한 부여(Authorization)를 받아야 합니다. 이는 다이어그램에서 단계 2로 표시됩니다.
요청에는 요청자의 사용자 이름, 요청된 동작, 그리고 그 동작의 영향을 받는 객체가 포함되어야 해요. 기존 정책이 사용자가 요청된 동작을 완료할 권한이 있다고 선언하면 요청이 허가됩니다.
예를 들어 Bob이 아래 정책을 가지고 있다면, projectCaribou 네임스페이스에서만 파드를 읽을 수 있어요.
{ "apiVersion" : "abac.authorization.kubernetes.io/v1beta1" , "kind" : "Policy" , "spec" : { "user" : "bob" , "namespace" : "projectCaribou" , "resource" : "pods" , "readonly" : true } }
Bob이 다음 요청을 하면, projectCaribou 네임스페이스에서 객체를 읽을 수 있기 때문에 요청이 허가됩니다.
{ "apiVersion" : "authorization.k8s.io/v1beta1" , "kind" : "SubjectAccessReview" , "spec" : { "resourceAttributes" : { "namespace" : "projectCaribou" , "verb" : "get" , "group" : "unicorn.example.org" , "resource" : "pods" } } }
Bob이 projectCaribou 네임스페이스의 객체에 쓰기(create 또는 update)를 요청하면 그의 권한 부여는 거부됩니다. Bob이 projectFish 같은 다른 네임스페이스에서 객체를 읽는(get) 요청을 하면 그의 권한 부여는 거부돼요.
Kubernetes 권한 부여는 조직 전체 또는 클라우드 제공자 전체의 기존 접근 통제 시스템과 상호작용하기 위해 공통 REST 속성을 사용해야 합니다. 이런 통제 시스템이 Kubernetes API 외의 다른 API와도 상호작용할 수 있기 때문에 REST 형식을 사용하는 것이 중요해요.
Kubernetes는 ABAC 모드, RBAC 모드, Webhook 모드 같은 여러 권한 부여 모듈을 지원합니다. 관리자가 클러스터를 만들 때 API 서버에서 사용할 권한 부여 모듈을 구성해요. 둘 이상의 권한 부여 모듈이 구성되면 Kubernetes는 각 모듈을 확인하고, 어떤 모듈이라도 요청을 허가하면 요청이 진행될 수 있습니다. 모든 모듈이 요청을 거부하면 요청은 거부됩니다(HTTP 상태 코드 403).
지원되는 권한 부여 모듈을 사용해 정책을 만드는 방법에 대한 세부 사항을 포함해 Kubernetes 권한 부여에 대해 더 배우려면 권한 부여 문서를 참조하세요.
어드미션 컨트롤 (Admission control)
어드미션 컨트롤(Admission Control) 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이에요. 권한 부여 모듈에 사용 가능한 속성 외에도, 어드미션 컨트롤 모듈은 생성되거나 수정되는 객체의 내용에 접근할 수 있습니다.
어드미션 컨트롤러는 객체를 생성, 수정, 삭제하거나 (프록시로) 연결하는 요청에 작동합니다. 어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않아요. 여러 어드미션 컨트롤러가 구성되면 순서대로 호출됩니다. 이는 다이어그램에서 단계 3으로 표시됩니다.
인증 및 권한 부여 모듈과 달리, 어떤 어드미션 컨트롤러 모듈이라도 거부하면 요청은 즉시 거부됩니다. 객체를 거부하는 것 외에도, 어드미션 컨트롤러는 필드에 대한 복잡한 기본값을 설정할 수도 있어요.
사용 가능한 어드미션 컨트롤 모듈은 어드미션 컨트롤러 문서에 설명되어 있습니다. 요청이 모든 어드미션 컨트롤러를 통과하면 해당 API 객체의 검증 루틴을 사용해서 검증되고, 그 후 객체 저장소에 기록됩니다(단계 4로 표시).
감사 (Auditing)
Kubernetes 감사는 클러스터에서 일어난 일련의 동작을 기록하는, 보안과 관련된 시간순 레코드 집합을 제공합니다. 클러스터는 사용자, Kubernetes API를 사용하는 애플리케이션, 그리고 컨트롤 플레인 자체가 생성한 활동들을 감사해요.
자세한 내용은 감사 문서를 참조하세요.
다음 단계 (What's next)
인증, 권한 부여, API 접근 통제에 대한 더 많은 문서를 읽어보세요.
- 인증(Authenticating)
- 부트스트랩 토큰으로 인증
- 어드미션 컨트롤러(Admission Controllers)
- 동적 어드미션 컨트롤
- 권한 부여(Authorization)
- 역할 기반 접근 통제(Role Based Access Control)
- 속성 기반 접근 통제(Attribute Based Access Control)
- 노드 권한 부여(Node Authorization)
- 웹훅 권한 부여(Webhook Authorization)
- 인증서 서명 요청(Certificate Signing Requests)
- CSR 승인과 인증서 서명 포함
- 서비스 계정(Service accounts)