Kubernetes 为什么需要策略支持
Kubernetes 中内置了 RBAC、SecurityContext、PodSecurityPolicy 几个对象，用于为集群的运维和运营工作提供安全支持，那么为什么还要出现 Gatekeeper、Kyverno、Polaris 等策略系统呢？答案呼之欲出——不够用。首先看看几个内置手段的工作范围。
RBAC
这是一个最基础的访问控制手段，它的任务就是描述“谁”能把“什么”“怎么样”。
谁：这个主语通常指的是操作主体，在 RBAC 体系中，会在
RoleBinding或ClusterRoleBinding的Subject字段中进行指定，其取值范围包括user、group以及ServiceAccount等。什么：Kubernetes 中的对象，例如
Pod、Namespace、NetworkPolicy等，除此之外还包括对象的子对象，例如Pod的logs、exec等。这个内容在Role或者ClusterRole的resources字段中进行表达。怎么样：允许特定用户对特定资源进行的操作，例如
get、create和update等，这个内容保存在Role或者ClusterRole对象的verbs字段中。
RBAC 相对来说是一个比较粗放的模型，实际工作中可能会有更复杂的需要，例如 Pod、NetworkPolicy 或者复杂 Operator 的 CRD，都是需要精细控制的。
SecurityContext
SecurityContext 负责定义 Pod 和容器的一些具体行为，可以直接在 Pod 中进行定义。
注意 SecurityContext 字段在容器和 Pod 两个级别都是存在的，
容器级别的对象类型为 SecurityContext，其限制范围包括：
allowPrivilegeEscalationcapabilitiesprivilegedprocMountreadOnlyRootFilesystemrunAsGrouprunAsNonRootrunAsUserseLinuxOptionswindowsOptions
而 Pod 级别的对象类型为 PodSecurityContext，其限制范围包括：
fsGroupfsGroupChangePolicyrunAsGrouprunAsNonRootrunAsUserseLinuxOptionssupplementalGroupssysctlswindowsOptions
PodSecurityPolicy
PSP 像是 RBAC 的延伸，通过 PodSecurityPolicy 对象定制 Pod 的安全规则，再借助 RBAC 的形式授权给用户，从而允许或者禁止特定用户/ServiceAccount 所创建的 Pod 的安全相关的能力。
和前面两种措施不同，PSP 并不是开箱即用的，需要单独启用这个 AdmissionController。在启用之前要注意，PSP 除了需要显式启用，还需要进行显式授权，必须为当前集群中运行的所有 Pod 所属的 ServiceAccount 赋予合适的 PSP，才能启用该功能，否则会造成大量的系统 Pod 无法正常运行。
PSP 基本覆盖了 SecurityContext 的各项能力，除此之外还加入了一些特技：
- hostPID、hostIPC
- hostNetwork、hostPorts
- allowedHostPaths
和可以自由发挥的 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)，考虑以下几个要求：
5.1.1 Ensure that the cluster-admin role is only used where required
这是一个不计分项目，确保仅在必要时使用 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: {}
5.2.4 Minimize the admission of containers wishing to share the host network namespace (Scored)
在没有启用 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"
5.5.1 Configure Image Provenance using ImagePolicyWebhook admission controller
又一个不计分，但是个人认为很有用的规则，例如特定命名空间内，只会运行同样来源的镜像：
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/*"