보안

• 1: 클라우드 네이티브 보안 개요
• 2: 파드 시큐리티 스탠다드
• 3: 파드 시큐리티 폴리시
• 4: 윈도우 노드에서의 보안
• 5: 쿠버네티스 API 접근 제어하기
• 6: 역할 기반 접근 제어 (RBAC) 모범 사례

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

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

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

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

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

클라우드

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

클라우드 공급자 보안

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

인프라스트럭처 보안

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

클러스터

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

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

클러스터의 컴포넌트

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

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

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

컨테이너

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

코드

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

코드 보안

다음 내용

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

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

2 - 파드 시큐리티 스탠다드

파드 시큐리티 스탠다드에서는 보안 범위를 넓게 다루기 위해 세 가지 정책을 정의한다. 이러한 정책은 점증적이며 매우 허용적인 것부터 매우 제한적인 것까지 있다. 이 가이드는 각 정책의 요구사항을 간략히 설명한다.

프로필 세부사항

특권(Privileged)

특권 정책은 의도적으로 열려있으며 전적으로 제한이 없다. 이러한 종류의 정책은 권한이 있고 신뢰할 수 있는 사용자가 관리하는 시스템 및 인프라 수준의 워크로드를 대상으로 한다.

특권 정책은 제한 사항이 없는 것으로 정의한다. 기본으로 허용하는 메커니즘(예를 들면, gatekeeper)은 당연히 특권 정책일 수 있다. 반대로, 기본적으로 거부하는 메커니즘(예를 들면, 파드 시큐리티 폴리시)의 경우 특권 정책은 모든 제한 사항을 비활성화해야 한다.

기본(Baseline)

기본 정책은 알려진 권한 상승을 방지하면서 일반적인 컨테이너 워크로드에 대해 정책 채택을 쉽게 하는 것을 목표로 한다. 이 정책은 일반적인(non-critical) 애플리케이션의 운영자 및 개발자를 대상으로 한다. 아래 명시한 제어 방식은 다음과 같이 강행되거나 금지되어야 한다.

제한(Restricted)

제한 정책은 일부 호환성을 희생하면서 현재 사용되고 있는 파드 하드닝 모범 사례 시행하는 것을 목표로 한다. 보안이 중요한 애플리케이션의 운영자 및 개발자는 물론 신뢰도가 낮은 사용자도 대상으로 한다. 아래에 나열된 제어 방식은 강제되거나 금지되어야 한다.

정책 초기화

정책 초기화에서의 디커플링(Decoupling) 정책 정의는, 내재되어 있는 시행 메커니즘과 별개로 클러스터 사이의 공통된 이해와 일관된 정책 언어 사용을 가능하게끔 한다.

메커니즘이 발달함에 따라, 아래와 같이 정책별로 정의가 될 것이다. 개별 정책에 대한 시행 방식은 여기서 정의하고 있지 않는다.

파드 시큐리티 어드미션 컨트롤러

• 특권 네임스페이스
• 기본 네임스페이스
• 제한 네임스페이스

대안

쿠버네티스 환경에서 정책을 시행하기 위한 대안이 개발되고 있으며 다음은 몇 가지 예시이다.

• Kubewarden
• Kyverno
• OPA Gatekeeper

파드 OS 필드

쿠버네티스에서는 리눅스 또는 윈도우를 실행하는 노드를 사용할 수 있다. 하나의 클러스터에 두 종류의 노드를 혼합하여 사용할 수 있다. 윈도우 환경 쿠버네티스는 리눅스 기반 워크로드와 비교하였을 때 몇 가지 제한사항 및 차별점이 있다. 구체적으로 말하자면, 대부분의 파드 securityContext 필드는 윈도우 환경에서 효과가 없다.

제한 파드의 시큐리티 스탠다드 변화

쿠버네티스 v1.25에서 나타난 또 다른 중요 변화는, 제한 파드 시큐리티가 pod.spec.os.name 필드를 사용하도록 업데이트 되었다는 것이다. 특정 OS에 특화된 일부 정책은 OS 이름에 근거하여 다른 OS에 대해서는 완화될 수 있다

