Kubernetes 中内置了 RBAC、SecurityContext、PodSecurityPolicy 几个对象,用于为集群的运维和运营工作提供安全支持,那么为什么还要出现 Gatekeeper、Kyverno、Polaris 等策略系统呢?答案呼之欲出——不够用。首先看看几个内置手段的工作范围。
这是一个最基础的访问控制手段,它的任务就是描述“谁”能把“什么”“怎么样”。
RoleBinding
或 ClusterRoleBinding
的 Subject
字段中进行指定,其取值范围包括 user
、group
以及 ServiceAccount
等。Pod
、Namespace
、NetworkPolicy
等,除此之外还包括对象的子对象,例如 Pod
的 logs
、exec
等。这个内容在 Role
或者 ClusterRole
的 resources
字段中进行表达。get
、create
和 update
等,这个内容保存在 Role
或者 ClusterRole
对象的 verbs
字段中。RBAC 相对来说是一个比较粗放的模型,实际工作中可能会有更复杂的需要,例如 Pod
、NetworkPolicy
或者复杂 Operator 的 CRD,都是需要精细控制的。
SecurityContext
负责定义 Pod 和容器的一些具体行为,可以直接在 Pod 中进行定义。
注意 SecurityContext
字段在容器和 Pod 两个级别都是存在的,
容器级别的对象类型为 SecurityContext
,其限制范围包括:
allowPrivilegeEscalation
capabilities
privileged
procMount
readOnlyRootFilesystem
runAsGroup
runAsNonRoot
runAsUser
seLinuxOptions
windowsOptions
而 Pod 级别的对象类型为 PodSecurityContext
,其限制范围包括:
fsGroup
fsGroupChangePolicy
runAsGroup
runAsNonRoot
runAsUser
seLinuxOptions
supplementalGroups
sysctls
windowsOptions
PSP 像是 RBAC 的延伸,通过 PodSecurityPolicy
对象定制 Pod 的安全规则,再借助 RBAC 的形式授权给用户,从而允许或者禁止特定用户/ServiceAccount 所创建的 Pod 的安全相关的能力。
和前面两种措施不同,PSP 并不是开箱即用的,需要单独启用这个 AdmissionController。在启用之前要注意,PSP 除了需要显式启用,还需要进行显式授权,必须为当前集群中运行的所有 Pod 所属的 ServiceAccount 赋予合适的 PSP,才能启用该功能,否则会造成大量的系统 Pod 无法正常运行。
PSP 基本覆盖了 SecurityContext 的各项能力,除此之外还加入了一些特技:
和可以自由发挥的 SecurityContext 相比,PSP 具备更多能力,也具备更大的强制性,可能会对既有集群上的业务造成一定影响,需要慎重使用。
根据前面的了解,我们借助 Kubernetes 自有的安全设置能力,已经能够对工作负载进行很多有助于提高安全性的设置,这是否足够了呢?其实是存在一些漏洞的,例如管理需要,我们要求必须提供资源限制,可以使用如下的的 Kyverno 策略:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-cpu-memory
spec:
validationFailureAction: enforce
rules:
- name: check-pod-resources
match:
resources:
kinds:
- Pod
validate:
message: "CPU and memory resource requests and limits are required"
pattern:
spec:
containers:
- name: "*"
resources:
limits:
memory: "?*"
cpu: "?*"
requests:
memory: "?*"
cpu: "?*"
用类似的手法,还可以检查标签、标注等是否合规。
参考 CIS Kubernetes Benchmark (v151)
,考虑以下几个要求:
这是一个不计分项目,确保仅在必要时使用 cluster-admin
身份(例如 kubeadm 生成的缺省 kubeconfig 文件)。下面的 Kyverno 规则可以用于制止 cluster-admin
身份的用户创建 deployment
:
apiVersion : kyverno.io/v1
kind: ClusterPolicy
metadata:
name: deny-cluster-admin
spec:
validationFailureAction: enforce
background: false
rules:
- name: deny-cluster-admin
match:
resources:
kinds:
- Deployment
namespace: default
clusterroles:
- cluster-admin
validate:
message: "cluster-admin is denied"
deny: {}
在没有启用 PSP 的情况下,可以用如下策略完成这个限制:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-hostnetwork
spec:
validationFailureAction: enforce
background: false
rules:
- name: check-hostnetwork
match:
resources:
kinds:
- Deployment
validate:
message: "Hostnetwork is not allowed"
pattern:
spec:
template:
spec:
=(hostNetwork): "!true"
又一个不计分,但是个人认为很有用的规则,例如特定命名空间内,只会运行同样来源的镜像:
apiVersion : kyverno.io/v1
kind: ClusterPolicy
metadata:
name: image-prefix
spec:
validationFailureAction: enforce
background: false
rules:
- name: image-prefix
match:
resources:
kinds:
- Deployment
namespace: default
validate:
message: "Registry is not allowed"
pattern:
spec:
template:
spec:
containers:
- name: "*"
image: "trust-me/*"