쿠버네티스 API 접근 제어하기

쿠버네티스 API 접근 제어하기 (Controlling Access to the Kubernetes API)

이 페이지는 쿠버네티스 API 접근을 제어하는 방법의 개요를 제공해요.

사용자는 kubectl, 클라이언트 라이브러리, 또는 REST 요청을 만들어 쿠버네티스 API에 접근해요. 사람 사용자와 쿠버네티스 서비스 계정 모두 API 접근 권한을 부여받을 수 있어요. 요청이 API에 도달하면 여러 단계를 거치는데, 다음 다이어그램에 나와 있어요.

출처: 문서

본문

전송 보안 (Transport security)

기본적으로 쿠버네티스 API 서버는 첫 번째 non-localhost 네트워크 인터페이스의 포트 6443에서 TLS로 보호된 상태로 수신 대기해요. 일반적인 프로덕션 쿠버네티스 클러스터에서 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 모듈을 실행하도록 구성해요. Authenticator에 대한 자세한 내용은 '인증' 문서에 설명돼 있어요.

인증 단계의 입력은 전체 HTTP 요청이지만, 보통 헤더 및/또는 클라이언트 인증서를 검사해요.

인증 모듈에는 클라이언트 인증서, 비밀번호, 일반 토큰, 부트스트랩 토큰, 그리고 JSON 웹 토큰(서비스 계정용)이 포함돼요.

여러 인증 모듈을 지정할 수 있으며, 이 경우 각 모듈이 하나가 성공할 때까지 순서대로 시도돼요.

요청을 인증할 수 없으면 HTTP 상태 코드 401로 거부돼요. 그렇지 않으면 사용자는 특정 사용자 이름으로 인증되고, 그 사용자 이름은 이후 단계에서 결정에 사용할 수 있어요. 일부 인증자는 사용자의 그룹 구성원을 제공하지만, 다른 인증자는 제공하지 않아요.

쿠버네티스는 접근 제어 결정과 요청 로깅에 사용자 이름을 사용하지만, User 객체가 없고 API에 사용자 이름이나 사용자에 대한 다른 정보를 저장하지 않아요.

권한 부여 (Authorization)

요청이 특정 사용자로부터 온 것으로 인증된 후에는 그 요청이 권한 부여(authorized)되어야 해요. 다이어그램에서 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) 요청을 하면 권한이 거부돼요.

쿠버네티스 권한 부여는 기존 조직 전체 또는 클라우드 제공자 전체 접근 제어 시스템과 상호작용하기 위해 공통 REST 속성을 사용할 것을 요구해요. REST 형식을 사용하는 것이 중요한데, 이 제어 시스템들이 쿠버네티스 API 외의 다른 API와도 상호작용할 수 있기 때문이에요.

쿠버네티스는 ABAC 모드, RBAC 모드, Webhook 모드 같은 여러 권한 부여 모듈을 지원해요. 관리자가 클러스터를 만들 때 API 서버에서 사용할 권한 부여 모듈을 구성해요. 둘 이상의 권한 부여 모듈이 구성되면 쿠버네티스는 각 모듈을 확인하고, 어떤 모듈이 요청을 승인하면 요청은 진행될 수 있어요. 모든 모듈이 요청을 거부하면 요청은 거부돼요(HTTP 상태 코드 403).

지원되는 권한 부여 모듈로 정책을 만드는 방법의 세부 사항을 포함한 쿠버네티스 권한 부여에 대해 더 배우려면 '권한 부여(Authorization)'를 참고하세요.

어드미션 컨트롤 (Admission control)

어드미션 컨트롤(Admission Control) 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이에요. 권한 부여 모듈에 사용할 수 있는 속성 외에도, 어드미션 컨트롤 모듈은 생성되거나 수정되는 객체의 내용에 접근할 수 있어요.

어드미션 컨트롤러는 객체를 생성, 수정, 삭제, 연결(프록시)하는 요청에 작동해요. 어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않아요. 여러 어드미션 컨트롤러가 구성되면 순서대로 호출돼요.

다이어그램에서 3단계로 표시돼 있어요.

인증·권한 부여 모듈과 달리, 어드미션 컨트롤러 모듈 중 하나라도 거부하면 요청은 즉시 거부돼요.

객체를 거부하는 것 외에도, 어드미션 컨트롤러는 필드에 복잡한 기본값을 설정할 수도 있어요.

사용 가능한 어드미션 컨트롤 모듈은 '어드미션 컨트롤러' 문서에 설명돼 있어요.

요청이 모든 어드미션 컨트롤러를 통과하면, 해당 API 객체에 대한 검증 루틴으로 검증된 후 객체 저장소에 기록돼요(4단계로 표시).

감사 (Auditing)

쿠버네티스 감사는 클러스터에서의 일련의 작업 순서를 문서화하는, 보안 관련되고 시간순인 레코드 집합을 제공해요. 클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션, 그리고 제어 플레인 자체가 생성한 활동을 감사해요.

자세한 내용은 '감사(Auditing)'를 참고하세요.

더 알아보기 (Learn more)

인증, 권한 부여, API 접근 제어에 대한 더 많은 문서를 읽어 보세요.

다음에 대해 배울 수 있어요.

파드가 Secret을 사용해 API 자격 증명을 얻는 방법.