특정 OS 정책 제어

spec.os.name의 값이 windows가 아닐 시에만 다음 제어 항목에 대한 제한 사항이 요구된다.

• 권한 상승
• Seccomp
• Linux 기능

FAQ

왜 특권 프로필과 기본 프로필 사이의 프로필은 없는 것인가?

여기서 정의된 세 가지 프로필은 가장 높은 보안에서(제한 프로필) 가장 낮은 보안까지(특권 프로필) 명백한 선형 관계를 가지며 넓은 범위의 워크로드를 다룬다. 기본 정책을 넘는 요청 권한은 일반적으로 애플리케이션 전용에 속하므로 이러한 틈새시장에 대해서는 표준 프로필을 제공하지 않는다. 이 경우에는 항상 특권 프로필을 사용해야 한다는 주장은 아니지만, 해당 영역의 정책은 케이스 별로 정의되어야 한다는 것이다.

이외 프로필이 분명히 필요하다면 SIG Auth는 향후에 이러한 입장을 재고할 수 있다.

시큐리티 컨텍스트와 시큐리티 프로필의 차이점은 무엇인가?

시큐리티 컨텍스트는 파드 및 컨테이너를 런타임에 설정한다. 시큐리티 컨텍스트는 파드 매니페스트 내 파드 및 컨테이너 명세의 일부로 정의되고 컨테이너 런타임에 파라미터로 제공한다.

시큐리티 프로필은 컨트롤 플레인 메커니즘으로, 시큐리티 컨텍스트의 상세 설정을 비롯하여 시큐리티 컨텍스트 외부의 다른 관련된 파라미터도 적용한다. 2021년 7월부로, 파드 시큐리티 폴리시는 내장된 파드 시큐리티 어드미션 컨트롤러에 의해 대체되어 사용이 중단되었다.

샌드박스 파드는 어떠한가?

현재로서는, 파드가 샌드박스 특성을 가지는지 제어할 수 있는 API 표준이 존재하지 않는다. 샌드박스 파드는 샌드박스 런타임(예를 들면, gVisor 혹은 Kata 컨테이너)을 통해 식별할 수 있지만, 샌드박스 런타임이 무엇인지에 대한 표준 정의는 없는 상태이다.

샌드박스 워크로드가 필요로하는 보호물은 다른 워크로드와 다를 수 있다. 예를 들어, 내재된 커널과 분리된 워크로드에서는 제한된 특수 권한의 필요성이 적어진다. 이는 높아진 권한을 요구하는 워크로드가 분리될 수 있도록 허용한다.

추가적으로, 샌드박스 방식에 따라 샌드박스 워크로드에 대한 보호가 달라진다. 이와 같은 경우에는, 하나의 프로필만을 모든 샌드박스 워크로드에 대해 권장할 수 없다.

3 - 파드 시큐리티 폴리시

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

파드 시큐리티 폴리시란?

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. 파드를 기본값으로 설정하거나 변경해야 하는 경우, 파드를 허용할 첫 번째 파드시큐리티폴리시 (이름순)가 선택된다.

파드시큐리티폴리시에 대해 파드의 유효성이 검증되면, 파드시큐리티폴리시의 이름을 어노테이션 값으로 사용하는 [kubernetes.io/psp 어노테이션]이 파드에 추가된다.

예제

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

설정

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

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 https://k8s.io/examples/policy/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 get pod pause -o yaml | grep kubernetes.io/psp

결과는 다음과 같다:

kubernetes.io/psp: example

그러나 특권있는 파드를 만들려는 시도는 여전히 거부되어야 한다.

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:
    # docker/default 는 seccomp를 위한 프로파일을 나타내지만, 특별히 도커 런타임에 묶여 있는 것은 아니다.
    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)

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 # 읽기 전용 마운트만 허용

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

Sysctl

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

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

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

다음 내용

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

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

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

4 - 윈도우 노드에서의 보안

이 페이지에서는 윈도우 운영 체제에서의 보안 고려 사항 및 추천 사례에 대해 기술한다.

노드의 시크릿 데이터 보호

