정책

• 1: 리밋 레인지(Limit Range)
• 2: 리소스 쿼터
• 3: 파드 시큐리티 폴리시
• 4: 노드 리소스 매니저

1 - 리밋 레인지(Limit Range)

기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 컴퓨팅 리소스로 실행된다. 리소스 쿼터을 사용하면 클러스터 관리자는 네임스페이스별로 리소스 사용과 생성을 제한할 수 있다. 네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다.

리밋레인지 는 다음과 같은 제약 조건을 제공한다.

• 네임스페이스에서 파드 또는 컨테이너별 최소 및 최대 컴퓨팅 리소스 사용량을 지정한다.
• 네임스페이스에서 스토리지클래스별 최소 및 최대 스토리지 요청을 지정한다.
• 네임스페이스에서 리소스에 대한 요청과 제한 사이의 비율을 지정한다.
• 네임스페이스에서 컴퓨팅 리소스에 대한 기본 요청/제한을 설정하고 런타임에 있는 컨테이너에 자동으로 설정한다.

리밋레인지 활성화

쿠버네티스 1.10 버전부터 리밋레인지 지원이 기본적으로 활성화되었다.

해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 특정 네임스페이스에 리밋레인지가 지정된다.

리밋레인지 오브젝트의 이름은 유효한 DNS 서브도메인 이름이어야 한다.

리밋 레인지 개요

• 관리자는 하나의 네임스페이스에 하나의 리밋레인지를 만든다.
• 사용자는 네임스페이스에서 파드, 컨테이너 및 퍼시스턴트볼륨클레임과 같은 리소스를 생성한다.
• LimitRanger 어드미션 컨트롤러는 컴퓨팅 리소스 요청 사항을 설정하지 않은 모든 파드와 컨테이너에 대한 기본값과 제한을 지정하고 네임스페이스의 리밋레인지에 정의된 리소스의 최소, 최대 및 비율을 초과하지 않도록 사용량을 추적한다.
• 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하는 경우 HTTP 상태 코드 403 FORBIDDEN 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다.
• cpu, memory와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다.
• 리밋레인지 유효성 검사는 파드 실행 단계가 아닌 파드 어드미션 단계에서만 발생한다.

리밋 레인지를 사용하여 생성할 수 있는 정책의 예는 다음과 같다.

• 용량이 8GiB RAM과 16 코어인 2 노드 클러스터에서 네임스페이스의 파드를 제한하여 CPU의 최대 제한이 500m인 CPU 100m를 요청하고 메모리의 최대 제한이 600M인 메모리 200Mi를 요청하라.
• 스펙에 CPU 및 메모리 요청없이 시작된 컨테이너에 대해 기본 CPU 제한 및 요청을 150m로, 메모리 기본 요청을 300Mi로 정의하라.

네임스페이스의 총 제한이 파드/컨테이너의 제한 합보다 작은 경우 리소스에 대한 경합이 있을 수 있다. 이 경우 컨테이너 또는 파드가 생성되지 않는다.

경합이나 리밋레인지 변경은 이미 생성된 리소스에 영향을 미치지 않는다.

다음 내용

자세한 내용은 LimitRanger 디자인 문서를 참조한다.

제한의 사용에 대한 예시는 다음을 참조한다.

• 네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법.
• 네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법.
• 네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법.
• 네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법.
• 네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법.
• 네임스페이스당 할당량을 설정하는 자세한 예시.

2 - 리소스 쿼터

여러 사용자나 팀이 정해진 수의 노드로 클러스터를 공유할 때 한 팀이 공정하게 분배된 리소스보다 많은 리소스를 사용할 수 있다는 우려가 있다.

리소스 쿼터는 관리자가 이 문제를 해결하기 위한 도구이다.

ResourceQuota 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는 제약 조건을 제공한다. 유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와 해당 네임스페이스의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을 제한할 수 있다.

리소스 쿼터는 다음과 같이 작동한다.

• 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을 적용하기 위한 지원이 계획되어 있다.

• 관리자는 각 네임스페이스에 대해 하나의 리소스쿼터를 생성한다.

• 사용자는 네임스페이스에서 리소스(파드, 서비스 등)를 생성하고 쿼터 시스템은 사용량을 추적하여 리소스쿼터에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다.

• 리소스를 생성하거나 업데이트할 때 쿼터 제약 조건을 위반하면 위반된 제약 조건을 설명하는 메시지와 함께 HTTP 상태 코드 403 FORBIDDEN으로 요청이 실패한다.

• cpu, memory와 같은 컴퓨트 리소스에 대해 네임스페이스에서 쿼터가 활성화된 경우 사용자는 해당값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 쿼터 시스템이 파드 생성을 거부할 수 있다. 힌트: 컴퓨트 리소스 요구 사항이 없는 파드를 기본값으로 설정하려면 LimitRanger 어드미션 컨트롤러를 사용하자.

  이 문제를 회피하는 방법에 대한 예제는 연습을 참고하길 바란다.

리소스쿼터 오브젝트의 이름은 유효한 DNS 서브도메인 이름이어야 한다.

네임스페이스와 쿼터를 사용하여 만들 수 있는 정책의 예는 다음과 같다.

• 용량이 32GiB RAM, 16 코어인 클러스터에서 A 팀이 20GiB 및 10 코어를 사용하고 B 팀은 10GiB 및 4 코어를 사용하게 하고 2GiB 및 2 코어를 향후 할당을 위해 보유하도록 한다.
• "testing" 네임스페이스를 1 코어 및 1GiB RAM을 사용하도록 제한한다. "production" 네임스페이스에는 원하는 양을 사용하도록 한다.

클러스터의 총 용량이 네임스페이스의 쿼터 합보다 작은 경우 리소스에 대한 경합이 있을 수 있다. 이것은 선착순으로 처리된다.

경합이나 쿼터 변경은 이미 생성된 리소스에 영향을 미치지 않는다.

리소스 쿼터 활성화

많은 쿠버네티스 배포판에 기본적으로 리소스 쿼터 지원이 활성화되어 있다. API 서버 --enable-admission-plugins= 플래그의 인수 중 하나로 ResourceQuota가 있는 경우 활성화된다.

해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에 리소스 쿼터가 적용된다.

컴퓨트 리소스 쿼터

