25. Pod Security Policy (PSP)

 

 

Pod Security Policy 

 

 

 

참고) 환경

 

Master Node server

 OS = CentOS 7

 리눅스 커널 버전 : Linux 3.10.0-1062.el7.x86_64

 docker version : 1.13.1

 api verison : 1.26

 

Worker Node server

 OS = CentOS 7

 리눅스 커널 버전 : Linux 3.10.0-1062.el7.x86_64

 docker version : 1.13.1

 api verison : 1.26

 

Kubernetes version

 1.18

 

 

 

 

---

 

 

 

PodSecurityPolicy(PSP) 란?

 

SecurityContext가 Pod와 Container에 적용되는 정책 설정이라면

Pod Security Policy(PSP)는 Kubernetes Cluster 전체에 적용됨.

 

Pod Security Policy는 Kubernetes Cluster 수준의 자원이여서

Pod Security Policy는 생성하는 순간 Kubernetes Cluster 전체에 적용됨.

 

Pod Security Policy를 통해 생성 또는 업데이트 되는 Pod 내부 Container의 

권한에 대한 정책, Volume, 파일 권한 등 설정이 가능.

 

Pod 내 Container가 불필요하게 과도한 권한을 가지지 않도록 주의 해야하는데

이를 PodSecurityPolicy 를 사용해서 권한을 조절함.

 

Kubernetes Cluster는 Default로 Pod Security Policy이 비활성화 되어있음

Pod Security Policy를 활성화 하기 위해서는 

Pod Security Policy Admission Controller를 활성화 해야함

 

Pod의 Spec: 에 설정되는 항목에 대한 권한을 설정함.

 

 

PodSecurityPolicy(PSP)를 사용해 제어가능한 목록

 

참고) SecurityContext 항목과 동일함

Policy 내 설정	설명
privileged	Privileged Container 생성 제어. Privileged container는 Host의 모든 리소스에 접근할 수 있음. 보통 privileged 설정은 false로 하고 아래있는 hostPID, IPC, Network, Ports 옵션으로  권한을 조정함.
hostPID, hostIPC	host pid, ipc namespace 사용 제어 해당 설정을 true로 하면 Container는 Node의 PID, IPC namespace를 사용할 수 있어서 Container에서 실행 중인 프로세스가 Host 즉 Node의 모든 프로세스를 보거나  IPC를 통해 통신할 수 있음.
hostNetwork,	host Network 사용 제어 Pod안에 있는 모든 container들이 Worker Node의 network namespace와  동일한 네트워크를 사용하도록 설정. container 에서 eth0 network interface에 접근 가능.
hostPorts	host Port 사용 제어 min, mx설정으로 사용가능한 hostport 범위를 지정. 특정 Port 번호를 설정하면  Container가 생성된  Node에 해당 Port가 열리게 되고 설정된 Port로 들어오는 요청은 proxying 되지 않으고 곧바로 컨테이너로 직접 전달 됨. 해당 Container가 위치한 Node의 Port만 열림.
volumes	volumes 사용 제어 volume object 다양한 종류 중에서 특정 종류만 사용 가능하도록 설정 가능
allowedHostPaths	호스트 파일 시스템의 사용 제어
allowedFlexVolumes	Flex volume 드라이버 설정
fsGroup	Pod의 volume을 소유한 FSGroup 할당
readOnlyRootFilesystem	읽기 전용 root filesystem 설정
runAsUser, runAsGroup, supplementalGroups	Container의 사용자 및 그룹 ID 지정 Container에서 application, 프로세스를 실행하면 default로 root 계정이 실행하게 되는데 해당 설정을 사용하면  특정 user, Group으로 실행되도록 변경 할 수 있음
allowPrivilegeEscalation, defaultAllowPrivilegeEscalation	Privileged Container 권한 부여 제어
defaultAddCapabilities, allowedCapabilities	Container에서 Linux 기능 사용 여부
requiredDropCapabilities,	Container에서 Linux 기능 사용 못하게 함.
seLinux	컨테이너의 SELinux 프로필
allowedProcMountTypes	컨테이너의 마운트 타입 설정
annotations	컨테이너의 AppArmor, seccomp, sysctl 프로필

 

 

 

Pod Security Policy(PSP)와 Security Context 관계

 

Pod Security Policy(PSP)는 Security Context 보다 상위 보안설정.

 

Security Context는 Pod와 Container에 적용되는 설정이라면

Pod Security Policy 는 클러스터 전체에 적용되기 때문에

 