윈도우에서는 시크릿 데이터가 노드의 로컬 스토리지에 평문으로 기록된다(리눅스는 tmpfs 또는 인메모리 파일시스템에 기록). 클러스터 운영자로서, 다음 2 가지의 추가 사항을 고려해야 한다.

1. 파일 ACL을 사용하여 시크릿의 파일 위치를 보호한다.
2. BitLocker를 사용하여 볼륨 수준의 암호화를 적용한다.

컨테이너 사용자

윈도우 파드 또는 컨테이너에 RunAsUsername을 설정하여 해당 컨테이너 프로세스를 실행할 사용자를 지정할 수 있다. 이는 RunAsUser와 대략적으로 동등하다.

윈도우 컨테이너는 ContainerUser와 ContainerAdministrator라는 기본 사용자 계정을 2개 제공한다. 이 두 사용자 계정이 어떻게 다른지는 마이크로소프트의 안전한 윈도우 컨테이너 문서 내의 언제 ContainerAdmin 및 ContainerUser 사용자 계정을 사용해야 하는가를 참고한다.

컨테이너 빌드 과정에서 컨테이너 이미지에 로컬 사용자를 추가할 수 있다.

그룹 관리 서비스 어카운트를 활용하여 윈도우 컨테이너를 Active Directory 사용자로 실행할 수도 있다.

파드-수준 보안 격리

리눅스 특유의 파드 보안 컨텍스트 메커니즘(예: SELinux, AppArmor, Seccomp, 또는 커스텀 POSIX 기능)은 윈도우 노드에서 지원되지 않는다.

특권을 가진(Privileged) 컨테이너는 윈도우에서 지원되지 않는다. 대신, 리눅스에서 권한 있는 컨테이너가 할 수 있는 작업 중 많은 부분을 윈도우에서 수행하기 위해 HostProcess 컨테이너를 사용할 수 있다.

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

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

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

전송 보안

기본적으로 쿠버네티스 API 서버는 TLS에 의해 보호되는 첫번째 non-localhost 네트워크 인터페이스의 6443번 포트에서 수신을 대기한다. 일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다. 포트번호는 --secure-port 플래그를 통해, 수신 대기 IP 주소는 --bind-address 플래그를 통해 변경될 수 있다.

API 서버는 인증서를 제시한다. 이러한 인증서는 사설 인증 기관(CA)에 기반하여 서명되거나, 혹은 공인 CA와 연결된 공개키 인프라스트럭처에 기반한다. 인증서와 그에 해당하는 개인키는 각각 --tls-cert-file과 --tls-private-key-file 플래그를 통해 지정한다.

만약 클러스터가 사설 인증 기관을 사용한다면, 해당 CA 인증서를 복사하여 클라이언트의 ~/.kube/config 안에 구성함으로써 연결을 신뢰하고 누군가 중간에 가로채지 않았음을 보장해야 한다.

클라이언트는 이 단계에서 TLS 클라이언트 인증서를 제시할 수 있다.

인증

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

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

인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰, 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단계)된다.

감사(Auditing)

쿠버네티스 감사는 클러스터에서 발생하는 일들의 순서를 문서로 기록하여, 보안과 관련되어 있고 시간 순서로 정리된 기록을 제공한다. 클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션, 그리고 컨트롤 플레인 자신이 생성한 활동을 감사한다.

더 많은 정보는 감사를 참고한다.

다음 내용

인증 및 인가 그리고 API 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다.

• 인증하기
  • 부트스트랩 토큰(bootstrap token)으로 인증하기
• 어드미션 컨트롤러(admission controller)
  • 동적 어드미션(admission) 제어
• 인가
  • 역할 기반 접근 제어(role based access control)
  • 속성 기반 접근 제어(attribute based access control)
  • 노드 인가
  • 웹훅(webhook) 인가
• 인증서 서명 요청(Certificate Signing Request)
  • CSR 승인 및 인증서 서명 포함하기
• 서비스 어카운트
  • 개발자 가이드
  • 운영

또한, 다음 사항을 익힐 수 있다.

• 파드가 API 크리덴셜(credential)을 얻기 위해 시크릿(Secret) 을 사용하는 방법.

