内容简介:PodSecurityPolicy是一种用来控制Pod安全相关配置的全局资源。在开启RBAC的kubernetes集群上,如果允许用户使用kubectl,那么必须开启PodSecurityPolicy,否则用户可能会使用一些特权资源(例如privileged,hostNetwork,hostPath等等),影响node机器的稳定性。开启PSP后,用户只能使用管理员允许的资源。PSP支持以下方面(具体请见
PodSecurityPolicy是什么
PodSecurityPolicy是一种用来控制Pod安全相关配置的全局资源。
在开启RBAC的kubernetes集群上,如果允许用户使用kubectl,那么必须开启PodSecurityPolicy,否则用户可能会使用一些特权资源(例如privileged,hostNetwork,hostPath等等),影响node机器的稳定性。
开启PSP后,用户只能使用管理员允许的资源。PSP支持以下方面(具体请见 官网 ):
Control Aspect | Field Names |
---|---|
Running of privileged containers | |
Usage of host namespaces | |
Usage of host networking and ports |
hostNetwork
, hostPorts
|
Usage of volume types | |
Usage of the host filesystem | |
White list of Flexvolume drivers | |
Allocating an FSGroup that owns the pod’s volumes | |
Requiring the use of a read only root file system |
readOnlyRootFilesystem
|
The user and group IDs of the container |
runAsUser
, runAsGroup
, supplementalGroups
|
Restricting escalation to root privileges |
allowPrivilegeEscalation
, defaultAllowPrivilegeEscalation
|
Linux capabilities |
defaultAddCapabilities
, requiredDropCapabilities
, allowedCapabilities
|
The SELinux context of the container | |
The Allowed Proc Mount types for the container |
allowedProcMountTypes
|
The AppArmor profile used by containers | |
The seccomp profile used by containers | |
The sysctl profile used by containers |
开启PodSecurityPolicy
开启很简单,配置apiserver增加admission plugin PodSecurityPolicy即可。
--enable-admission-plugins=NodeRestriction,PodSecurityPolicy
修改后apiserver会重启。由于这里没有配置任何Policy,所以重启后PSP会阻止所有Pod的创建。
由于PSP API policy/v1beta1/podsecuritypolicy
与admission controller是独立的,对于现存的集群,建议先配置psp以及授权,再开启PS。
授权策略
Policy本身并不会产生实际作用,需要将其与用户或者serviceaccount绑定才可以完成授权。
绑定方法:创建Role,该Role可以use 该PodSecurityPolicy,然后将该role与用户或者serviceaccount绑定。
示例
下面举个例子。
1. 创建Policy
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: example spec: privileged: false # Don't allow privileged pods! # The rest fills in some required fields. seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny volumes: - '*'
2. 创建serviceaccount
kubectl create namespace hellobaby kubectl create sa fake-user alias kubectl-admin='kubectl -n hellobaby' alias kubectl-user='kubectl --as=system:serviceaccount:hellobaby:fake-user -n hellobaby'
3. 创建Pod
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx name: nginx
此时使用kubectl-user创建Pod会提示 Error from server (Forbidden): error when creating "STDIN": pods "nginx" is forbidden: unable to validate against any pod security policy: []
,因为sa fake-user并没有psp example的权限,可以通过auth检查下。
kubectl-user auth can-i use podsecuritypolicy/example
所以下面需要创建role、rolebinding。
4. 创建带psp example use权限的role,并与sa hellobaby绑定
kubectl-admin create role psp:unprivileged --verb=use \ --resource=podsecuritypolicy \ --resource-name=example kubectl-admin create rolebinding fake-user:psp:unprivileged \ --role=psp:unprivileged \ --serviceaccount=hellobaby:fake-user rolebinding "fake-user:psp:unprivileged" created
现在再去创建上述Pod nginx,就可以创建了,而且可以创建成功,因为这个Pod没有请求任何特殊权限,是个乖孩子。
加上特权字段,再创建呢?
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx name: nginx securityContext: privileged: true
kubectl-user会返回 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]
提示很清楚: Privileged containers are not allowed
。
PodSecurityPolicy 生效了。
5. 非sa直接创建的Pod
大部分情况我们并不会直接创建Pod,而是会创建Deployment。试试看。
$ kubectl-user run nginx --image=nginx deployment "nginx" 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 nginx-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "nginx-7774d79b5-" is forbidden: no providers available to validate pod request
提示没有providers用来检查Pod请求,可是我们已经给sa hellobaby:fake-user授权了呀。
原因是,这个Pod是replicaset controller创建的,默认kubectl run的形式创建的应用指定的 spec.template.spec.serviceAccount
和 spec.template.spec.serviceAccountName
都是default,而上面我们RBAC绑定的SA是 hellobaby:fake-user
,并不是 hellobaby:default
。
怎么解决呢?官网给的方法是,再给 hellobaby:default
绑定 role psp:unprivileged
。的确这样可以解决问题,但这个解决方法并不合理。
我们知道,一个namespace下是可以创建多个serviceaccount的,如果我需要给同一namespace下不同是sa授予不同的psp,那么应该如何给sa default授权呢?显然就无法绑定了。
事实上,我认为官网的这个例子并不合理,而且 kubectl run
命令也要被取消了。
更好的做法是创建一个deployment,并且设置其 spec.template.spec.serviceAccount
和 spec.template.spec.serviceAccountName
为实际的sa。
下面是一个实际的例子。
metadata: labels: run: nginx-test name: nginx-test namespace: hellobaby spec: replicas: 1 selector: matchLabels: run: nginx-test template: metadata: labels: run: nginx-test spec: containers: - image: nginx imagePullPolicy: Always name: nginx-test #securityContext: # privileged: true dnsPolicy: ClusterFirst restartPolicy: Always serviceAccount: fake-user serviceAccountName: fake-user
此时replicaset controller会使用 sa hellobaby:fake-user
创建pod,由于前面已经为该sa绑定了psp example,所以可以成功创建Pod。
Ref:
以上所述就是小编给大家介绍的《kubernetes支持PodSecurityPolicy》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 支持向量机(一):支持向量机的分类思想
- Vardump 更新,支持打印各种 Java 数据结构,支持嵌套
- Vardump 更新,支持打印各种 Java 数据结构,支持嵌套
- NutzBoot v2.1.5 添加单元测试支持及 ssdb 支持
- iView 3.1.0 版本:支持 TypeScript,支持 Vue CLI 3
- Mesalink v1.0.0 发布,正式支持 TLS 1.3 和 IPv6,支持CMake编译,支持Windows,实现生产环境可用
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。