Pod Security Policy가 부여하지 않은 권한을 Security Context 가 부여할 수 없음

 

예를들어

Pod Security Policy 에서 Privileged 권한을 false로 줬는데

Security Context 에서 true 로 주면

해당 컨테이너는 생성되지 않음

 

 

 

 

---

 

 

 

 

 

 

 

On-Premise 환경에서 Pod Security Policy 활성화

 

Kubernetes Cluster Default 환경에서 

Pod Security Policy를 생성을 해도 

Pod Security Policy 정책이 Cluster에 적용되지 않음

그 이유는 

Kubernetes Cluster는 Default로 Pod Security Policy가 활성화 되어있지 않기 때문임.

즉 지금까지 Kubernetes를 사용한 것은 Pod Security Policy가 비활성화 된 상태에서 사용해 왔었던 것.

Pod Security Policy를 활성화 하기 위해서는 

Pod Security Policy Admission Controller를 활성화 해야함

 

[참고]

Pod Security Policy Admission Controller를 활성화 이후에

Pod Security Policy와 ClusterRole을 생성하면 바로 적용됨

다시 

Pod Security Policy Admission Controller를 비활성화 했다가 활성화 할 필요가 없음.

 

 

[주의]

Pod Security Policy 정책이 없는 상태에서 

Pod Security Policy Admission Controller를 활성화하면

어떠한 Pod도 정상적으로 생성되지 않음.

기존에 존재하고있던 Pod 들은 유지되지만

Update되거나 새로 생성할 시 Pod Security Policy 정책이 없어서

정상적으로 생성되지 않을 수가 있으니

Pod Security Policy Admission Controller를 활성화 하기 전에

반드시 Pod Security Policy 정책이 1개 이상은 존재하고 있는것이 좋음

 

 

Admission Controller 활성화 용도 PSP 생성.

 

어떠한 PSP도 없이 그냥 

Pod Security Policy Admission Controller를 활성화하면

kube-apiserver POD를 재생성 할 때 오류가 발생함. 

(오류에 대한 내용은 글 맨 아래에 자세히 설명함)

 

오류 없이 Pod Security Policy Admission Controller를 활성화하기 위해서는 먼저

모든 권한이 부여된 PSP, Cluster 를 생성해야함.

해당 PSP를 생성하고 PSP admission controller 를 활성화하면

정상적으로 생성됨.

 

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'

 

ClusterRole.yaml

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: privileged-psp rules: - apiGroups: ['policy']   resources: ['podsecuritypolicies']   verbs:     ['use']   resourceNames:   - privileged   ---   apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:   name: privileged-psp-system-authenticated roleRef:   apiGroup: rbac.authorization.k8s.io   kind: ClusterRole   name: privileged-psp subjects:   - kind: Group     apiGroup: rbac.authorization.k8s.io     name: system:authenticated

 

두개의 yaml파일 모두 생성함.

 

[명령어]

kubectl apply -f PSP.yaml

kubectl apply -f ClusterRole.yaml

 

 

 

Pod Security Policy Admission Controller 설정

 

[kube-apiserver.yaml 로 이동]

해당 파일 경로 (default의 경우) : /etc/kubernetes/manifests

 

[kube-apiserver.yaml 에 설정 추가]

(Default 상태)

- --enable-admission-plugins=NodeRestriction

기존에는 

 

(Pod Security Policy 추가)

- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy

 

 

이제 admission Controller에 PSP를 활성화 적용함

 

[ 명령어 ]

kubectl apply -f kube-apiserver.yaml

 

[ 생성 확인 ]

(명령어)

kubectl get podl -n kube-system

kube-apiserver-kube.master.node Pod 가 있는지 확인

 

(명령어)

kubectl describe pod kube-apiserver-kube.master.node -n kube-system

 

설정 중

- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy

이 정상적으로 추가되어있는지 확인.

 

그리고  Annotations 를 확인해보면 

상위에서 생성했던 PSP가 명시되어있는것을 확인할 수 있음

해당 PSP 권한으로 kube-apiserver 가 생성됨을 확인

 

 

 

Admission Controller 활성화 용도 생성했던 PSP를 제거.

 

맨 처음 생성했던 PSP는 모든 권한이 부여된 PSP로

이후 실습과정에서 보안정책을 부여해서 생성할 PSP에 지장을 줄 수 있음.

그래서 생성했던 PSP를 모두 지워주고 진행함.

 

(명령어)

kubectl delete -f PSP.yaml

