kyverno VS gateKeeper

概述

这两组开源工具都是是基于kubernetes 的webhook机制，支持validatingwebhook和mutatingwebhook。整体思路上是一样的，都是针对资源的字段，如标签、镜像等来设置规则，在对kubernetes资源的控制范围和粒度上，二者可以看作是一样的。

kyverno

kyverno 的架构如下，它是基于kubernetes 资源的一种策略执行器，主要基于kubernetes资源的标签和spec字段制定规则，规则支持简单的条件判断，逻辑与、或、非。支持如下功能：

支持集群级别和命名空间级别的策略
支持审计日志功能
有一个官方的UI
支持kubernetes原生资源和CRD
支持如下规则类型：

validate：规则校验，最常用的类型

mutate：支持修改现有资源

generate：支持生成新的资源

verifyImages：校验镜像签名

例子

如下策略表示拒绝没有cluster-admin clusterRoles的用户删除带app.kubernetes.io/managed-by: kyverno 标签的对象

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

  name: deny-deletes

spec:

  validationFailureAction: enforce

  background: false

  rules:

  - name: block-deletes-for-kyverno-resources

    match:

      resources:

        selector:

          matchLabels:

            app.kubernetes.io/managed-by: kyverno

    exclude:

      clusterRoles:

      - cluster-admin

    validate:

      message: "Deleting {{request.oldObject.kind}}/{{request.oldObject.metadata.name}} is not allowed"

      deny:

        conditions:

        - key: "{{request.operation}}"

          operator: In

          value:

          - DELETE

由于kyverno 建立在kubernetes之上，其策略决策和策略执行也是基于kubernetes的资源，因此也限制了其使用场景，如对接image registries, Active Directory/LDAP directories等第三方验证服务，而gatekeeper就可以支持就这些场景。

此外由于它使用类yaml的方式来表达策略的，因此其使用起来比较笨拙。

优点就是使用的配置比较简单，相比于gateKeeper来说入手比较简单，维护成本低。

gateKeeper

例子

gateKeeper的规则配置要分为两步，首先创建ConstraintTemplate，再创建constraint

首先需要创建一个模板ConstraintTemplate，下面模板用于要求所有资源中必须存在constraint 所要求的标签

apiVersion: templates.gatekeeper.sh/v1beta1

kind: ConstraintTemplate

metadata:

  name: k8srequiredlabels

spec:

  crd:

    spec:

      names:

        kind: K8sRequiredLabels

      validation:

        # Schema for the `parameters` field

        openAPIV3Schema:

          properties:

            labels:

              type: array

              items: string

  targets:

    - target: admission.k8s.gatekeeper.sh

      rego: |

        package k8srequiredlabels

        violation[{"msg": msg, "details": {"missing_labels": missing}}] {

          provided := {label | input.review.object.metadata.labels[label]}

          required := {label | label := input.parameters.labels[_]}

          missing := required - provided

          count(missing) > 0

          msg := sprintf("you must provide labels: %v", [missing])

        }

然后创建一个constraints，并指定上面的K8sRequiredLabels模板，要求所有命名空间资源中必须有gatekeeper标签

apiVersion: constraints.gatekeeper.sh/v1beta1

kind: K8sRequiredLabels

metadata:

  name: ns-must-have-gk

spec:

  match:

    kinds:

      - apiGroups: [""]

        kinds: ["Namespace"]

  parameters:

    labels: ["gatekeeper"]

对比表

Features/Capabilities	Gatekeeper	Kyverno
Validation	✓	✓
Mutation	✓* beta	✓
Generation	X	✓
Policy as native resources	✓	✓
Metrics exposed	✓	✓
OpenAPI validation schema (`kubectl explain`)	X	✓
High Availability	✓	✓*
API object lookup	✓	✓
CLI with test ability	✓**	✓
Policy audit ability	✓	✓
Self-service reports	X	✓

* Alpha status

** Separate CLI

Community/Ecosystem	Gatekeeper	Kyverno
CNCF status	Graduated (OPA)	Sandbox
Partner ecosystem adoption*	◗	◔
GitHub status (stars, forks, releases, commits)	1,832, 349, 46, 630	1,063, 122, 82, 3,326
Community traction**	◗	◔
Policy sample library	✓	✓

* Not well defined. 相比Kyverno来说，Gatekeeper 的采纳意向更多,但具体不详.

** No objective measurement exists. 考虑到社区的存在时间，Gatekeeper 可能更具吸引力.

Meta/Misc	Gatekeeper	Kyverno
Programming required	✓	X
Use outside Kubernetes	✓	X
Birth (Age as of June 2021)	July 2017 (3 years, 11 months)	May 2019 (2 years, 1 month)
Origin company	Styra (OPA)	Nirmata
Documentation maturity	◗*	◕

* Not totally objective with direct comparison being difficult. Assessment made based on Gatekeeper project/functionality and not maturity level of Rego enablement materials/literature.

参考