Kubernetes 动态访问控制：OPA 实战指南

Kubernetes 动态访问控制：OPA 实战指南

你好！在日益复杂的云原生环境中，Kubernetes 的访问控制变得至关重要。静态的 RBAC（Role-Based Access Control）虽然强大，但在面对细粒度、动态变化的访问控制需求时，就显得力不从心了。这时，OPA（Open Policy Agent）就能大显身手，帮你实现 Kubernetes 中的动态访问控制。

什么是 OPA？

OPA 是一个开源的、通用的策略引擎，它可以让你将策略与应用程序解耦。简单来说，OPA 就像一个“守门员”，你的应用程序（比如 Kubernetes）向它询问“这个用户能不能做这件事？”，OPA 会根据你预先定义的策略给出“允许”或“拒绝”的答案。

OPA 使用一种名为 Rego 的声明式语言来编写策略。Rego 语法简洁、灵活，可以轻松表达各种复杂的访问控制逻辑。更重要的是，OPA 不仅能用于 Kubernetes，还能用于 API 网关、SSH、数据库等各种场景，实现统一的策略管理。

为什么要在 Kubernetes 中使用 OPA？

Kubernetes 自带的 RBAC 虽然能实现基于角色的访问控制，但它有以下局限性：

1. 静态配置： RBAC 规则是静态的，一旦配置好就无法动态改变。如果需要根据运行时环境（比如 Pod 的标签、命名空间、时间等）来调整访问权限，RBAC 就无能为力了。
2. 粒度较粗： RBAC 的最小授权单位是 API 资源（比如 Pod、Service），无法对资源的字段级别进行更细粒度的控制。
3. 缺乏上下文感知： RBAC 无法感知请求的上下文信息，比如请求来源 IP、请求时间等，也就无法根据这些信息做出更智能的决策。

OPA 可以完美解决这些问题。通过 OPA，你可以：

1. 实现动态访问控制： 根据 Pod 的标签、命名空间、请求时间、请求来源 IP 等各种运行时信息，动态调整访问权限。
2. 实现细粒度访问控制： 对资源的字段级别进行访问控制，比如只允许用户修改 Pod 的某些标签。
3. 实现上下文感知访问控制： 根据请求的上下文信息（比如请求来源 IP、请求时间等）做出更智能的决策。
4. 集中管理，减少重复: RBAC策略可能散布于多个配置文件中，OPA 可以让你在一个地方定义和管理所有策略。

OPA 在 Kubernetes 中的集成

要在 Kubernetes 中使用 OPA，通常有两种方式：

1. OPA Gatekeeper： 这是 OPA 官方提供的 Kubernetes 准入控制器（Admission Controller）。它会在 Pod 创建、更新等操作之前，向 OPA 询问是否允许该操作。Gatekeeper 提供了 CRD（Custom Resource Definition）来定义策略，使用起来非常方便。
2. 自定义准入控制器： 你也可以自己编写一个准入控制器，然后在其中调用 OPA 的 API 来进行策略评估。这种方式更灵活，但需要一定的开发工作。

本文将重点介绍 OPA Gatekeeper 的使用方法，因为它更简单、更易用。

OPA Gatekeeper 实战

1. 安装 OPA Gatekeeper

首先，我们需要在 Kubernetes 集群中安装 OPA Gatekeeper。你可以使用 Helm 来安装：

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper/gatekeeper --name gatekeeper --namespace gatekeeper-system --create-namespace

这会在你的集群中创建一个名为 gatekeeper-system 的命名空间，并在其中部署 Gatekeeper 的相关组件。

2. 编写 Rego 策略

接下来，我们需要编写 Rego 策略。Rego 是一种声明式语言，它的语法比较简单，但功能非常强大。这里我们举一个简单的例子：

package kubernetes.admission

denial[msg] {
 input.request.kind.kind == "Pod"
 input.request.operation == "CREATE"
 input.request.namespace == "production"
 not input.request.object.metadata.labels["app"]
 msg := "生产环境的 Pod 必须要有 app 标签"
}

这个策略的意思是：如果有人要在 production 命名空间中创建一个 Pod，而且这个 Pod 没有 app 标签，那么就拒绝这个请求，并返回一条错误消息。

让我们逐行解释一下：

• package kubernetes.admission：这是 Rego 策略的包名，通常使用 kubernetes.admission。
• denial[msg]：这是一个规则，表示如果满足条件，就拒绝请求。msg 是一个变量，用于存储错误消息。
• input.request.kind.kind == "Pod"：表示请求的资源类型是 Pod。
• input.request.operation == "CREATE"：表示请求的操作是创建。
• input.request.namespace == "production"：表示请求的命名空间是 production。
• not input.request.object.metadata.labels["app"]：表示 Pod 没有 app 标签。
• msg := "生产环境的 Pod 必须要有 app 标签"：这是错误消息。

