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

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: {}

在没有启用 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/*"

文章来源于互联网:Kubernetes 为什么需要策略支持