客座文章之前由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.admissiondeny[msg] {  c := input_containers[_]  c.securityContext.privileged  msg := sprintf("Privileged container is not allowed: %v, securityContext: %v", [c.name, c.securityContext])}input_containers[c] {  c := input.request.object.spec.containers[_]}input_containers[c] {  c := input.request.object.spec.initContainers[_]}

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

  • 第1行：蕴含package。留神，你必须应用kubernetes.admission让政策工作。
  • 第2行：Deny是默认对象，它将蕴含咱们须要执行的策略。如果所蕴含的代码计算结果为true，则将违反策略。
  • 第3行：咱们定义了一个变量，它将包容pod中的所有容器，并从稍后定义的input_containers[c]接管值。
  • 第4行：如果pod蕴含“privileged”属性，则该语句为true。
  • 第5行：当用户尝试运行特权容器时显示给他们的音讯。它包含容器名称和违规的平安上下文。
  • 第7-9行：input_containers[c]函数从申请对象中提取容器。留神，应用了_字符来遍历数组中的所有容器。在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 - <<EOTapiVersion: v1kind: Podmetadata: name: nginx-privileged labels:  app: nginx-privilegedspec: containers: - name: nginx  image: nginx  securityContext:   privileged: true #falseEOTError 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微信公众号。