# 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`，其限制范围包括：

- `allowPrivilegeEscalation`
- `capabilities`
- `privileged`
- `procMount`
- `readOnlyRootFilesystem`
- `runAsGroup`
- `runAsNonRoot`
- `runAsUser`
- `seLinuxOptions`
- `windowsOptions`

而 Pod 级别的对象类型为 `PodSecurityContext`，其限制范围包括：

- `fsGroup`
- `fsGroupChangePolicy`
- `runAsGroup`
- `runAsNonRoot`
- `runAsUser`
- `seLinuxOptions`
- `supplementalGroups`
- `sysctls`
- `windowsOptions`

## 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 策略：

~~~yaml
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`：

~~~yaml
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 的情况下，可以用如下策略完成这个限制：

~~~yaml
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

又一个不计分，但是个人认为很有用的规则，例如特定命名空间内，只会运行同样来源的镜像：

~~~yaml
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/*"
~~~
