22. 3. Kubernetesにおけるポリシー制御
deprecate PSP in 1.21, but leave removal at 1.25 #97171
https://github.com/kubernetes/kubernetes/pull/97171
なぜ Pod Security Policy (PSP) は Kubernetes 1.21 から非推奨になったのか？
https://qiita.com/kiyoshim55/items/0262d42b57320bea2d00
Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller
https://kubernetes.io/docs/tasks/con
fi
gure-pod-container/migrate-from-psp/
Why is PodSecurityPolicy going away?
In the years since PodSecurityPolicy was
fi
rst introduced, we have realized that PSP has some serious
usability problems that canʼt be addressed without making breaking changes.
PodSecurityPolicy Deprecation: Past, Present, and Future
https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/
(参考) Pod Security Policy廃止に関する情報
30. 4.1. Pod Security Admission - Namespaceに対するポリシー適用 -
# kubectl apply -f exploit-pod.yaml -n namespace-a
Error from server (Forbidden): error when creating "exploit-pod.yaml": pods "exploit-pod" is forbidden: violates
PodSecurity "baseline:v1.25": host namespaces (hostPID=true), privileged (container "ubuntu" must not set
securityContext.privileged=true)
# kubectl get po -n namespace-a
No resources found in namespace-a namespace.
# kubectl apply -f exploit-pod.yaml -n namespace-b
pod/exploit-pod created
# kubectl get po -n namespace-b
NAME READY STATUS RESTARTS AGE
exploit-pod 1/1 Running 0 7s
exploit-pod.yaml を各Namespaceに適用してみると、それぞれ以下のような結果になります。
namespace-bでは通常通りPodのデプロイが成功しているのに対し、ポリシーを適用したnamespace-aではエラーが表示され
Podのデプロイに失敗していることが分かります。
namespace-a(ポリシーが適用されている)
namespace-b(ポリシーが適用されていない)
Baselineポリシーに違反しているためPodのデプロイが拒否された
[Pod Security Admission]
enforce: baseline
audit: restricted
warn: restricted
33. 4.1. Pod Security Admission - Namespaceに対するポリシー適用 -
baseline-pod.yamlをnamespace-aに適用し、Podをデプロイしてみます。
すると警告メッセージが表示されつつ、Podのデプロイは成功していることが確認できます。
このようにPod Security Admissionではポリシーに準拠していないPodのデプロイを防止したり、
ポリシー違反による警告文言の表示やAudit Logへの記録を行うことができます。
# kubectl apply -f baseline-pod.yaml -n namespace-a
Warning: would violate PodSecurity "restricted:v1.25": allowPrivilegeEscalation != false (container "ubuntu" must set
securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "ubuntu" must set
securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "ubuntu" must set
securityContext.runAsNonRoot=true), seccompPro
fi
le (pod or container "ubuntu" must set
securityContext.seccompPro
fi
le.type to "RuntimeDefault" or "Localhost")
pod/baseline-pod created
# kubectl get po -n namespace-a
NAME READY STATUS RESTARTS AGE
baseline-pod 1/1 Running 0 35s
Restrictedポリシーに違反していることが警告として表示され、
Podがデプロイされた
[Pod Security Admission]
enforce: baseline
audit: restricted
warn: restricted
41. 4.3. Pod Security Admission - デフォルトポリシーの適用 -
Kubernetesクラスターのデフォルトポリシーやポリシー適用除外対象はAdmissionCon
fi
gurationとして定義することが
できます。
※ここで除外設定した対象についてはNamespaceにlabelsを付与してもポリシーが適用されなくなる
apiVersion: apiserver.con
fi
g.k8s.io/v1
kind: AdmissionCon
fi
guration
plugins:
- name: PodSecurity
con
fi
guration:
apiVersion: pod-security.admission.con
fi
g.k8s.io/v1
kind: PodSecurityCon
fi
guration
defaults: # デフォルトポリシーを定義
enforce: "baseline" # Baselineポリシーに違反するPodのデプロイを禁止
enforce-version: "v1.25"
audit: "restricted" # Restrictedポリシーに違反するPodのデプロイを検知した場合はAudit Logに記録(違反してもPodはデプロイされる)
audit-version: "v1.25"
warn: "restricted" # Restrictedポリシーに違反するPodのデプロイを検知した場合は警告を表示(違反してもPodはデプロイされる)
warn-version: "v1.25
exemptions: # ポリシー適用除外対象
usernames: [] # ポリシーを適用しないユーザーを指定する
runtimeClasses: [] # ポリシーを適用しないRuntimeClassを指定する
namespaces: # ポリシーを適用しないNamespaceを指定する
- kube-system
- namespace-c
pod-security.yaml
42. 4.3. Pod Security Admission - デフォルトポリシーの適用 -
A Guide to Kubernetes Admission Controllers
https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/
(参考) KubernetesにおけるValidation/Mutation
一般的にKubernetesmではAPI Serverへのリクエスト時にAdmission Controllerと呼ばれる仕組みを用いてValidation/Mutationを
実現します。
Pod Security AdmissionについてもAdmission Controllerに含まれるAdmission Pluginと言う仕組みを用いて実現されています。
kube-apiserverの処理フロー
43. 4.3. Pod Security Admission - デフォルトポリシーの適用 -
apiVersion: v1
kind: Pod
metadata:
・・・
name: kube-apiserver
namespace: kube-system
spec:
containers:
- command:
- kube-apiserver
・・・
- --admission-control-con
fi
g-
fi
le=/etc/kubernetes/policies/pod-security.yaml
・・・
volumeMounts:
- mountPath: /etc/kubernetes/policies
name: policies
readOnly: true
・・・
volumes:
- name: policies
hostPath:
path: /etc/kubernetes/policies
type: DirectoryOrCreate
・・・
/etc/kubernetes/manifests/kube-apiserver.yaml (kubeadmの例)
AdmissionCon
fi
gurationをKubernetesクラスターに適用するには、kube-apiserverの起動オプション
--admission-control-con
fi
g-
fi
leで、AdmissionCon
fi
guration定義ファイルを指定します。
44. 4.3. Pod Security Admission - デフォルトポリシーの適用 -
# kubectl apply -f exploit-pod.yaml -n namespace-b
Error from server (Forbidden): error when creating "exploit-pod.yaml": pods "exploit-pod" is forbidden: violates
PodSecurity "baseline:v1.25": host namespaces (hostPID=true), privileged (container "ubuntu" must not set
securityContext.privileged=true)
# kubectl get po -n namespace-b
No resources found in namespace-b namespace.
# kubectl apply -f exploit-pod.yaml -n namespace-c
pod/exploit-pod created
# kubectl get po -n namespace-c
NAME READY STATUS RESTARTS AGE
exploit-pod 1/1 Running 0 20s
exploit-pod.yaml をnamespace-bとnamespace-cに適用してみます。
namespace-bにはデフォルトポリシーが適用されているためPodのデプロイに失敗していることが確認できます。
一方namespace-cではポリシーが適用されず、正常にPodのデプロイに成功していることが確認できます。
namespace-c(ポリシー適用除外対象として指定)
namespace-b(デフォルトポリシーが適用される)
ポリシーが適用されずPodのデプロイに成功している
Baselineポリシーに違反しているためPodのデプロイが拒否された
[Pod Security Admission]
enforce: baseline
audit: restricted
warn: restricted
