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.