6 - 역할 기반 접근 제어 (RBAC) 모범 사례

쿠버네티스 RBAC는 클러스터 사용자 및 워크로드가 자신의 역할을 수행하기 위해 필요한 자원에 대해서만 접근 권한을 가지도록 보장하는 핵심 보안 제어 방식이다. 클러스터 관리자가 클러스터 사용자 권한을 설정할 시에는, 보안 사고로 이어지는 과도한 접근 권한 부여의 위험을 줄이기 위해 권한 에스컬레이션 발생 가능성에 대해 이해하는 것이 중요하다.

여기서 제공하는 모범 사례는 RBAC 문서 와 함께 읽는 것을 권장한다.

보편적인 모범 사례

최소 권한

이상적으로는, 최소의 RBAC 권한만이 사용자 및 서비스 어카운트에 부여되어야 한다. 작업에 명시적으로 필요한 권한만 사용되어야 한다. 각 클러스터마다 경우가 다르겠지만, 여기서 적용해 볼 수 있는 보편적 규칙은 다음과 같다.

• 권한은 가능하면 네임스페이스 레벨에서 부여한다. 클러스터롤바인딩 대신 롤바인딩을 사용하여 특정 네임스페이스 내에서만 사용자에게 권한을 부여한다.
• 와일드카드(wildcard)를 사용한 권한 지정을 할 시에는, 특히 모든 리소스에 대해서는 가능하면 지양한다. 쿠버네티스는 확장성을 지니는 시스템이기 때문에, 와일드카드를 이용한 권한 지정은 현재 클러스터에 있는 모든 오브젝트 타입뿐만 아니라 추후에 생성될 오브젝트 타입에 대해서도 권한을 부여하게 된다.
• 운영자는 cluster-admin 계정이 필수로 요구되지 않을시에는 사용을 지양한다. 적은 권한을 가진 계정과 가장 (impersonation) 권한을 혼합하여 사용하면 클러스터 자원을 실수로 수정하는 일을 방지할 수 있다.
• system:masters 그룹에 사용자 추가를 지양한다. 해당 그룹의 멤버는 누구나 모든 RBAC 권한 체크를 우회할 수 있으며 롤바인딩과 클러스터 롤바인딩을 통한 권한 회수가 불가능한 슈퍼유저 (superuser) 권한을 가지게 된다. 추가적으로 클러스터가 권한 웹훅을 사용할 시에는, 그룹의 멤버가 해당 웹훅도 우회할 수 있다. (그룹의 멤버인 사용자가 전송하는 요청은 웹훅에 전달되지 않는다.)

특권 토큰 분배 최소화

이상적인 상황에서는, 강력한 권한이 부여된 서비스 어카운트를 파드에게 지정해서는 안된다. (예를 들어, 권한 에스컬레이션 위험에 명시된 모든 권한) 워크로드가 강력한 권한을 요구하는 상황에서는 다음과 같은 사례를 고려해 보자.

• 강력한 권한을 가진 파드를 실행하는 노드의 수를 제한한다. 컨테이너 이스케이프의 영향 범위를 최소화하기 위해, 실행되고 있는 모든 데몬셋은 최소의 권한만을 가지도록 한다.
• 강력한 권한을 가진 파드를 신뢰되지 못하거나 외부로 노출된 파드와 함께 실행하는 것을 지양한다. 신뢰되지 못하거나 신뢰성이 적은 파드와 함께 실행되는 것을 방지하기 위해 테인트와 톨러레이션, 노드 어피니티, 혹은 파드 안티-어피니티를 사용해 보는 것도 고려해 보자. 신뢰성이 적은 파드가 제한된 파드 시큐리티 스탠다드에 부합하지 않을 시에는 더욱 조심해야 한다.

하드닝 (Hardening)

모든 클러스터에서 요구되지 않더라도, 쿠버네티스에서는 기본으로 제공하는 권한이 있다. 기본으로 부여되는 RBAC 권리에 대한 검토를 통해 보안 하드닝을 할 수 있다. 보편적으로는 system: 계정에 부여되는 권한을 수정하는 것은 지양한다. 클러스터 권한을 하드닝할 수 있는 방법은 다음과 같다.