지정된 네임스페이스에서 요청할 수 있는 총 컴퓨트 리소스 합을 제한할 수 있다.

다음과 같은 리소스 유형이 지원된다.

확장된 리소스에 대한 리소스 쿼터

위에서 언급한 리소스 외에도 릴리스 1.10에서는 확장된 리소스에 대한 쿼터 지원이 추가되었다.

확장된 리소스에는 오버커밋(overcommit)이 허용되지 않으므로 하나의 쿼터에서 동일한 확장된 리소스에 대한 requests와 limits을 모두 지정하는 것은 의미가 없다. 따라서 확장된 리소스의 경우 지금은 접두사 requests.이 있는 쿼터 항목만 허용된다.

예를 들어, 리소스 이름이 nvidia.com/gpu이고 네임스페이스에서 요청된 총 GPU 수를 4개로 제한하려는 경우, GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.

• requests.nvidia.com/gpu: 4

자세한 내용은 쿼터 보기 및 설정을 참고하길 바란다.

스토리지 리소스 쿼터

지정된 네임스페이스에서 요청할 수 있는 총 스토리지 리소스 합을 제한할 수 있다.

또한 연관된 ​​스토리지 클래스를 기반으로 스토리지 리소스 사용을 제한할 수 있다.

예를 들어, 운영자가 bronze 스토리지 클래스와 별도로 gold 스토리지 클래스를 사용하여 스토리지에 쿼터를 지정하려는 경우 운영자는 다음과 같이 쿼터를 정의할 수 있다.

• gold.storageclass.storage.k8s.io/requests.storage: 500Gi
• bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

릴리스 1.8에서는 로컬 임시 스토리지에 대한 쿼터 지원이 알파 기능으로 추가되었다.

참고: CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스토리지 쿼터에 포함된다. 이로 인해 스토리지 쿼터를 소진한 파드가 예기치 않게 축출될 수 있다. 자세한 내용은 로깅 아키텍처를 참조한다.

오브젝트 수 쿼터

다음 구문을 사용하여 모든 표준 네임스페이스 처리된(namespaced) 리소스 유형에 대한 특정 리소스 전체 수에 대하여 쿼터를 지정할 수 있다.

• 코어 그룹이 아닌(non-core) 리소스를 위한 count/<resource>.<group>
• 코어 그룹의 리소스를 위한 count/<resource>

다음은 사용자가 오브젝트 수 쿼터 아래에 배치하려는 리소스 셋의 예이다.

• count/persistentvolumeclaims
• count/services
• count/secrets
• count/configmaps
• count/replicationcontrollers
• count/deployments.apps
• count/replicasets.apps
• count/statefulsets.apps
• count/jobs.batch
• count/cronjobs.batch

사용자 정의 리소스를 위해 동일한 구문을 사용할 수 있다. 예를 들어 example.com API 그룹에서 widgets 사용자 정의 리소스에 대한 쿼터를 생성하려면 count/widgets.example.com을 사용한다.

