使用 Gatekeeper 进行 OPA 策略管理
发布时间:2022-05-23 14:04:08 所属栏目:云计算 来源:互联网
导读:前面我们介绍了使用 kube-mgmt 这个 sidecar 容器来完成 OPA 策略的自动同步,此外还有另外一个更加高级的工具 Gatekeeper,相比于之前的模式,Gatekeeper(v3.0) 准入控制器集成了 OPA Constraint Framework,以执行基于 CRD 的策略,并允许声明式配置的策略
前面我们介绍了使用 kube-mgmt 这个 sidecar 容器来完成 OPA 策略的自动同步,此外还有另外一个更加高级的工具 Gatekeeper,相比于之前的模式,Gatekeeper(v3.0) 准入控制器集成了 OPA Constraint Framework,以执行基于 CRD 的策略,并允许声明式配置的策略可靠地共享,使用 kubebuilder 构建,它提供了验证和修改准入控制和审计功能。这允许为 Rego 策略创建策略模板,将策略创建为 CRD,并在策略 CRD 上存储审计结果,这个项目是谷歌、微软、红帽和 Styra 一起合作实现的。 直接使用下面的命令即可安装 Gatekeeper: 复制 ➜ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/release-3.7/deploy/gatekeeper.yaml 默认会将 Gatekeeper 安装到 gatekeeper-system 命名空间下面,同样会安装几个相关的 CRD: 复制 ➜ kubectl get pods -n gatekeeper-system NAME READY STATUS RESTARTS AGE gatekeeper-audit-5cf4b9686-glndv 1/1 Running 0 2m2s gatekeeper-controller-manager-77b7dc99fb-dvkvp 1/1 Running 0 2m2s gatekeeper-controller-manager-77b7dc99fb-gk4gr 1/1 Running 0 2m2s gatekeeper-controller-manager-77b7dc99fb-mt5wn 1/1 Running 0 2m2s ➜ kubectl get crd |grep gate assign.mutations.gatekeeper.sh 2022-03-27T06:47:24Z assignmetadata.mutations.gatekeeper.sh 2022-03-27T06:47:24Z configs.config.gatekeeper.sh 2022-03-27T06:47:24Z constraintpodstatuses.status.gatekeeper.sh 2022-03-27T06:47:24Z constrainttemplatepodstatuses.status.gatekeeper.sh 2022-03-27T06:47:24Z constrainttemplates.templates.gatekeeper.sh 2022-03-27T06:47:24Z modifyset.mutations.gatekeeper.sh 2022-03-27T06:47:24Z mutatorpodstatuses.status.gatekeeper.sh 2022-03-27T06:47:25Z providers.externaldata.gatekeeper.sh 2022-03-27T06:47:25Z Gatekeeper 使用 OPA 约束框架来描述和执行策略,在定义约束之前必须首先定义一个 ConstraintTemplate 对象,它描述了强制执行约束的 Rego 和约束的模式。约束的模式允许管理员对约束的行为进行微调,就像函数的参数一样。 如下所示是一个约束模板,描述了验证的对象必须要有标签存在: 复制 # k8srequiredlabels_template.yaml apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8srequiredlabels spec: crd: spec: names: kind: K8sRequiredLabels validation: openAPIV3Schema: # Schema for the `parameters` field type: object description: Describe K8sRequiredLabels crd parameters properties: labels: type: array items: type: string description: A label 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]) } 直接应用上面的 ConstraintTemplate 资源清单: 复制 ➜ kubectl apply -f k8srequiredlabels_template.yaml constrainttemplate.templates.gatekeeper.sh/k8srequiredlabels created ➜ kubectl get ConstraintTemplate NAME AGE k8srequiredlabels 68s 上面我们的定义的 ConstraintTemplate 对象就是一个模板,其中的 crd 部分描述了我们定义的 CRD 模板,比如类型叫 K8sRequiredLabels,需要和模板的名称保持一致,然后通过下面的 validation 定义了我们的 CRD 的属性 Schema,比如有一个 labels 的属性参数,类似是字符串数据类型: 复制 crd: spec: names: kind: K8sRequiredLabels validation: openAPIV3Schema: # Schema for the `parameters` field type: object description: Describe K8sRequiredLabels crd parameters properties: labels: type: array items: type: string description: A label string 然后下面的 targets 部分就是定义的约束目标,使用 Rego 进行编写。 首先通过 provided := {label | input.review.object.metadata.labels[label]} 获取到创建对象的所有 label 标签。 然后通过 required := {label | label := input.parameters.labels[_]} 获取到需要提供的 label 标签。 将上面两个标签集合相减(rego语言支持该操作),得到未满足的 label。 断言未满足的label数量>0,如果大于0,说明条件满足,violation 为 true,说明违反了约束,返回错误。 上面的约束模板创建完成后,实际上相当于创建了一个名为的 K8sRequiredLabels 对象,我们定义的属性位于 spec.parameters 属性下面: 复制 ➜ kubectl get K8sRequiredLabels No resources found ➜ kubectl explain K8sRequiredLabels.spec.parameters.labels KIND: K8sRequiredLabels VERSION: constraints.gatekeeper.sh/v1beta1 FIELD: labels <[]string> DESCRIPTION: A label string 现在我们就可以使用上面的 K8sRequiredLabels 这个约束模板来定义策略了,比如我们要求在所有命名空间上都定义一个 gatekeeper 的标签,则可以创建如下所示的对象: 复制 # all_ns_must_have_gatekeeper.yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: ns-must-have-gk spec: match: kinds: - apiGroups: [""] kinds: ["Namespace"] # 表示这个约束会在创建命名空间的时候被应用,可以使用 namespaceSelector、namespaces等进行过滤 parameters: labels: ["gatekeeper"] # 根据schema规范定义 注意 match 字段,它定义了将应用给定约束的对象的范围,其中 kinds: ["Namespace"] 表示这个约束会在创建命名空间的时候被应用,此外它还支持其他匹配器: kind 接受带有 apiGroups 和 kind 字段的对象列表,这些字段列出了约束将应用到的对象的组/种类。如果指定了多个组/种类对象,则资源在范围内只需要一个匹配项。 scope 接受 、Cluster 或 Namespaced 决定是否选择集群范围和/或命名空间范围的资源。(默认为) namespaces 是命名空间名称的列表。如果已定义,则约束仅适用于列出的命名空间中的资源。命名空间还支持基于前缀的 glob。例如,namespaces: [kube-*] 匹配 kube-system 和 kube-public。 excludeNamespaces 是命名空间名称的列表。如果已定义,则约束仅适用于不在列出的命名空间中的资源。ExcludedNamespaces 还支持基于前缀的 glob,例如,excludedNamespaces: [kube-*] 匹配 kube-system 和 kube-public。 labelSelector 是标准的 Kubernetes 标签选择器。 namespaceSelector 是针对对象的包含名称空间或对象本身的标签选择器,如果对象是名称空间。name 是对象的名称。如果已定义,则匹配具有指定名称的对象。Name 还支持基于前缀的 glob。例如,名称:pod-* 匹配 pod-a 和 pod-b。 下面的 parameters.labels 就是根据上面的 CRD 规范定义的属性,该值是传递给 opa 的参数,此处表示一个 key 为 labels,value 为一个列表的字典,与 ConstraintTemplate 里的 properties 要匹配上,此处表示要创建的对象需要含有 gatekeeper 的 label。 直接应用上面的这个资源对象即可: 复制 ➜ kubectl apply -f all_ns_must_have_gatekeeper.yaml k8srequiredlabels.constraints.gatekeeper.sh/ns-must-have-gk created 创建完成后可以查看到这个 constraints 对象: 复制 ➜ kubectl get k8srequiredlabels NAME AGE ns-must-have-gk 73s ➜ kubectl get constraints # 和上面对象一样 NAME AGE ns-must-have-gk 81s 由于 Gatekeeper 具有审计功能,可以根据集群中执行的约束条件对资源进行定期评估,以检测预先存在的错误配置,Gatekeeper 将审计结果存储为相关约束条件的 status 字段中列出违规行为。我们可以查看 K8sRequiredLabels 对象的 status 字段来查看不符合约束的行为: 复制 ➜ kubectl get constraints ns-must-have-gk -o yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels ...... status: auditTimestamp: "2022-03-27T07:42:38Z" ...... totalViolations: 11 violations: - enforcementAction: deny kind: Namespace message: 'you must provide labels: {"gatekeeper"}' name: apisix - enforcementAction: deny kind: Namespace message: 'you must provide labels: {"gatekeeper"}' name: default 比如现在我们创建一个如下所示的 Namespace: 复制 # test-namespace.yaml apiVersion: v1 kind: Namespace metadata: name: ns-test labels: a: b #gatekeeper: abc 此时不给命名空间添加 key 为 gatekeeper 的 label,创建的时候就会报错: 复制 Error from server ([ns-must-have-gk] you must provide labels: {"gatekeeper"}): error when creating "test-namespace.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [ns-must-have-gk] you must provide labels: {"gatekeeper"} 1. 然后把 gatekeeper: abc 这行的注释打开,则能成功创建了,这就是 Gatekeeper 的基本用法。 从上面我们可以知道定义约束模板的策略会经常从 input 对象中获取数据,但是如果需要创建自己的约束,但是不知道传入的参数即 input 是什么,有一种简单方法是使用拒绝所有请求并将请求对象作为其拒绝消息输出的约束/模板。我们可以在创建模板时在 violation 中只保留一行 msg := sprintf("input: %v", [input]),此时创建对象时必定会失败,然后获取到输出的错误信息,里面即包含所有 input 信息,之后再通过 Rego 语法去获取需要的数据即可。 复制 apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8sdenyall spec: crd: spec: names: kind: K8sDenyAll targets: - target: admission.k8s.gatekeeper.sh rego: | package k8sdenyall violation[{"msg": msg}] { msg := sprintf("input: %v", [input]) } --- apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sDenyAll metadata: name: deny-all-namespaces spec: match: kinds: - apiGroups: [""] kinds: ["Namespace"] 由于约束模板或者说策略库具有一定的通用性,所以 OPA Gatekeeper 社区提供了一个通用的策略库:https://github.com/open-policy-agent/gatekeeper-library,该仓库中包含了大量通用的约束模板。 每个模板库下面都包含一个 template.yaml 文件用来描述约束模板,samples 目录下面就包含具体的约束对象和示例资源清单,这些策略也是我们去学习 Rego 语言的很好的案例。 (编辑:东莞站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
站长推荐