• system:unauthenticated 그룹의 바인딩은 누구에게나 네트워크 레벨에서 API 서버와 통신할 수 있는 권한을 부여하므로, 바인딩을 검토해 보고 가능하면 제거한다.
• automountServiceAccountToken: false를 설정함으로써, 서비스 어카운트 토큰의 자동 마운트 사용을 지양한다. 더 자세한 내용은 기본 서비스 어카운트 토큰 사용법을 참고한다. 파드에서 위와 같은 설정을 하게 된다면, 서비스 어카운트 설정을 덮어쓰게 되며 서비스 어카운트 토큰을 요구하는 워크로드는 여전히 마운트가 가능하다.

주기적 검토

중복된 항목 및 권한 에스컬레이션에 대비하여, 쿠버네티스 RBAC 설정을 주기적으로 검토하는 일은 중요하다. 만일 공격자가 삭제된 사용자와 같은 이름으로 사용자 계정을 생성할 수 있다면, 삭제된 사용자의 모든 권한, 특히 해당 사용자에게 부여되었던 권한까지도 자동으로 상속받을 수 있게 된다.

쿠버네티스 RBAC - 권한 에스컬레이션 위험

쿠버네티스 RBAC 중, 부여받을 시 사용자 또는 서비스 어카운트가 권한 에스컬레이션을 통해 클러스터 밖의 시스템까지 영향을 미칠 수 있게끔 하는 권한이 몇 가지 존재한다.

해당 섹션은 클러스터 운영자가 실수로 클러스터에 의도되지 않은 접근 권한을 부여하지 않도록 하기 위해 신경 써야 할 부분에 대한 시야를 제공하는 것이 목적이다.

시크릿 나열

시크릿에 대해 get 권한을 부여하는 행위는 사용자에게 해당 내용에 대한 열람을 허용하는 일이라는 것은 명확히 알려져 있다. list 및 watch 권한 또한 사용자가 시크릿의 내용을 열람할 수 있는 권한을 부여한다는 것을 알고 지나가는 것이 중요하다. 예를 들어 리스트 응답이 반환되면 (예를 들어, kubectl get secrets -A -o yaml을 통해), 해당 응답에는 모든 시크릿의 내용이 포함되어 있다.

워크로드 생성

워크로드(파드 혹은 파드를 관리하는 워크로드 리소스)를 생성할 수 있는 사용자는 파드 시큐리티 스탠다드에 기반한 제한 사항이 없을 시에는 해당 노드에 대한 접근 권한을 부여받을 수 있다.

특권 파드 실행 권한을 가지는 사용자는 해당 노드에 대한 권한을 부여받을 수 있으며, 더 나아가 권한을 상승시킬 수 있는 가능성도 존재한다. 특정 사용자 혹은, 적절히 안정 및 격리 된 파드를 생성할 수 있는 자격을 가진 다른 주체를 완전히 신뢰하지 못하는 상황이라면, 베이스라인 혹은 제한된 파드 시큐리티 스탠다드를 사용해야 한다. 이는 파드 시큐리티 어드미션 또는 다른 (서드 파티) 매커니즘을 통해 시행할 수 있다.

사용자의 특권을 가진 파드 생성 자격을 제한하기 위해, 현재는 사용이 중지 된 파드시큐리티폴리시 매커니즘도 사용할 수 있다. (주의 - 파드시큐리티폴리시는 1.25 버전 이후로 중지될 예정이다.)

사용자가 네임스페이스 내에서 워크로드를 생성하면, 해당 네임스페이스에 위치한 시크릿에 대한 간접적 접근 권한을 부여 받게 된다. 사용자가 kube-system 또는 유사한 특권을 가진 네임스페이스에서 파드를 생성하게 되면, RBAC를 통해 직접적으로는 접근 권한을 가지지 못할 시크릿에 대한 권한도 부여받게 된다.

퍼시스턴트 볼륨 생성