kubectl delete -f ClusterRole.yaml

 

[참고]

다수의 PSP가 있는 경우

PSP 이름의 알파벳 순서에 따라 우선순위가 적용되어 

Pod 생성 시 PSP가 적용된다는데 

Test 해본결과 그렇게 동작하지 않고

무조건 최초에 생성했던 모든 권한이 부여된

privileged PSP로 정책이 지정됐었음...

 

다수의 PSP는 어떻게 관리하는지에 대해서는

더 리서치를 진행해봐야할것같음.

 

[추가 리서치 결과]

생성된 순서로 우선순위가 적용됨.

가장 최초로 생성된 PSP로 적용.

 

 

---

 

 

 

 

 

Pod Security Policy (PSP) 실습

 

 

목적

아래 그림과 같이 kubernetes 에는 각 종류의 Controller에 해당하는

Service Account 계정들이 존재해서 

해당 Controller로 Pod를 생성할 때 

Controller와 일치하는 Service Account를 사용해서 생성함.

 

진행할 실습에서는 

Controller의 Service Account 중 replicaset-controller 에 

root 권한으로는 Container가 동작할 수 없도록 하고

오직 user 권한으로만 Container가 동작할 수 있도록하는

Pod Security Policy 정책을 적용해서 

결과를 확인하도록 하겠음.

 

 

Pod Security Policy 설정 및 생성

 

[ 예제 psp.yaml ]

privileged container 가 생성되는것을 막고

Container 에서 application 실행 시 무조건 user 권한으로만 실행되도록 설정.

그 이외 권한은 모두 부여함

apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata:   name: iksoon-replicaset-psp spec:   privileged: false  # privileged container를 생성하지 못하게 함   seLinux:     rule: RunAsAny   supplementalGroups:     rule: RunAsAny   runAsUser:     rule: MustRunAsNonRoot  # 오직 user 권한으로만 Container가 동작할 수 있음   fsGroup:     rule: RunAsAny   volumes:   - '*'

 

 

[ PSP 생성 ]

(생성 명령어)

kubectl appy -f psp.yaml

(생성 확인 명령어)

kubectl get podsecuritypolicy

정상적으로 생성된 PSP를 확인할 수 있음

 

 

[결과]

해당 단계 까지가 PSP 를 정의하고 실행을 완료한 상태.

하지만 이 상태에서 Deployment를 통해 root 계정으로 실행되는 Container를 생성해보면

PSP가 적용되지 않고 정상적으로 생성이 됨.

즉 아직 PSP가 실제로 적용되지 않은 상태임.

 

PSP를 적용하기 위해서는 

Kubernetes 인증 부분에서 설명했던 RBAC 의 ClusterRole, ClusterRoleBinding 과

PSP를 연동해야 

실제로 PSP가 적용되기 시작함.

 

ClusterRole 을 통해 PSP를 적용한다는 것을 확인하면

인증의 User 부분을 고려하지 않을 수가 없음.

PSP는 결과적으로 User Account 에도 적용될 수 있고 Service Account에도 적용될 수 있음.

 

하지만 PSP는 kuberentes Cluster 전체에 적용되는 보안정책이기 때문에

주로 직접적으로 Pod를 관리하는 Kubernete Controller 에 적용이 됨.

 

위에서 설명드렸듯 Kubernete Controller는 

각 종류의 Controller에 해당하는 Service Account 계정들이 존재해서 

PSP는 주로 Controller의 SA에 적용이 되어 

Kubernetes Cluster를 관리하게 됨.

 

 

 

PSP ClusterRole,Binding 설정 및 생성

 

[ 예제 clusterRole-PSP.yaml ]

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: iksoon-psp-clusterrole rules: - apiGroups: ['policy']   # psp 정책을 적용하기 위해서는 반드시 이와같이 설정해야함.   resources: ['podsecuritypolicies']    verbs:     ['use']   resourceNames:   - iksoon-replicaset-psp  # 상위에서 생성한 PSP의 name   ---   apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:   name: iksoon-psp-clusterrole-binding roleRef:   apiGroup: rbac.authorization.k8s.io   kind: ClusterRole   name: iksoon-psp-clusterrole subjects:   - kind: ServiceAccount   # kubernetes Controller 의 SA와 연동하기 위해 SA로 설정     name: replicaset-controleer  # replicaset controller 의 SA를 넣어줌     namespace: kube-system

 

[ PSP의 ClusterRole생성 ]

(생성 명령어)

kubectl appy -f clusterRole-PSP.yaml

 

 

