关于k8s:为什么使用OPA而不是原生的Pod安全策略

客座文章之前由 Mohamed Ahmed 在 Magalix 博客 上发表

在本文中，咱们将演示如何应用 OPA 执行最细粒度的安全策略。请留神，本文是一个系列的一部分，咱们将基于“OPA 作为代码介绍”和“集成 OPA 到 Kubernetes”中取得的常识进行。如果你还没有这样做，请浏览本系列中已发表的文章。

你可能曾经相熟 Pod 安全策略，能够在其中对 Pod 利用十分特定的安全控制。例如，应用 Linux 内核性能，应用主机命名空间、网络、端口或文件系统，以及其余许多性能。应用 OPA，你还能够对 pods 施加相似的管制，在本实验室中，咱们将创立一个 OPA 策略，不容许在 pods 中创立有特权的容器。特权容器对主机的拜访级别比非特权容器高。

为什么应用 OPA 而不是原生的 Pod 安全策略？

应用 Pod 安全策略来执行咱们的安全策略并没有什么问题。然而，依据定义，PSP 只能利用于 pods。它们不能解决其余 Kubernetes 资源，如 Ingresses、Deployments、Services 等。OPA 的弱小之处在于它能够利用于任何 Kubernetes 资源。OPA 作为一个许可控制器部署到 Kubernetes，它拦挡发送到 API 服务器的 API 调用，并验证和 / 或批改它们。相应地，你能够有一个对立的 OPA 策略，实用于零碎的不同组件，而不仅仅是 pods。例如，有一种策略，强制用户在其服务中应用公司的域，并确保用户只从公司的镜像存储库中提取镜像。请留神，咱们应用的 OPA 是应用 kube-mgmt 部署的，而不是 OPA Gatekeeper。

Rego 的策略代码

在本文中，咱们假如你曾经相熟了 OPA 和 Rego 语言。咱们还假如你有一个正在运行的 Kubernetes 集群，该集群部署了 OPA 和 kube-mgmt 容器。无关装置阐明，请参阅咱们的前一篇文章。咱们的 no-priv-pod.rego 文件如下所示：

package kubernetes.admission
deny[msg] {c := input_containers[_]
  c.securityContext.privileged
  msg := sprintf("Privileged container is not allowed: %v, securityContext: %v",)
}
input_containers {c := input.request.object.spec.containers[_]
}
input_containers {c := input.request.object.spec.initContainers[_]
}

让咱们简要地浏览一下这个文件：

• 第 1 行：蕴含 package。留神，你必须应用 kubernetes.admission 让政策工作。
• 第 2 行：Deny 是默认对象，它将蕴含咱们须要执行的策略。如果所蕴含的代码计算结果为 true，则将违反策略。
• 第 3 行：咱们定义了一个变量，它将包容 pod 中的所有容器，并从稍后定义的 input_containers 接管值。
• 第 4 行：如果 pod 蕴含“privileged”属性，则该语句为 true。
• 第 5 行：当用户尝试运行特权容器时显示给他们的音讯。它包含容器名称和违规的平安上下文。
• 第 7 - 9 行：input_containers 函数从申请对象中提取容器。留神，应用了_字符来遍历数组中的所有容器。在 Rego 中，你不须要定义循环—下划线字符将主动为你实现此操作。
• 第 10-12 行：咱们再次为 init 容器定义函数。请留神，在 Rego 中，能够屡次定义同一个函数。这样做是为了克服 Rego 函数中不能返回多个输入的限度。当调用函数名时，将执行两个函数，并应用 AND 操作符组合输入。因而，在咱们的例子中，在一个或多个地位中存在一个有特权的容器将违反策略。

部署策略

OPA 会在 opa 命名空间的 ConfigMaps 中找到它的策略。要将咱们的代码利用到 ConfigMap 中，咱们运行以下命令：

kubectl create configmap no-priv-pods --from-file=no-priv-pod.rego

kube-mgmt 边车（sidecar）容器在 opa 命名空间中继续监督 API 服务器，以便你只需创立 ConfigMap 就能够部署策略。

运行策略

让咱们通过尝试部署一个特权容器来确保咱们的策略是无效的：

kubectl -n default apply -f - <<EOT
apiVersion: v1
kind: Pod
metadata:
 name: nginx-privileged
 labels:
  app: nginx-privileged
spec:
 containers:
 - name: nginx
  image: nginx
  securityContext:
   privileged: true #false
EOT
Error from server (Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "STDIN": admission webhook "validating-webhook.openpolicyagent.org" denied the request: Privileged container is not allowed: nginx, securityContext: {"privileged": true}

请留神，咱们无意将 pod 部署到默认命名空间，因为咱们的 admission webhook 将疏忽在 opa 命名空间或 kube-system 中创立的任何资源。

总结

• OPA 是一种通用的、平台无感的策略施行工具，能够通过多种形式与 Kubernetes 集成。
• 你能够应用 OPA 策略来模仿 Pod 安全策略，以避免在集群上调度特权容器。
• 因为 OPA 能够与其余 Kubernetes 资源一起工作，而不仅仅是 Pods，所以倡议应用它来创立逾越所有相干资源的集群级策略文档。

点击浏览网站原文。

CNCF (Cloud Native Computing Foundation)成立于 2015 年 12 月，隶属于 Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注 CNCF 微信公众号。