count/* 리소스 쿼터를 사용할 때 서버 스토리지 영역에 있다면 오브젝트는 쿼터에 대해 과금된다. 이러한 유형의 쿼터는 스토리지 리소스 고갈을 방지하는 데 유용하다. 예를 들어, 크기가 큰 서버에서 시크릿 수에 쿼터를 지정할 수 있다. 클러스터에 시크릿이 너무 많으면 실제로 서버와 컨트롤러가 시작되지 않을 수 있다. 잘못 구성된 크론 잡으로부터의 보호를 위해 잡의 쿼터를 설정할 수 있다. 네임스페이스 내에서 너무 많은 잡을 생성하는 크론 잡은 서비스 거부를 유발할 수 있다.

또한 제한된 리소스 셋에 대해서 일반 오브젝트 수(generic object count) 쿼터를 적용하는 것도 가능하다. 다음 유형이 지원된다.

예를 들어, pods 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 pods 수를 계산하고 최댓값을 적용한다. 사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP 공급이 고갈되는 경우를 피하기 위해 네임스페이스에 pods 쿼터를 설정할 수 있다.

쿼터 범위

각 쿼터에는 연결된 scopes 셋이 있을 수 있다. 쿼터는 열거된 범위의 교차 부분과 일치하는 경우에만 리소스 사용량을 측정한다.

범위가 쿼터에 추가되면 해당 범위와 관련된 리소스를 지원하는 리소스 수가 제한된다. 허용된 셋 이외의 쿼터에 지정된 리소스는 유효성 검사 오류가 발생한다.

BestEffort 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.

• pods

Terminating, NotTerminating, NotBestEffort 및 PriorityClass 범위는 쿼터를 제한하여 다음의 리소스를 추적한다.

• pods
• cpu
• memory
• requests.cpu
• requests.memory
• limits.cpu
• limits.memory

Terminating 과 NotTerminating 범위를 동일한 쿼터 내에 모두 명시하지는 못하며, 마찬가지로 BestEffort 와 NotBestEffort 범위도 동일한 쿼터 내에서 모두 명시하지는 못한다.

scopeSelector 는 operator 필드에 다음의 값을 지원한다.

• In
• NotIn
• Exists
• DoesNotExist

scopeSelector 를 정의할 때, scopeName 으로 다음의 값 중 하나를 사용하는 경우, operator 는 Exists 이어야 한다.

• Terminating
• NotTerminating
• BestEffort
• NotBestEffort

만약 operator 가 In 또는 NotIn 인 경우, values 필드는 적어도 하나의 값은 가져야 한다. 예를 들면 다음과 같다.

  scopeSelector:
    matchExpressions:
      - scopeName: PriorityClass
        operator: In
        values:
          - middle

만약 operator 가 Exists 또는 DoesNotExist 이라면, values 필드는 명시되면 안된다.

PriorityClass별 리소스 쿼터

특정 우선 순위로 파드를 생성할 수 있다. 쿼터 스펙의 scopeSelector 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을 제어할 수 있다.

쿼터 스펙의 scopeSelector가 파드를 선택한 경우에만 쿼터가 일치하고 사용된다.

scopeSelector 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면, 쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다.

• pods
• cpu
• memory
• ephemeral-storage
• limits.cpu
• limits.memory
• limits.ephemeral-storage
• requests.cpu
• requests.memory
• requests.ephemeral-storage

이 예에서는 쿼터 오브젝트를 생성하여 특정 우선 순위의 파드와 일치시킨다. 예제는 다음과 같이 작동한다.

• 클러스터의 파드는 "low(낮음)", "medium(중간)", "high(높음)"의 세 가지 우선 순위 클래스 중 하나를 가진다.
• 각 우선 순위마다 하나의 쿼터 오브젝트가 생성된다.

다음 YAML을 quota.yml 파일에 저장한다.

apiVersion: v1
kind: List
items:
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-high
  spec:
    hard:
      cpu: "1000"
      memory: 200Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["high"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-medium
  spec:
    hard:
      cpu: "10"
      memory: 20Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["medium"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-low
  spec:
    hard:
      cpu: "5"
      memory: 10Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["low"]

kubectl create를 사용하여 YAML을 적용한다.

kubectl create -f ./quota.yml

resourcequota/pods-high created
resourcequota/pods-medium created
resourcequota/pods-low created

kubectl describe quota를 사용하여 Used 쿼터가 0인지 확인하자.

kubectl describe quota

Name:       pods-high
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     1k
memory      0     200Gi
pods        0     10


Name:       pods-low
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     5
memory      0     10Gi
pods        0     10


Name:       pods-medium
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     10
memory      0     20Gi
pods        0     10

우선 순위가 "high"인 파드를 생성한다. 다음 YAML을 high-priority-pod.yml 파일에 저장한다.

apiVersion: v1
kind: Pod
metadata:
  name: high-priority
spec:
  containers:
  - name: high-priority
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello; sleep 10;done"]
    resources:
      requests:
        memory: "10Gi"
        cpu: "500m"
      limits:
        memory: "10Gi"
        cpu: "500m"
  priorityClassName: high

kubectl create로 적용하자.

kubectl create -f ./high-priority-pod.yml

"high" 우선 순위 쿼터가 적용된 pods-high에 대한 "Used" 통계가 변경되었고 다른 두 쿼터는 변경되지 않았는지 확인한다.

kubectl describe quota

Name:       pods-high
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         500m  1k
memory      10Gi  200Gi
pods        1     10


Name:       pods-low
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     5
memory      0     10Gi
pods        0     10


Name:       pods-medium
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     10
memory      0     20Gi
pods        0     10

네임스페이스 간 파드 어피니티 쿼터

오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를 제한하기 위해 CrossNamespacePodAffinity 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의 namespaces 또는 namespaceSelector 필드를 설정할 수 있는 파드를 제어한다.

안티-어피니티 제약 조건이 있는 파드는 장애 도메인에서 다른 모든 네임스페이스의 파드가 예약되지 않도록 차단할 수 있으므로 사용자가 네임스페이스 간 어피니티 용어를 사용하지 못하도록 하는 것이 바람직할 수 있다.

이 범위 오퍼레이터를 사용하면 CrossNamespaceAffinity 범위와 하드(hard) 제한이 0인 네임스페이스에 리소스 쿼터 오브젝트를 생성하여 특정 네임스페이스(아래 예에서 foo-ns)가 네임스페이스 간 파드 어피니티를 사용하는 파드를 사용하지 못하도록 방지할 수 있다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: disable-cross-namespace-affinity
  namespace: foo-ns
spec:
  hard:
    pods: "0"
  scopeSelector:
    matchExpressions:
    - scopeName: CrossNamespaceAffinity

오퍼레이터가 기본적으로 namespaces 및 namespaceSelector 사용을 허용하지 않고, 특정 네임스페이스에만 허용하려는 경우, kube-apiserver 플래그 --admission-control-config-file를 다음의 구성 파일의 경로로 설정하여 CrossNamespaceAffinity 를 제한된 리소스로 구성할 수 있다.

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: ResourceQuotaConfiguration
    limitedResources:
    - resource: pods
      matchScopes:
      - scopeName: CrossNamespaceAffinity

위의 구성을 사용하면, 파드는 생성된 네임스페이스에 CrossNamespaceAffinity 범위가 있는 리소스 쿼터 오브젝트가 있고, 해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만 파드 어피니티에서 namespaces 및 namespaceSelector 를 사용할 수 있다.

이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서 기능 게이트 PodAffinityNamespaceSelector 를 설정하여 활성화할 수 있다.

요청과 제한의 비교

컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다. 쿼터는 값에 대한 쿼터를 지정하도록 구성할 수 있다.

쿼터에 requests.cpu나 requests.memory에 지정된 값이 있으면 들어오는 모든 컨테이너가 해당 리소스에 대한 명시적인 요청을 지정해야 한다. 쿼터에 limits.cpu나 limits.memory에 지정된 값이 있으면 들어오는 모든 컨테이너가 해당 리소스에 대한 명시적인 제한을 지정해야 한다.

쿼터 보기 및 설정

Kubectl은 쿼터 생성, 업데이트 및 보기를 지원한다.

kubectl create namespace myspace

cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.nvidia.com/gpu: 4
EOF

kubectl create -f ./compute-resources.yaml --namespace=myspace

cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    pods: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"
EOF

kubectl create -f ./object-counts.yaml --namespace=myspace

kubectl get quota --namespace=myspace

NAME                    AGE
compute-resources       30s
object-counts           32s

kubectl describe quota compute-resources --namespace=myspace

Name:                    compute-resources
Namespace:               myspace
Resource                 Used  Hard
--------                 ----  ----
limits.cpu               0     2
limits.memory            0     2Gi
requests.cpu             0     1
requests.memory          0     1Gi
requests.nvidia.com/gpu  0     4

kubectl describe quota object-counts --namespace=myspace

Name:                   object-counts
Namespace:              myspace
Resource                Used    Hard
--------                ----    ----
configmaps              0       10
persistentvolumeclaims  0       4
pods                    0       4
replicationcontrollers  0       20
secrets                 1       10
services                0       10
services.loadbalancers  0       2

Kubectl은 count/<resource>.<group> 구문을 사용하여 모든 표준 네임스페이스 리소스에 대한 오브젝트 수 쿼터를 지원한다.

kubectl create namespace myspace

kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace

kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2

kubectl describe quota --namespace=myspace

Name:                         test
Namespace:                    myspace
Resource                      Used  Hard
--------                      ----  ----
count/deployments.apps        1     2
count/pods                    2     3
count/replicasets.apps        1     4
count/secrets                 1     4

쿼터 및 클러스터 용량

리소스쿼터는 클러스터 용량과 무관하다. 그것들은 절대 단위로 표현된다. 따라서 클러스터에 노드를 추가해도 각 네임스페이스에 더 많은 리소스를 사용할 수 있는 기능이 자동으로 부여되지는 않는다.

가끔 다음과 같은 보다 복잡한 정책이 필요할 수 있다.

• 여러 팀으로 전체 클러스터 리소스를 비례적으로 나눈다.
• 각 테넌트가 필요에 따라 리소스 사용량을 늘릴 수 있지만, 실수로 리소스가 고갈되는 것을 막기 위한 충분한 제한이 있다.
• 하나의 네임스페이스에서 요구를 감지하고 노드를 추가하며 쿼터를 늘린다.

이러한 정책은 쿼터 사용을 감시하고 다른 신호에 따라 각 네임스페이스의 쿼터 하드 제한을 조정하는 "컨트롤러"를 작성하여 ResourceQuotas를 구성 요소로 사용하여 구현할 수 있다.

리소스 쿼터는 통합된 클러스터 리소스를 분할하지만 노드에 대한 제한은 없다. 여러 네임스페이스의 파드가 동일한 노드에서 실행될 수 있다.

기본적으로 우선 순위 클래스 소비 제한

파드가 특정 우선 순위, 예를 들어 일치하는 쿼터 오브젝트가 존재하는 경우에만 "cluster-services"가 네임스페이스에 허용되어야 한다.

이 메커니즘을 통해 운영자는 특정 우선 순위가 높은 클래스의 사용을 제한된 수의 네임스페이스로 제한할 수 있으며 모든 네임스페이스가 기본적으로 이러한 우선 순위 클래스를 사용할 수 있는 것은 아니다.

이를 적용하려면 kube-apiserver 플래그 --admission-control-config-file 을 사용하여 다음 구성 파일의 경로를 전달해야 한다.

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: ResourceQuotaConfiguration
    limitedResources:
    - resource: pods
      matchScopes:
      - scopeName: PriorityClass
        operator: In
        values: ["cluster-services"]

그리고, kube-system 네임스페이스에 리소스 쿼터 오브젝트를 생성한다.

policy/priority-class-resourcequota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-cluster-services
spec:
  scopeSelector:
    matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["cluster-services"]

kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system

resourcequota/pods-cluster-services created

이 경우, 파드 생성은 다음의 조건을 만족해야 허용될 것이다.

1. 파드의 priorityClassName 가 명시되지 않음.
2. 파드의 priorityClassName 가 cluster-services 이외의 다른 값으로 명시됨.
3. 파드의 priorityClassName 가 cluster-services 로 설정되고, 파드가 kube-system 네임스페이스에 생성되었으며 리소스 쿼터 검증을 통과함.

파드 생성 요청은 priorityClassName 가 cluster-services 로 명시되고 kube-system 이외의 다른 네임스페이스에 생성되는 경우, 거절된다.

다음 내용

• 자세한 내용은 리소스쿼터 디자인 문서를 참고한다.
• 리소스 쿼터를 사용하는 방법에 대한 자세한 예를 참고한다.
• 우선 순위 클래스에 대한 쿼터 지원 디자인 문서를 읽는다.
• 제한된 자원을 참고한다.

3 - 파드 시큐리티 폴리시

파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다. 사용 중단에 대한 상세 사항은 파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래를 참조한다.

파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을 부여할 수 있다.

파드 시큐리티 폴리시란?

Pod Security Policy 는 파드 명세의 보안 관련 측면을 제어하는 ​​클러스터-레벨의 리소스이다. 파드시큐리티폴리시 오브젝트는 관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는 조건 셋을 정의한다. 관리자는 다음을 제어할 수 있다.

파드 시큐리티 폴리시 활성화

파드 시큐리티 폴리시 제어는 선택 사항인 어드미션 컨트롤러로 구현된다. 어드미션 컨트롤러를 활성화하면 파드시큐리티폴리시가 적용되지만, 정책을 승인하지 않고 활성화하면 클러스터에 파드가 생성되지 않는다.

파드 시큐리티 폴리시 API(policy/v1beta1/podsecuritypolicy)는 어드미션 컨트롤러와 독립적으로 활성화되므로 기존 클러스터의 경우 어드미션 컨트롤러를 활성화하기 전에 정책을 추가하고 권한을 부여하는 것이 좋다.

정책 승인

파드시큐리티폴리시 리소스가 생성되면 아무 것도 수행하지 않는다. 이를 사용하려면 요청 사용자 또는 대상 파드의 서비스 어카운트는 정책에서 use 동사를 허용하여 정책을 사용할 권한이 있어야 한다.

대부분의 쿠버네티스 파드는 사용자가 직접 만들지 않는다. 대신 일반적으로 컨트롤러 관리자를 통해 디플로이먼트, 레플리카셋, 또는 기타 템플릿 컨트롤러의 일부로 간접적으로 생성된다. 컨트롤러에 정책에 대한 접근 권한을 부여하면 해당 컨트롤러에 의해 생성된 모든 파드에 대한 접근 권한이 부여되므로 정책을 승인하는 기본 방법은 파드의 서비스 어카운트에 대한 접근 권한을 부여하는 것이다(예 참고).

RBAC을 통한 방법

RBAC은 표준 쿠버네티스 권한 부여 모드이며, 정책 사용 권한을 부여하는 데 쉽게 사용할 수 있다.

먼저, Role 또는 ClusterRole은 원하는 정책을 use 하려면 접근 권한을 부여해야 한다. 접근 권한을 부여하는 규칙은 다음과 같다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <role name>
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - <list of policies to authorize>

그런 다음 (Cluster)Role이 승인된 사용자에게 바인딩된다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <binding name>
roleRef:
  kind: ClusterRole
  name: <role name>
  apiGroup: rbac.authorization.k8s.io
subjects:
# 네임스페이스의 모든 서비스 어카운트 승인(권장):
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts:<authorized namespace>
# 특정 서비스 어카운트 승인(권장하지 않음):
- kind: ServiceAccount
  name: <authorized service account name>
  namespace: <authorized pod namespace>
# 특정 사용자 승인(권장하지 않음):
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: <authorized user name>

RoleBinding(ClusterRoleBinding 아님)을 사용하는 경우, 바인딩과 동일한 네임스페이스에서 실행되는 파드에 대해서만 사용 권한을 부여한다. 네임스페이스에서 실행되는 모든 파드에 접근 권한을 부여하기 위해 시스템 그룹과 쌍을 이룰 수 있다.

# 네임스페이스의 모든 서비스 어카운트 승인:
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts
# 또는 동일하게, 네임스페이스의 모든 승인된 사용자에게 사용 권한 부여
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:authenticated

RBAC 바인딩에 대한 자세한 예는, 역할 바인딩 예제를 참고한다. 파드시큐리티폴리시 인증에 대한 전체 예제는 아래를 참고한다.

추천 예제

파드시큐리티폴리시는 새롭고 간결해진 PodSecurity 어드미션 컨트롤러로 대체되고 있다. 이 변경에 대한 상세사항은 파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래를 참조한다. 다음 가이드라인을 참조하여 파드시큐리티폴리시를 새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다.

1. 파드시큐리티폴리시를 파드 보안 표준에 의해 정의된 폴리시로 한정한다.

   • Privileged
   • Baseline
   • Restricted

2. system:serviceaccounts:<namespace> (여기서 <namespace>는 타겟 네임스페이스) 그룹을 사용하여 파드시큐리티폴리시를 전체 네임스페이스에만 바인드한다. 예시는 다음과 같다.

   apiVersion: rbac.authorization.k8s.io/v1
   # 이 클러스터롤바인딩(ClusterRoleBinding)을 통해 "development" 네임스페이스의 모든 파드가 기준 파드시큐리티폴리시(PSP)를 사용할 수 있다.
   kind: ClusterRoleBinding
   metadata:
     name: psp-baseline-namespaces
   roleRef:
     kind: ClusterRole
     name: psp-baseline
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: system:serviceaccounts:development
     apiGroup: rbac.authorization.k8s.io
   - kind: Group
     name: system:serviceaccounts:canary
     apiGroup: rbac.authorization.k8s.io
   

문제 해결

• 컨트롤러 관리자는 보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다. API 서버 접근 제어에 대한 자세한 내용은 쿠버네티스 API에 대한 접근 제어를 참고하길 바란다. 컨트롤러 관리자가 신뢰할 수 있는 API 포트(localhost 리스너라고도 함)를 통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고, 모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를 만들 수 있는 권한을 부여할 수 있다.

컨트롤러 관리자 권한 구성에 대한 자세한 내용은 컨트롤러 역할을 참고하기 바란다.

정책 순서

파드 생성 및 업데이트를 제한할 뿐만 아니라 파드 시큐리티 폴리시를 사용하여 제어하는 ​​많은 필드에 기본값을 제공할 수도 있다. 여러 정책을 사용할 수 있는 경우 파드 시큐리티 폴리시 컨트롤러는 다음 기준에 따라 정책을 선택한다.

1. 기본 설정을 변경하거나 파드를 변경하지 않고 파드를 있는 그대로 허용하는 파드시큐리티폴리시가 선호된다. 이러한 비-변이(non-mutating) 파드시큐리티폴리시의 순서는 중요하지 않다.
2. 파드를 기본값으로 설정하거나 변경해야 하는 경우, 파드를 허용할 첫 번째 파드시큐리티폴리시 (이름순)가 선택된다.

참고: 업데이트 작업 중(파드 스펙에 대한 변경이 허용되지 않는 동안) 비-변이 파드시큐리티폴리시만 파드의 유효성을 검사하는 데 사용된다.

예제

이 예에서는 파드시큐리티폴리시 어드미션 컨트롤러가 활성화된 클러스터가 실행 중이고 클러스터 관리자 권한이 있다고 가정한다.

설정

이 예제와 같이 네임스페이스와 서비스 어카운트를 설정한다. 이 서비스 어카운트를 사용하여 관리자가 아닌 사용자를 조정한다.

kubectl create namespace psp-example
kubectl create serviceaccount -n psp-example fake-user
kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user

어떤 사용자로 활동하고 있는지 명확하게 하고 입력 내용을 저장하려면 2개의 별칭(alias)을 만든다.

alias kubectl-admin='kubectl -n psp-example'
alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example'

정책과 파드 생성

파일에서 예제 파드시큐리티폴리시 오브젝트를 정의한다. 이는 특권있는 파드를 만들지 못하게 하는 정책이다. 파드시큐리티폴리시 오브젝트의 이름은 유효한 DNS 서브도메인 이름이어야 한다.

policy/example-psp.yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false  # 특권을 가진 파드는 허용금지!
  # 나머지는 일부 필수 필드를 채운다.
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

그리고 kubectl로 생성한다.

kubectl-admin create -f example-psp.yaml

이제 권한이 없는 사용자로서 간단한 파드를 생성해보자.

kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: pause
spec:
  containers:
    - name: pause
      image: k8s.gcr.io/pause
EOF

이것의 출력은 다음과 같을 것이다.

Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []

무슨 일이 일어났나? 파드시큐리티폴리시가 생성되었지만, 파드의 서비스 어카운트나 fake-user는 새 정책을 사용할 권한이 없다.

kubectl-user auth can-i use podsecuritypolicy/example
no

예제 정책에서 fake-user에게 use 동사를 부여하는 rolebinding을 생성한다.

참고: 이 방법은 권장하지 않는다! 선호하는 방법은 다음 절을 참고하길 바란다.

kubectl-admin create role psp:unprivileged \
    --verb=use \
    --resource=podsecuritypolicy \
    --resource-name=example
role "psp:unprivileged" created

kubectl-admin create rolebinding fake-user:psp:unprivileged \
    --role=psp:unprivileged \
    --serviceaccount=psp-example:fake-user
rolebinding "fake-user:psp:unprivileged" created

kubectl-user auth can-i use podsecuritypolicy/example
yes

이제 파드 생성을 다시 시도하자.

kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: pause
spec:
  containers:
    - name: pause
      image: k8s.gcr.io/pause
EOF

이것의 출력은 다음과 같을 것이다.

pod "pause" created

예상대로 작동한다! 그러나 특권있는 파드를 만들려는 시도는 여전히 거부되어야 한다.

kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: privileged
spec:
  containers:
    - name: pause
      image: k8s.gcr.io/pause
      securityContext:
        privileged: true
EOF

이것의 출력은 다음과 같을 것이다.

Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]

계속 진행하기 전에 파드를 삭제하자.

kubectl-user delete pod pause

다른 파드를 실행

약간 다르게 다시 시도해보자.

kubectl-user create deployment pause --image=k8s.gcr.io/pause
deployment "pause" created

kubectl-user get pods
No resources found.

kubectl-user get events | head -n 2
LASTSEEN   FIRSTSEEN   COUNT     NAME              KIND         SUBOBJECT                TYPE      REASON                  SOURCE                                  MESSAGE
1m         2m          15        pause-7774d79b5   ReplicaSet                            Warning   FailedCreate            replicaset-controller                   Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request

무슨 일이 일어났나? 우리는 이미 fake-user에 대해 psp:unprivileged 역할을 바인딩했는데, Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request 오류가 발생하는 이유는 무엇인가? 그 답은 소스인 replicaset-controller에 있다. Fake-user가 디플로이먼트를 성공적으로 생성했지만(레플리카셋을 성공적으로 생성했음), 레플리카셋이 파드를 생성했을 때 podsecuritypolicy 예제를 사용할 권한이 없었다.

이 문제를 해결하려면 psp:unprivileged 역할을 파드의 서비스 어카운트에 대신 바인딩한다. 이 경우(지정하지 않았으므로) 서비스 어카운트는 default이다.

kubectl-admin create rolebinding default:psp:unprivileged \
    --role=psp:unprivileged \
    --serviceaccount=psp-example:default
rolebinding "default:psp:unprivileged" created

이제 다시 한번 해본다면 replicaset-controller가 파드를 성공적으로 생성할 것이다.

kubectl-user get pods --watch
NAME                    READY     STATUS    RESTARTS   AGE
pause-7774d79b5-qrgcb   0/1       Pending   0         1s
pause-7774d79b5-qrgcb   0/1       Pending   0         1s
pause-7774d79b5-qrgcb   0/1       ContainerCreating   0         1s
pause-7774d79b5-qrgcb   1/1       Running   0         2s

정리

네임스페이스를 삭제하여 대부분의 예제 리소스를 정리한다.

kubectl-admin delete ns psp-example
namespace "psp-example" deleted

PodSecurityPolicy 리소스는 네임스페이스에 포함되지 않으므로 별도로 정리해야 한다.

kubectl-admin delete psp example
podsecuritypolicy "example" deleted

정책 예제

다음은 파드 시큐리티 폴리시 어드미션 컨트롤러를 사용하지 않는 것과 동일하게 만들 수 있는 최소한의 제한 정책이다.

policy/privileged-psp.yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: privileged
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  volumes:
  - '*'
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'

다음은 권한이 없는 사용자로서의 실행을 필요로 하고, 루트로의 에스컬레이션(escalation) 가능성을 차단하고, 여러 보안 메커니즘을 사용을 필요로 하는 제한적 정책의 예제이다.

policy/restricted-psp.yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
    apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
    apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
spec:
  privileged: false
  # 루트로의 에스컬레이션을 방지하는 데 필요하다.
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  # 기본 볼륨 유형을 허용한다.
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    # 클러스터 관리자에 의해 구성된 휘발성 CSI 드라이버와 퍼시스턴트볼륨(PersistentVolume)의 사용은 안전하다고 가정한다.
    - 'csi'
    - 'persistentVolumeClaim'
    - 'ephemeral'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    # 루트 권한없이 컨테이너를 실행해야 한다.
    rule: 'MustRunAsNonRoot'
  seLinux:
    # 이 정책은 노드가 SELinux가 아닌 AppArmor를 사용한다고 가정한다.
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # 루트 그룹을 추가하지 않는다.
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # 루트 그룹을 추가하지 않는다.
      - min: 1
        max: 65535
  readOnlyRootFilesystem: false

더 많은 예제는 파드 보안 표준을 본다.

정책 레퍼런스

특권을 가진

Privileged - 파드의 컨테이너가 특권 모드를 사용할 수 있는지 여부를 결정한다. 기본적으로 컨테이너는 호스트의 모든 장치에 접근할 수 없지만 "특권을 가진" 컨테이너는 호스트의 모든 장치에 접근할 수 있다. 이것은 컨테이너가 호스트에서 실행되는 프로세스와 거의 동일한 접근을 허용한다. 이것은 네트워크 스택 조작 및 장치 접근과 같은 리눅스 기능을 사용하려는 컨테이너에 유용하다.

호스트 네임스페이스

HostPID - 파드 컨테이너가 호스트 프로세스 ID 네임스페이스를 공유할 수 있는지 여부를 제어한다. ptrace와 함께 사용하면 컨테이너 외부로 권한을 에스컬레이션하는 데 사용할 수 있다(ptrace는 기본적으로 금지되어 있음).

HostIPC - 파드 컨테이너가 호스트 IPC 네임스페이스를 공유할 수 있는지 여부를 제어한다.

HostNetwork - 파드가 노드 네트워크 네임스페이스를 사용할 수 있는지 여부를 제어한다. 이렇게 하면 파드에 루프백 장치에 접근 권한을 주고, 서비스는 로컬호스트(localhost)를 리스닝할 수 있으며, 동일한 노드에 있는 다른 파드의 네트워크 활동을 스누핑(snoop)하는 데 사용할 수 있다.

HostPorts - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 목록을 제공한다. min과 max를 포함하여 HostPortRange의 목록으로 정의된다. 기본값은 허용하는 호스트 포트 없음(no allowed host ports)이다.

볼륨 및 파일시스템

Volumes - 허용되는 볼륨 유형의 목록을 제공한다. 허용 가능한 값은 볼륨을 생성할 때 정의된 볼륨 소스에 따른다. 볼륨 유형의 전체 목록은 볼륨 유형들에서 참고한다. 또한 *를 사용하여 모든 볼륨 유형을 허용할 수 있다.

새 PSP에 허용되는 볼륨의 최소 권장 셋 은 다음과 같다.

• 컨피그맵
• 다운워드API
• emptyDir
• 퍼시스턴트볼륨클레임
• 시크릿
• 프로젝티드(projected)

경고: 파드시큐리티폴리시는 PersistentVolumeClaim이 참조할 수 있는 PersistentVolume 오브젝트의 유형을 제한하지 않으며 hostPath 유형 PersistentVolumes은 읽기-전용 접근 모드를 지원하지 않는다. 신뢰할 수 있는 사용자만 PersistentVolume 오브젝트를 생성할 수 있는 권한을 부여 받아야 한다.

FSGroup - 일부 볼륨에 적용되는 보충 그룹(supplemental group)을 제어한다.

• MustRunAs - 하나 이상의 range를 지정해야 한다. 첫 번째 범위의 최솟값을 기본값으로 사용한다. 모든 범위에 대해 검증한다.
• MayRunAs - 하나 이상의 range를 지정해야 한다. 기본값을 제공하지 않고 FSGroups을 설정하지 않은 상태로 둘 수 있다. FSGroups이 설정된 경우 모든 범위에 대해 유효성을 검사한다.
• RunAsAny - 기본값은 제공되지 않는다. 어떠한 fsGroup ID의 지정도 허용한다.

AllowedHostPaths - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 목록을 지정한다. 빈 목록은 사용되는 호스트 경로에 제한이 없음을 의미한다. 이는 단일 pathPrefix 필드가 있는 오브젝트 목록으로 정의되며, hostPath 볼륨은 허용된 접두사로 시작하는 경로를 마운트할 수 있으며 readOnly 필드는 읽기-전용으로 마운트 되어야 함을 나타낸다. 예를 들면 다음과 같습니다.

 allowedHostPaths:
   # 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만,
   # "/fool", "/etc/foo" 등은 허용하지 않는다.
   # "/foo/../" 는 절대 유효하지 않다.
   - pathPrefix: "/foo"
     readOnly: true # 읽기 전용 마운트만 허용

경고:

호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션 (다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할 수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다.

쓰기 가능한 hostPath 디렉터리 볼륨을 사용하면, 컨테이너가 pathPrefix 외부의 호스트 파일시스템에 대한 통행을 허용하는 방식으로 컨테이너의 파일시스템 쓰기(write)를 허용한다. 쿠버네티스 1.11 이상 버전에서 사용 가능한 readOnly: true는 지정된 pathPrefix에 대한 접근을 효과적으로 제한하기 위해 모든 allowedHostPaths에서 사용해야 한다.

ReadOnlyRootFilesystem - 컨테이너는 읽기-전용 루트 파일시스템(즉, 쓰기 가능한 레이어 없음)으로 실행해야 한다.

FlexVolume 드라이버

flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 목록을 지정한다. 빈 목록 또는 nil은 드라이버에 제한이 없음을 의미한다. volumes 필드에 flexVolume 볼륨 유형이 포함되어 있는지 확인한다. 그렇지 않으면 FlexVolume 드라이버가 허용되지 않는다.

예를 들면 다음과 같다.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: allow-flex-volumes
spec:
  # ... 다른 스펙 필드
  volumes:
    - flexVolume
  allowedFlexVolumes:
    - driver: example/lvm
    - driver: example/cifs

사용자 및 그룹

RunAsUser - 컨테이너를 실행할 사용자 ID를 제어힌다.

• MustRunAs - 하나 이상의 range를 지정해야 한다. 첫 번째 범위의 최솟값을 기본값으로 사용한다. 모든 범위에 대해 검증한다.
• MustRunAsNonRoot - 파드가 0이 아닌 runAsUser로 제출되거나 이미지에 USER 지시문이 정의되어 있어야 한다(숫자 UID 사용). runAsNonRoot 또는 runAsUser 설정을 지정하지 않은 파드는 runAsNonRoot=true를 설정하도록 변경되므로 컨테이너에 0이 아닌 숫자가 정의된 USER 지시문이 필요하다. 기본값은 제공되지 않는다. 이 전략에서는 allowPrivilegeEscalation=false를 설정하는 것이 좋다.
• RunAsAny - 기본값은 제공되지 않는다. 어떠한 runAsUser의 지정도 허용한다.

RunAsGroup - 컨테이너가 실행될 기본 그룹 ID를 제어한다.

• MustRunAs - 하나 이상의 range를 지정해야 한다. 첫 번째 범위의 최솟값을 기본값으로 사용한다. 모든 범위에 대해 검증한다.
• MayRunAs - RunAsGroup을 지정할 필요가 없다. 그러나 RunAsGroup을 지정하면 정의된 범위에 속해야 한다.
• RunAsAny - 기본값은 제공되지 않는다. 어떠한 runAsGroup의 지정도 허용한다.

SupplementalGroups - 컨테이너가 추가할 그룹 ID를 제어한다.

• MustRunAs - 하나 이상의 range를 지정해야 한다. 첫 번째 범위의 최솟값을 기본값으로 사용한다. 모든 범위에 대해 검증한다.
• MayRunAs - 하나 이상의 range를 지정해야 한다. supplementalGroups에 기본값을 제공하지 않고 설정하지 않은 상태로 둘 수 있다. supplementalGroups가 설정된 경우 모든 범위에 대해 유효성을 검증한다.
• RunAsAny - 기본값은 제공되지 않는다. 어떠한 supplementalGroups의 지정도 허용한다.

권한 에스컬레이션

이 옵션은 allowPrivilegeEscalation 컨테이너 옵션을 제어한다. 이 bool은 컨테이너 프로세스에서 no_new_privs 플래그가 설정되는지 여부를 직접 제어한다. 이 플래그는 setuid 바이너리가 유효 사용자 ID를 변경하지 못하게 하고 파일에 추가 기능을 활성화하지 못하게 한다(예: ping 도구 사용을 못하게 함). MustRunAsNonRoot를 효과적으로 강제하려면 이 동작이 필요하다.

AllowPrivilegeEscalation - 사용자가 컨테이너의 보안 컨텍스트를 allowPrivilegeEscalation=true로 설정할 수 있는지 여부를 게이트한다. 이 기본값은 setuid 바이너리를 중단하지 않도록 허용한다. 이를 false로 설정하면 컨테이너의 하위 프로세스가 상위 프로세스보다 더 많은 권한을 얻을 수 없다.

DefaultAllowPrivilegeEscalation - allowPrivilegeEscalation 옵션의 기본값을 설정한다. 이것이 없는 기본 동작은 setuid 바이너리를 중단하지 않도록 권한 에스컬레이션을 허용하는 것이다. 해당 동작이 필요하지 않은 경우 이 필드를 사용하여 기본적으로 허용하지 않도록 설정할 수 있지만 파드는 여전히 allowPrivilegeEscalation을 명시적으로 요청할 수 있다.

기능

리눅스 기능은 전통적으로 슈퍼유저와 관련된 권한을 보다 세밀하게 분류한다. 이러한 기능 중 일부는 권한 에스컬레이션 또는 컨테이너 분류에 사용될 수 있으며 파드시큐리티폴리시에 의해 제한될 수 있다. 리눅스 기능에 대한 자세한 내용은 기능(7)을 참고하길 바란다.

다음 필드는 대문자로 표기된 기능 이름 목록을 CAP_ 접두사 없이 가져온다.

AllowedCapabilities - 컨테이너에 추가될 수 있는 기능의 목록을 제공한다. 기본적인 기능 셋은 암시적으로 허용된다. 비어있는 셋은 기본 셋을 넘어서는 추가 기능이 추가되지 않는 것을 의미한다. *는 모든 기능을 허용하는 데 사용할 수 있다.

RequiredDropCapabilities - 컨테이너에서 삭제해야 하는 기능이다. 이러한 기능은 기본 셋에서 제거되며 추가해서는 안된다. RequiredDropCapabilities에 나열된 기능은 AllowedCapabilities 또는 DefaultAddCapabilities에 포함되지 않아야 한다.

DefaultAddCapabilities - 런타임 기본값 외에 기본적으로 컨테이너에 추가되는 기능이다. 도커 런타임을 사용할 때 기본 기능 목록은 도커 문서를 참고하길 바란다.

SELinux

• MustRunAs - seLinuxOptions을 구성해야 한다. seLinuxOptions을 기본값으로 사용한다. seLinuxOptions에 대해 유효성을 검사한다.
• RunAsAny - 기본값은 제공되지 않는다. 어떠한 seLinuxOptions의 지정도 허용한다.

AllowedProcMountTypes

allowedProcMountTypes는 허용된 ProcMountTypes의 목록이다. 비어 있거나 nil은 DefaultProcMountType만 사용할 수 있음을 나타낸다.

DefaultProcMount는 /proc의 읽기 전용 및 마스킹(masking)된 경로에 컨테이너 런타임 기본값을 사용한다. 대부분의 컨테이너 런타임은 특수 장치나 정보가 실수로 보안에 노출되지 않도록 /proc의 특정 경로를 마스킹한다. 이것은 문자열 Default로 표시된다.

유일하게 다른 ProcMountType은 UnmaskedProcMount로, 컨테이너 런타임의 기본 마스킹 동작을 무시하고 새로 작성된 /proc 컨테이너가 수정없이 그대로 유지되도록 한다. 이 문자열은 Unmasked로 표시된다.

AppArmor

파드시큐리티폴리시의 어노테이션을 통해 제어된다. AppArmor 문서를 참고하길 바란다.

Seccomp

쿠버네티스 v1.19부터 파드나 컨테이너의 securityContext 에서 seccompProfile 필드를 사용하여 seccomp 프로파일 사용을 제어할 수 있다. 이전 버전에서는, 파드에 어노테이션을 추가하여 seccomp를 제어했다. 두 버전에서 동일한 파드시큐리티폴리시를 사용하여 이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다.

seccomp.security.alpha.kubernetes.io/defaultProfileName - 컨테이너에 적용할 기본 seccomp 프로파일을 지정하는 어노테이션이다. 가능한 값은 다음과 같다.

• unconfined - 대안이 제공되지 않으면 Seccomp가 컨테이너 프로세스에 적용되지 않는다(쿠버네티스의 기본값임).
• runtime/default - 기본 컨테이너 런타임 프로파일이 사용된다.
• docker/default - 도커 기본 seccomp 프로파일이 사용된다. 쿠버네티스 1.11 부터 사용 중단(deprecated) 되었다. 대신 runtime/default 사용을 권장한다.
• localhost/<path> - <seccomp_root>/<path>에 있는 노드에서 파일을 프로파일로 지정한다. 여기서 <seccomp_root>는 Kubelet의 --seccomp-profile-root 플래그를 통해 정의된다. --seccomp-profile-root 플래그가 정의되어 있지 않으면, <root-dir> 이 --root-dir 플래그로 지정된 <root-dir>/seccomp 기본 경로가 사용된다.

참고: --seccomp-profile-root 플래그는 쿠버네티스 v1.19부터 더 이상 사용되지 않는다. 사용자는 기본 경로를 사용하는 것이 좋다.

seccomp.security.alpha.kubernetes.io/allowedProfileNames - 파드 seccomp 어노테이션에 허용되는 값을 지정하는 어노테이션. 쉼표로 구분된 허용된 값의 목록으로 지정된다. 가능한 값은 위에 나열된 값과 모든 프로파일을 허용하는 * 이다. 이 주석이 없으면 기본값을 변경할 수 없다.

Sysctl

기본적으로 모든 안전한 sysctls가 허용된다.

• forbiddenSysctls - 특정 sysctls를 제외한다. 목록에서 안전한 것과 안전하지 않은 sysctls의 조합을 금지할 수 있다. 모든 sysctls 설정을 금지하려면 자체적으로 *를 사용한다.
• allowedUnsafeSysctls - forbiddenSysctls에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.

Sysctl 문서를 참고하길 바란다.

다음 내용

• 파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래에서 파드시큐리티폴리시의 미래에 대해 알아본다.

• 폴리시 권장 사항에 대해서는 파드 보안 표준을 참조한다.

• API 세부 정보는 파드 시큐리티 폴리시 레퍼런스 참조한다.

4 - 노드 리소스 매니저

쿠버네티스는 지연 시간에 민감하고 처리량이 많은 워크로드를 지원하기 위해 리소스 매니저 세트를 제공한다. 매니저는 CPU, 장치 및 메모리 (hugepages) 리소스와 같은 특정한 요구 사항으로 구성된 파드를 위해 노드의 리소스 할당을 조정하고 최적화하는 것을 목표로 한다.

주 매니저인 토폴로지 매니저는 정책을 통해 전체 리소스 관리 프로세스를 조정하는 Kubelet 컴포넌트이다.

개별 매니저의 구성은 다음의 문서에 자세히 기술되어 있다.

• CPU 관리 정책
• 장치 매니저
• 메모리 관리 정책