[결과]

해당 단계 까지 완료했다면

PSP 생성과 PSP가 ClusterRole 을 통해

Kubernetes Controller의 replicaset 까지 적용이 완료된 상태.

 

 

 

User 권한으로 실행되는 Deployment  생성 결과 확인

 

peksoon/iksoon_tomcat:1.0.6 image에는

iksoon user가 추가되어있고 

UID : 1000

GID : 1000

으로 생성 해놓았음

 

[ 예제 Deployment-User.yaml ]

apiVersion: apps/v1 kind: Deployment metadata:   name: iksoon-deployment   labels:     app: iksoontest spec:   replicas: 1   selector:     matchLabels:       app: iksoon-pod   template:     metadata:       labels:         app: iksoon-pod-tomcat     spec:       securityContext:  # securityContext를 통해 UID 가 1000 (iksoon)으로 실행되게 해놓음         runAsUser: 1000         fsGroup: 1000       containers:       - name: iksoon-tomcat         image: peksoon/iksoon_tomcat:1.0.6         ports:         - containerPort: 8080

 

[ 결과 ]

User 권한으로 실행되게 했을 경우 

Pod 내부 Container 가 정상 실행됨.

 

 

 

 

 

 

Root 권한으로 실행되는 Deployment  생성 결과 확인

 

[ 예제 Deployment-Root.yaml ]

apiVersion: apps/v1 kind: Deployment metadata:   name: iksoon-deployment   labels:     app: iksoontest spec:   replicas: 1   selector:     matchLabels:       app: iksoon-pod   template:     metadata:       labels:         app: iksoon-pod-tomcat     spec:       containers:       - name: iksoon-tomcat         image: peksoon/iksoon_tomcat:1.0.6         ports:         - containerPort: 8080

 

[ 결과 ]

Root 권한으로 실행되게 했을 경우 

Pod 내부 Container 생성에 실패함

 

describe 로 확인을 해보면

Annotations 항목에 적용된 PSP 를 확인할 수 있음

 

Log 를 확인해본 결과

image will run as root 라고 나오며 Error 가 발생.

상위에서 생성한 PSP 정책 에 위반되서 Container 생성이 안됨.

 rule: MustRunAsNonRoot  # 오직 user 권한으로만 Container가 동작할 수 있음

 

 

 

 

---

 

 

 

추가 테스트

 

 

추가로 테스트한 부분

 

Group - system:authenticated 인 PSP (G-PSP)

 

