보안

• 1: 클라우드 네이티브 보안 개요
• 2: 쿠버네티스 API 접근 제어하기

1 - 클라우드 네이티브 보안 개요

이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다.

클라우드 네이티브 보안의 4C

보안은 계층으로 생각할 수 있다. 클라우드 네이티브 보안의 4C는 클라우드(Cloud), 클러스터(Cluster), 컨테이너(Container)와 코드(Code)이다.

클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 한다. 코드 계층은 강력한 기본(클라우드, 클러스터, 컨테이너) 보안 계층의 이점을 제공한다. 코드 수준에서 보안을 처리하여 기본 계층의 열악한 보안 표준을 보호할 수 없다.

클라우드

여러 면에서 클라우드(또는 공동 위치 서버, 또는 기업의 데이터 센터)는 쿠버네티스 클러스터 구성을 위한 신뢰 컴퓨팅 기반(trusted computing base) 이다. 클라우드 계층이 취약하거나 취약한 방식으로 구성된 경우 이 기반 위에서 구축된 구성 요소가 안전하다는 보장은 없다. 각 클라우드 공급자는 해당 환경에서 워크로드를 안전하게 실행하기 위한 보안 권장 사항을 제시한다.

클라우드 공급자 보안

자신의 하드웨어 또는 다른 클라우드 공급자에서 쿠버네티스 클러스터를 실행 중인 경우, 보안 모범 사례는 설명서를 참고한다. 다음은 인기있는 클라우드 공급자의 보안 문서 중 일부에 대한 링크이다.

인프라스트럭처 보안

쿠버네티스 클러스터에서 인프라 보안을 위한 제안은 다음과 같다.

클러스터

쿠버네티스 보안에는 다음의 두 가지 영역이 있다.

• 설정 가능한 클러스터 컴포넌트의 보안
• 클러스터에서 실행되는 애플리케이션의 보안

클러스터의 컴포넌트

우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, 모범 사례에 대한 정보를 채택하기 위해서는 클러스터 보안에 대한 조언을 읽고 따른다.

클러스터 내 컴포넌트(애플리케이션)

애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와 리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, 서비스 B의 리소스를 제한하지 않으면 서비스 A가 손상될 위험이 높다. 다음은 쿠버네티스에서 실행되는 워크로드를 보호하기 위한 보안 문제 및 권장 사항이 나와 있는 표이다.

컨테이너

컨테이너 보안은 이 가이드의 범위를 벗어난다. 다음은 일반적인 권장사항과 이 주제에 대한 링크이다.

코드

애플리케이션 코드는 가장 많은 제어를 할 수 있는 주요 공격 영역 중 하나이다. 애플리케이션 코드 보안은 쿠버네티스 보안 주제를 벗어나지만, 애플리케이션 코드를 보호하기 위한 권장 사항은 다음과 같다.

코드 보안

다음 내용

쿠버네티스 보안 주제에 관련한 내용들을 배워보자.

• 파드 보안 표준
• 파드에 대한 네트워크 정책
• 쿠버네티스 API 접근 제어하기
• 클러스터 보안
• 컨트롤 플레인을 위한 전송 데이터 암호화
• Rest에서 데이터 암호화
• 쿠버네티스 시크릿
• 런타임 클래스

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

이 페이지는 쿠버네티스 API에 대한 접근 제어의 개요를 제공한다.

사용자는 kubectl, 클라이언트 라이브러리 또는 REST 요청을 통해 API에 접근한다. 사용자와 쿠버네티스 서비스 어카운트 모두 API에 접근할 수 있다. 요청이 API에 도달하면, 다음 다이어그램에 설명된 몇 가지 단계를 거친다.

전송 보안

일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다. API 서버는 인증서를 제시한다. 이 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 $USER/.kube/config는 API 서버의 인증서에 대한 루트 인증서를 포함하며, 시스템 기본 루트 인증서 대신 사용된다. kube-up.sh을 사용하여 클러스터를 직접 생성할 때 이 인증서는 일반적으로 $USER/.kube/config에 자동으로 기록된다. 클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.

인증

TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다. 이는 다이어그램에 1단계로 표시되어 있다. 클러스터 생성 스크립트 또는 클러스터 관리자는 API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다. 인증기는 여기에서 더 자세히 서술한다.

인증 단계로 들어가는 것은 온전한 HTTP 요청이지만 일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.

인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰, JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.

여러 개의 인증 모듈을 지정할 수 있으며, 이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.

GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.

요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다. 이 외에는 사용자가 특정 username으로 인증되며, 이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다. 일부 인증기는 사용자 그룹 관리 기능을 제공하는 반면, 이외의 인증기는 그렇지 않다.

쿠버네티스는 접근 제어 결정과 요청 기록 시 usernames를 사용하지만, user 오브젝트를 가지고 있지 않고 usernames 나 기타 사용자 정보를 오브젝트 저장소에 저장하지도 않는다.

인가

특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다. 이는 다이어그램에 2단계로 표시되어 있다.

요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다. 기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우 요청이 인가된다.

예를 들어 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 속성을 사용하여 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 상호 작용할 것을 요구한다. 이러한 제어 시스템은 쿠버네티스 API 이외의 다른 API와 상호작용할 수 있으므로 REST 형식을 사용하는 것이 중요하다.

쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).

인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 인가 개요를 참조한다.

어드미션 제어

어드미션 제어 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이다. 인가 모듈에서 사용할 수 있는 속성 외에도 어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.

어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다. 어드미션 컨트롤러는 단순히 오브젝트를 읽는 요청에는 작동하지 않는다. 여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.

이는 다이어그램에 3단계로 표시되어 있다.

인증 및 인가 모듈과 달리, 어드미션 제어 모듈이 거부되면 요청은 즉시 거부된다.

어드미션 제어 모듈은 오브젝트를 거부하는 것 외에도 필드의 복잡한 기본값을 설정할 수 있다.

사용 가능한 어드미션 제어 모듈은 여기에 서술되어 있다.

요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후 오브젝트 저장소에 기록(4단계)된다.

API 서버 포트와 IP

이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다. API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.

기본적으로, 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.

1. 로컬호스트 포트:

   • 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소 (스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
   • TLS가 없다.
   • 기본 포트는 8080이다.
   • 기본 IP는 로컬호스트(localhost)이며, --insecure-bind-address 플래그를 사용하여 변경한다.
   • 요청이 인증 및 인가 모듈을 우회한다.
   • 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
   • 호스트 접근 요구로부터 보호를 받는다.

2. 보안 포트:

   • 가능한 항상 사용하는 것이 좋다.
   • TLS를 사용한다. --tls-cert-file 플래그로 인증서를 지정하고 --tls-private-key-file 플래그로 키를 지정한다.
   • 기본 포트는 6443이며, --secure-port 플래그를 사용하여 변경한다.
   • 기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, --bind-address 플래그를 사용하여 변경한다.
   • 요청이 인증 및 인가 모듈에 의해 처리된다.
   • 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
   • 인증 및 인가 모듈을 실행한다.

GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 kube-up.sh로 클러스터를 생성하면 API 서버는 포트 443에서 서비스한다. GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다. 이외에 클러스터 설정 방법은 다양하다.