kyverno VS gateKeeper
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.
参考
本文来自博客园,作者:charlieroro,转载请注明原文链接:https://www.cnblogs.com/charlieroro/p/15829201.html