[ replica-set-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'   ---   apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: privileged-psp rules: - apiGroups: ['policy']   resources: ['podsecuritypolicies']   verbs:     ['use']   resourceNames:   - privileged   ---   apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:   name: privileged-psp-system-authenticated roleRef:   apiGroup: rbac.authorization.k8s.io   kind: ClusterRole   name: privileged-psp subjects:   - kind: Group     apiGroup: rbac.authorization.k8s.io     name: system:authenticated

 

 

 

Service Account - replicaset-contoller인 PSP1 (R1-PSP)

 

[ replica-set-psp.yaml ]

apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata:   name: a-iksoon-replicaset-psp spec:   privileged: false  # privileged container를 생성하지 못하게 함   seLinux:     rule: RunAsAny   supplementalGroups:     rule: RunAsAny   runAsUser:     rule: MustRunAsNonRoot  # 오직 user 권한으로만 Container가 동작할 수 있음   fsGroup:     rule: RunAsAny   volumes:   - '*'   ---   apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: a-iksoon-psp-clusterrole rules: - apiGroups: ['policy']   # psp 정책을 적용하기 위해서는 반드시 이와같이 설정해야함.   resources: ['podsecuritypolicies']   verbs:     ['use']   resourceNames:   - a-iksoon-replicaset-psp  # 상위에서 생성한 PSP의 name     ---     apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:   name: a-iksoon-psp-clusterrole-binding roleRef:   apiGroup: rbac.authorization.k8s.io   kind: ClusterRole   name: a-iksoon-psp-clusterrole subjects:   - kind: ServiceAccount   # kubernetes Controller 의 SA와 연동하기 위해 SA로 설정     name: replicaset-controller  # replicaset controller 의 SA를 넣어줌     namespace: kube-system

 

 

 

 

Service Account - replicaset-contoller인 PSP2 (R2-PSP) 

 

R1-PSP 와 정책이 다름 (동일한 SA에 부여되는 PSP가 있을 시 우선순위 확인용)

[ replica-set-psp.yaml ]

apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata:   name: b-iksoon-replicaset-psp spec:   privileged: false  # privileged container를 생성하지 못하게 함   seLinux:     rule: RunAsAny   supplementalGroups:     rule: RunAsAny   runAsUser:     rule: RunAsAny  # 오직 user 권한으로만 Container가 동작할 수 있음   fsGroup:     rule: RunAsAny   volumes:   - '*'   ---   apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: b-iksoon-psp-clusterrole rules: - apiGroups: ['policy']   # psp 정책을 적용하기 위해서는 반드시 이와같이 설정해야함.   resources: ['podsecuritypolicies']   verbs:     ['use']   resourceNames:   - b-iksoon-replicaset-psp  # 상위에서 생성한 PSP의 name     ---     apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:   name: b-iksoon-psp-clusterrole-binding roleRef:   apiGroup: rbac.authorization.k8s.io   kind: ClusterRole   name: b-iksoon-psp-clusterrole subjects:   - kind: ServiceAccount   # kubernetes Controller 의 SA와 연동하기 위해 SA로 설정     name: replicaset-controller  # replicaset controller 의 SA를 넣어줌     namespace: kube-system

 

 

 

 

 

1. ServiceAccount -새로 생성한 SA인  PSP (S1-PSP)

 

[ user1-sa-psp.yaml ]

apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata:   name: 1-test-psp spec:   privileged: false   seLinux:     rule: RunAsAny   supplementalGroups:     rule: RunAsAny   runAsUser:     rule: MustRunAsNonRoot   fsGroup:     rule: RunAsAny   volumes:   - '*'     ---     apiVersion: v1 kind: ServiceAccount metadata:   name: 1-test-sa     ---     apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: 1-test-clusterrole rules: - apiGroups: ['policy']   resources: ['podsecuritypolicies']   verbs:     ['use']   resourceNames:   - 1-test-psp     ---     apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:   name: 1-test-clusterrole-bindings subjects: - kind: ServiceAccount   name: 1-test-sa   namespace: default roleRef:   apiGroup: rbac.authorization.k8s.io   kind: ClusterRole   name: 1-test-clusterrole

 

 

 

 

 

2. ServiceAccount -새로 생성한 SA인  PSP (S2-PSP)

[ user2-sa-psp.yaml ]

apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata:   name: 2-test-psp spec:   privileged: false   seLinux:     rule: RunAsAny   supplementalGroups:     rule: RunAsAny   runAsUser:     rule: MustRunAsNonRoot   fsGroup:     rule: RunAsAny   volumes:   - '*'     ---     apiVersion: v1 kind: ServiceAccount metadata:   name: 2-test-sa     ---     apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: 2-test-clusterrole rules: - apiGroups: ['policy']   resources: ['podsecuritypolicies']   verbs:     ['use']   resourceNames:   - 2-test-psp     ---     apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:   name: 2-test-clusterrole-bindings subjects: - kind: ServiceAccount   name: 2-test-sa   namespace: default roleRef:   apiGroup: rbac.authorization.k8s.io   kind: ClusterRole   name: 2-test-clusterrole

 

위 3개의 PSP를 생성하고 우선순위를 확인 실험

 

G-PSP, R1-PSP, S1-PSP 순서로 생성된 상태.

= 무조건 G-PSP로 Pod 가 생성됨

 

G-PSP,  S1-PSP, S2-PSP 순서로 생성된 상태.

= 무조건 G-PSP로 Pod 가 생성됨

 

S1-PSP, S2-PSP, R-PSP, G-PSP 순서로 생성된 상태.

= 무조건 G-PSP로 Pod 가 생성됨

 

R-PSP, S1-PSP 순서로 생성된 상태.

= Deployment 생성 시 무조건 R-PSP로 Pod 가 생성됨 

= (SA 지정을해서 S1-PSP를 보도록 해도 R-PSP를 바라봄)

 

S1-PSP 생성된 상태.

= Deployment 생성 시 SA1를 지정하지 않으면 Pod 자체가 생성이 안됨 (PSP를 인식하지 못함)

= Deployment 생성 시 SA1를 지정하면 S1-PSP로 Pod 가 생성됨

= pod 생성 시 SA1를 지정하면 S1-PSP로 Pod 가 생성됨

 

R1-PSP 생성된 상태.

= Deployment 생성 시 무조건 R1-PSP로 Pod 가 생성됨

= Pod 생성 시 무조건 R1-PSP로 Pod 가 생성됨  

= (replicaset 에만 설정해서 pod로 생성하면 적용이 안될줄 알았는데 Pod생성 시에도 적용됨)

 

S-PSP(1), S-PSP(2) 순서로 생성된 상태.

= Deployment 생성 시 SA1를  지정하면 S1-PSP 로 생성

= Deployment 생성 시 SA2를  지정하면 S2-PSP 로 생성

 

R1-PSP,  S-PSP(1), S-PSP(2) 순서로 생성된 상태.

= Deployment 생성 시 SA1를  지정하면 S1-PSP 로 생성

= Deployment 생성 시 SA2를  지정하면 S2-PSP 로 생성

= Deployment 생성 시 R1-PSP 로 생성

 

S-PSP(1), S-PSP(2), R1-PSP,  순서로 생성된 상태.

= Deployment 생성 시 SA1를  지정하면 S1-PSP 로 생성

= Deployment 생성 시 SA2를  지정하면 S2-PSP 로 생성

= Deployment 생성 시 R1-PSP 로 생성

 

 

 R1-PSP,  R2-PSP 순서로 생성된 상태.

= Deployment 생성 시 R1-PSP 로 생성

 

 R2-PSP,  R1-PSP 순서로 생성된 상태.

= Deployment 생성 시 R2-PSP 로 생성

 

 

결과

= Group 의 system:authenticated 에 PSP 우선순위가 가장높음.

= 동일한 SA에 다수의 PSP가 있을 시 우선순위 = 가장 먼저 생성된 PSP.

= replicaset Controller PSP 보다 SA 지정 PSP 가 우선순위가 높음.

= replicaset Controller 에 PSP를 부여해도 Pod만 생성할때도 적용됨.

 

 

 

---

 

 

 

오류 참고

 

오류 : unable to validate against any pod security policy

 

[상황]

kube-apiserver.yaml에서 

- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy

설정을 하고

바로 kubectl apply -f kube-apiserver.yaml

명령으로 적용하게 되면

아래와 같이 오류가 발생함하고

kube-apiserver Pod 가 없음

 

[오류명]

Error from server (Forbidden): error when creating "kube-apiserver.yaml": pods "kube-apiserver" is forbidden: unable to validate against any pod security policy: [spec.volumes[0].hostPath.pathPrefix: Invalid value: "/etc/ssl/certs": is not allowed to be used spec.volumes[1].hostPath.pathPrefix: Invalid value: "/etc/pki": is not allowed to be used spec.volumes[2].hostPath.pathPrefix: Invalid value: "/etc/kubernetes/pki": is not allowed to be used]

 

[원인]

Pod Security Policy 활성화를 한 후

kube-apiserver Pod 를 생성할려고 하는데

kube-apiserver Pod 생성에 필요한 권한이 없어서 해당 Error가 발생함.

주로 Pod Security Policy가 하나도 없는 상황에서

활성화를 시도하면 많이 발생함.

 

[해결책]

Pod Security Policy 활성화 하기 전에

Pod Security Polic 리소스를 미리 만들어놓아야하는데

kube-apiserver Pod를 생성할때 필요한 권한을

Pod Security Policy 에 명시해야함.

 

실습 중에 해당 오류를 많이 마주했는데

해당 오류가 발생해서 kube-apiserver가 보이지 않더라도

docker ps 로 확인해보면 kube-apiserver가 정상적으로 동작 중으로 나옴.

그리고 cluster에서

Pod Security Policy 정책에 따라 pod도 정상적으로 생성됨.

 

 

 

 

 

---

제 글을 복사할 시 출처를 명시해주세요.
글에 오타, 오류가 있다면 댓글로 알려주세요! 바로 수정하겠습니다!

---

 

 

 

 

 

참고

[Pod Security Policy]

https://banzaicloud.com/blog/pod-security-policy/

https://kubernetes.io/docs/concepts/policy/pod-security-policy/

https://bcho.tistory.com/1276?category=731548

https://msazure.club/podsecuritypolicy-explained-by-examples/

https://yogae.github.io/kubernetes/2019/06/03/kubernetes_network_security.html

 

[On-Premise 환경에서 Pod Security Policy 활성화]

https://stackoverflow.com/questions/59054407/how-to-enable-admission-controller-plugin-on-k8s-where-api-server-is-deployed-as

https://capstonec.com/2020/04/22/hands-on-with-kubernetes-pod-security-policies/?doing_wp_cron=1598488842.8478059768676757812500