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 활성화]
'Kubernetes > Kubernetes 이론' 카테고리의 다른 글
| Mutating Admission Controller (0) | 2020.11.05 |
|---|---|
| Admission Controller (0) | 2020.11.05 |
| Security Context (0) | 2020.09.20 |
| Privileged Container (0) | 2020.09.20 |
| Kubernetes Private Registry image 사용법 (0) | 2020.09.20 |