3. 创建 ConstraintTemplate

在 Gatekeeper 中，我们使用 ConstraintTemplate 来定义策略的模板。ConstraintTemplate 包含了 Rego 策略代码，以及一些元数据，比如策略的名称、描述等。

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
 name: k8srequiredlabels
spec:
 crd:
 spec:
 names:
 kind: K8sRequiredLabels
 listKind: K8sRequiredLabelsList
 plural: k8srequiredlabels
 singular: k8srequiredlabels
 targets:
 - target: admission.k8s.gatekeeper.sh
 rego: |
 package kubernetes.admission
 
 denial[msg] {
 input.request.kind.kind == "Pod"
 input.request.operation == "CREATE"
 input.request.namespace == "production"
 not input.request.object.metadata.labels["app"]
 msg := "生产环境的 Pod 必须要有 app 标签"
 }

这个 YAML 文件定义了一个名为 k8srequiredlabels 的 ConstraintTemplate。它的 rego 字段包含了我们刚才编写的 Rego 策略。

4. 创建 Constraint

ConstraintTemplate 只是一个模板，它本身并不会生效。要让策略生效，我们需要创建一个 Constraint 对象。Constraint 对象引用了 ConstraintTemplate，并指定了策略的具体参数。

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
 name: require-app-label-on-production-pods
spec:
 match:
 kinds:
 - apiGroups: [""]
 kinds: ["Pod"]
 namespaces:
 - production
 parameters:
 labels:
 - key: app

这个 YAML 文件定义了一个名为 require-app-label-on-production-pods 的 Constraint 对象。它引用了我们刚才创建的 k8srequiredlabels ConstraintTemplate，并指定了策略只对 production 命名空间中的 Pod 生效，而且要求 Pod 必须要有 app 标签。

5. 测试策略

现在，我们可以测试一下我们的策略是否生效了。我们尝试在 production 命名空间中创建一个没有 app 标签的 Pod：

apiVersion: v1
kind: Pod
metadata:
 name: nginx
 namespace: production
spec:
 containers:
 - name: nginx
 image: nginx:latest

你会发现，Kubernetes 拒绝了这个请求，并返回了一条错误消息：

Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [require-app-label-on-production-pods] 生产环境的 Pod 必须要有 app 标签

这说明我们的策略生效了！

更复杂的例子

上面的例子只是一个简单的演示。在实际应用中，你可能需要编写更复杂的策略。比如，你可以根据 Pod 的资源请求、镜像名称、环境变量等各种信息来制定策略。你甚至可以调用外部 API 来获取策略判断所需的数据。

例如限制只有特定 tag 的镜像才能部署:

package kubernetes.admission

denial[msg] {
 input.request.kind.kind == "Pod"
 input.request.operation == "CREATE"
 container := input.request.object.spec.containers[_]
 startswith(container.image, "my-registry.com/my-image:")
 not endswith(container.image, ":latest")
 not endswith(container.image, ":v1")
 msg := sprintf("镜像 tag 必须是 latest 或 v1, 当前是 %s", [container.image])
}

这里只是抛砖引玉, Rego 提供了强大的表达能力， 结合input对象提供的丰富信息, 你可以按需组合出各种各样的复杂策略。

OPA 的优势与局限性

优势：

• 灵活性： OPA 使用 Rego 语言来编写策略，Rego 语法简洁、灵活，可以轻松表达各种复杂的访问控制逻辑。
• 通用性： OPA 不仅能用于 Kubernetes，还能用于 API 网关、SSH、数据库等各种场景，实现统一的策略管理。
• 解耦性： OPA 将策略与应用程序解耦，你可以独立地修改策略，而无需修改应用程序代码。
• 性能： OPA 使用了高效的查询引擎，可以快速地评估策略。

局限性：

• 学习曲线： Rego 语言虽然简洁，但对于初学者来说，还是有一定的学习曲线。
• 调试： Rego 策略的调试比较困难，需要借助一些工具和技巧。
• 生态: OPA的策略库还不够丰富, 许多策略需要自己从头编写. 不过, 社区也在不断完善, 相信未来会有更多开箱即用的策略。

总结

OPA 是一个强大的策略引擎，它可以帮助你实现 Kubernetes 中的动态访问控制。通过 OPA，你可以轻松地实现细粒度、动态变化的访问控制需求，提高 Kubernetes 集群的安全性。

希望这篇文章能帮助你了解 OPA 的基本概念和使用方法。如果你想深入学习 OPA，可以参考 OPA 的官方文档，或者加入 OPA 的社区，与其他 OPA 用户交流经验。记住，实践出真知，多动手尝试，你就能掌握 OPA 的精髓。