파드시큐리티폴리시 문서에서도 언급이 되었듯이, 퍼시스턴트볼륨 생성 권한은 해당 호스트에 대한 권한 에스컬레이션으로 이어질 수 있다. 퍼시스턴트 스토리지에 대한 권한이 필요할 시에는 신뢰 가능한 관리자를 통해 퍼시스턴트볼륨을 생성하고, 제한된 권한을 가진 사용자는 퍼시스턴트볼륨클레임을 통해 해당 스토리지에 접근하는 것이 바람직하다.

노드의 proxy 하위 리소스에 대한 접근

노드 오브젝트의 하위 리소스인 프록시에 대한 접근 권한을 가지는 사용자는 Kubelet API에 대한 권한도 가지며, 이는 권한을 가지고 있는 노드에 위치한 모든 파드에서 명령어 실행 권한이 주어짐을 의미한다. 이러한 접근 권한을 통해 감시 로깅 및 어드미션 컨트롤에 대한 우회가 가능해짐으로, 해당 리소스에 대한 권한을 부여할 시에는 주의가 필요하다.

에스컬레이트 동사

사용자가 자신이 보유한 권한보다 더 많은 권한을 가진 클러스터롤을 생성하고자 할때, RBAC 시스템이 이를 막는 것이 보편적이다. 이와 관련하여, escalate 동사가 예외에 해당한다. RBAC 문서에서도 언급이 되었듯이, 해당 권한을 가진 사용자는 권한 에스컬레이션을 할 수 있다.

바인드 동사

해당 권한을 사용자에게 부여함으로써 escalate 동사와 유사하게 권한 에스컬레이션에 대한 쿠버네티스에 내장된 보호 기능을 우회할 수 있게 되며, 이는 사용자가 부여받지 않은 권한을 가진 롤에 대한 바인딩을 생성할 수 있게끔 한다.

가장 (Impersonate) 동사

사용자는 해당 동사를 통해 클러스터 내에서 다른 사용자를 가장하여 권한을 부여받을 수 있게 된다. 가장된 계정을 통해 필요 이상의 권한이 부여되지 않도록 해당 동사 부여시 주의를 기울일 필요가 있다.

CSR 및 증명서 발급

CSR API를 통해 CSR에 대한 create 권한 및 certificatesigningrequests/approval에 대한 update 권한을 가진 사용자가, 서명자가 kubernetes.io/kube-apiserver-client인 새로운 클라이언트 증명서를 생성할 수 있게 되며 이를 통해 사용자는 클러스터를 인증할 수 있게 된다. 해당 클라이언트 증명서는 임의의 이름을 가지게 되며, 이에 중복된 쿠버네티스 시스템 구성 요소도 포함 된다. 이는 권한 에스컬레이션 발생 가능성을 열어두게 된다.

토큰 요청

serviceaccounts/token에 대해 create 권한을 가지는 사용자는 기존의 서비스 어카운트에 토큰을 발급할 수 있는 토큰리퀘스트를 생성할 수 있다.

컨트롤 어드미션 웹훅

validatingwebhookconfigurations 혹은 mutatingwebhookconfigurations에 대한 제어권을 가지는 사용자는 클러스터가 승인한 모든 오브젝트를 열람할 수 있는 웹훅을 제어할 수 있으며, 변화하는 웹훅의 경우에는 승인된 오브젝트를 변화시킬 수도 있다.

쿠버네티스 RBAC - 서비스 거부 위험

객체 생성 서비스 거부

클러스터 내 오브젝트 생성 권한을 가지는 사용자는 쿠버네티스가 사용하는 etcd는 OOM 공격에 취약에서 언급 되었듯이, 서비스 거부 현상을 초래할 정도 규모의 오브젝트를 생성할 수 있다. 다중 테넌트 클러스터에서 신뢰되지 못하거나 신뢰성이 적은 사용자에게 시스템에 대해 제한된 권한이 부여된다면 해당 현상이 나타날 수 있다.

해당 문제의 완화 방안 중 하나로는, 리소스 쿼터를 사용하여 생성할 수 있는 오브젝트의 수량을 제한하는 방법이 있다.

다음 내용

• RBAC에 대한 추가적인 정보를 얻기 위해서는 RBAC 문서를 참고한다.