3. OPA Gatekeeper 入门:OPA 与 Gatekeeper 概述、架构、安装与核心概念

3.1 OPA 与 Gatekeeper 概述

在云原生生态中,Kubernetes 集群的安全与合规管理是运维的基石。OPA(Open Policy Agent)是一个开源的、通用的策略引擎,它将策略从服务代码中解耦,提供统一的声明式策略语言 Rego。而 Gatekeeper 是 OPA 在 Kubernetes 环境中的原生集成实现,作为 Admission Webhook 运行,在资源创建、更新时拦截请求并进行策略校验。

核心关系:OPA 是通用策略引擎,Gatekeeper 是 OPA 在 K8s 上的专属适配器。Gatekeeper 将 OPA 的能力封装为 Kubernetes 原生资源(CRD),使得策略管理完全融入 K8s 声明式体系。

3.2 Gatekeeper 架构

Gatekeeper 由三个核心组件构成,它们协同工作以实现策略的注册、执行与审计。下图展示了 Gatekeeper 在 Kubernetes 集群中的部署架构与请求流程。

Gatekeeper 核心架构与请求流程 kubectl / 客户端 K8s API Server Gatekeeper Webhook OPA 引擎 创建/更新请求 AdmissionReview 查询 Rego 允许/拒绝 响应结果 数据存储(etcd / ConfigMap) ConstraintTemplate / Constraint / 集群状态 缓存数据 审计(Audit) 架构说明: 1. 客户端发起资源请求 → API Server 拦截 → 调用 Gatekeeper Webhook 2. Webhook 将 AdmissionReview 转发给 OPA 引擎,执行 Rego 策略 3. OPA 返回允许/拒绝 → Webhook 封装响应 → API Server 执行或拒绝 4. 审计组件定期扫描集群现有资源,标记违反策略的资源

3.3 安装与部署

Gatekeeper 的安装推荐使用 Helm Chart 或直接应用官方 YAML 清单。以下为两种主流部署方式。

部署方式 命令 / 步骤 适用场景
Helm 安装
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper/gatekeeper --name-template=gatekeeper --namespace gatekeeper-system --create-namespace
生产环境,参数可定制
YAML 直接部署
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml
快速验证、测试环境
注意事项:安装前确保集群版本 ≥ 1.16(支持 admissionregistration.k8s.io/v1)。Gatekeeper 默认部署在 gatekeeper-system 命名空间,包含 Deployment、Service、WebhookConfiguration 等资源。安装后可通过 kubectl get pods -n gatekeeper-system 验证 Pod 状态。

3.4 核心概念:ConstraintTemplate 与 Constraint

Gatekeeper 的策略体系围绕两个核心 CRD 构建:ConstraintTemplate 和 Constraint。它们的关系类似于“类”与“实例”,或“函数定义”与“函数调用”。

ConstraintTemplate 与 Constraint 关系 ConstraintTemplate 定义策略逻辑(Rego 代码) 定义参数 Schema(可选) 示例:K8sRequiredLabels 校验资源必须包含指定标签 Constraint 实例化 ConstraintTemplate 传入具体参数(如标签键值) 示例:require-owner-label 要求所有 Namespace 有 owner 标签 实例化 ConstraintTemplate 是策略的“蓝图”,Constraint 是策略的“执行规则”。一个 Template 可被多个 Constraint 复用。

3.4.1 ConstraintTemplate 详解

ConstraintTemplate 是一个集群范围的 CRD 资源,它使用 Rego 语言编写策略逻辑,并可选择性地定义参数 Schema 供 Constraint 传入。以下是一个检查资源必须包含特定标签的模板示例:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("缺少必要标签: %v", [missing])
        }

3.4.2 Constraint 详解

Constraint 是 ConstraintTemplate 的实例化资源,它指定了策略的作用范围(match)和具体参数(parameters)。以下是一个要求所有 Namespace 必须包含 owner 标签的 Constraint 示例:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-owner-label
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - "owner"
关键区别总结:
  • ConstraintTemplate:定义“怎么做”(Rego 逻辑),集群级资源,通常由平台管理员创建。
  • Constraint:定义“对谁做”(match)和“做什么”(parameters),命名空间级或集群级资源,由策略管理员配置。
  • 一个 ConstraintTemplate 可以被多个 Constraint 引用,实现策略复用。

3.5 核心概念对比表

概念 API 版本 作用域 核心内容 示例
ConstraintTemplate templates.gatekeeper.sh/v1 集群 Rego 策略代码 + 参数 Schema K8sRequiredLabels
Constraint constraints.gatekeeper.sh/v1beta1 集群/命名空间 match 规则 + parameters 参数 require-owner-label
Config config.gatekeeper.sh/v1alpha1 集群 Gatekeeper 运行时配置(如排除命名空间) 排除 kube-system
Audit 内置功能 集群 定期扫描现有资源,生成违反报告 constraint_status 对象

3.6 本章小结