使用Open Policy Agent实现Kubernetes Pod安全策略

Kubernetes是当今云原生生态系统中最受欢迎的容器编排平台。所以，Kubernetes的安全性也引发了愈来愈多的关注。

在此博客文章中，首先我将讨论Pod安全策略准入控制器。而后，咱们将看到Open Policy Agent如何实现Pod安全策略。实际上，Open Policy Agent被视为Pod安全策略的潜在替代方案。

首先，简要介绍一下容器，安全性和准入控制器。

容器和安全简介

容器轻巧，轻便且易于管理。在同一主机上运行的容器没有单独的物理/虚拟机。换句话说，容器共享运行它们的主机的资源，硬件和OS内核。所以，具备适当的安全性变得很是重要，这些安全性涉及容器中能够运行哪些进程，这些进程具备哪些特权，容器是否将容许特权升级，使用了什么镜像等等。

Pod是Kubernetes应用程序的基本执行单元，是您建立或部署的Kubernetes对象模型中最小和最简单的单元。它是一个或多个具备共享存储/网络的容器的组，以及有关如何运行容器的规范。所以，在容器上实施安全策略时，咱们将检查安全策略并将其应用于Pod规范。那么，这些策略如何执行？使用准入控制器。

什么是Admission Controllers?

准入控制器是kube-apiserver的一部分。在配置存储在集群设置（etcd）中以前，它们拦截对Kubernetes API服务器的请求。准入控制器能够是正在验证（用于验证传入请求的一个）或正在变异（用于修改传入请求的一个）或二者都在进行。请参阅Kubernetes文档以快速浏览各类准入控制器。

Open Policy Agent 做为 admission controller

Open Policy Agent（OPA）是一种开放源代码的通用策略引擎，能够将策略编写为代码。 OPA提供了一种高级声明性语言-Rego-以策略做为代码。使用OPA，咱们能够跨微服务，CI / CD管道，API网关等执行策略。 OPA最重要的用例之一是Kubernetes做为准入控制者的策略实施。

OPA做为准入控制器，您能够强制执行非root用户之类的策略，要求使用特定的资源标签，确保全部pod都指定了资源请求和限制等。基本上，OPA容许您使用Rego语言将任何自定义策略编写为代码。

这些策略以Rego编写并加载到OPA中，做为Kubernetes集群上的准入控制器运行。 OPA将根据Rego策略评估对Kubernetes API服务器的任何资源建立/更新/删除请求。若是请求知足全部策略，则容许该请求。可是，即便单个策略失败，请求也会被拒绝。

在此处阅读有关OPA，Rego的更多信息，并用做OPA文档中的准入控制器。

Pod Security Policy

Pod安全策略（PSP）是实现为准入控制器的集群级别资源。 PSP容许用户将安全要求转换为管理Pod规范的特定策略。首先，建立PodSecurityPolicy资源时，它什么也不作。为了使用它，必须经过容许“使用”动词来受权请求​​用户或目标pod的服务账户使用该策略。您能够参考Kubernetes文档上的启用Pod安全策略。

注意，PSP准入控制器既充当验证角色，又充当变异准入控制器。对于某些参数，PSP准入控制器使用默认值来更改传入的请求。此外，顺序始终是先突变而后验证。

使用PSP咱们能够控制哪些全部参数？

下表简要概述了PSP中使用的各类参数和字段。在此处的Kubernetes文档中提供了详细说明。

那么，咱们能够在OPA中实现PSP吗？

前面提到，Rego语言容许咱们将任何自定义策略编写为代码。这意味着，咱们可使用Rego编写上述的Pod安全策略，并以OPA做为准入控制器来执行。

让咱们快速了解一下实施“特权”Pod安全策略的Rego策略。能够在Rego playground试用此策略。

package kubernetes.admission

deny[message] {
    #applies for Pod resources
    input.request.kind.kind == "Pod" 
    #loops through all containers in the request
    container := input.request.object.spec.containers[_]
    #for each container, check privileged field
    container.securityContext.privileged
    #if all above statements are true, return message
    message := sprintf("Container %v runs in privileged mode.", [container.name])
}

那么，该策略有何做用？若是输入请求中的任何容器正在做为特权容器运行，它将返回一条消息。

PSP 实战

让咱们经过基于minikube的教程来了解这项策略的实际效果。首先，按照此处OPA文档中的教程，将OPA设置为准入控制器。本教程将加载入口验证策略。取而代之的是，咱们将加载上面显示的特权策略。

将OPA设置为minikube上的准入控制器后，请使用上述策略建立文件privileged.rego。而后，在“ opa”名称空间中将策略建立为configmap。

kubectl create configmap privileged-policy --from-file=privileged.rego -n opa

等待策略加载到OPA。当configmap的注释增长了openpolicyagent.org/policy-status:'{"status":"ok"}'项时代表已经加载了该策略。

如今，让咱们使用如下清单建立具备特权容器的部署：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    securityContext:
      privileged: true

当您尝试建立此Pod时，您会注意到Open Policy Agent拒绝了Pod。

Error from server (Container nginx runs in privileged mode.): error when creating "privileged-deploy.yaml": admission webhook "validating-webhook.openpolicyagent.org" denied the request: Container nginx runs in privileged mode.

一样，咱们能够为其余Pod安全策略参数编写策略，并使用OPA实施。

在本教程中，为简单起见，咱们使用configmap加载了策略，但这并非生产部署的最佳策略。对于生产部署，能够将OPA配置为按期从外部捆绑服务器中下载策略捆绑。您的全部策略均可以在此捆绑服务器中维护。 OPA将经过按期下载策略来保持最新状态。有关更多详细信息，请参考Bundle API。

简而言之，使用OPA，咱们能够实施Pod安全策略。不只如此，咱们还可使用相同的设置来实施任何其余基于自定义。

将OPA用于PSP的主要好处是什么？

咱们从这种方法中得到的一些主要好处是：

• 在一个准入控制器中集中管理全部策略（PSP和其余自定义策略），而没必要分别进行管理
• 在CI / CD管道中也执行相同的策略，从而在整个堆栈中实施“按代码编码”。
• 可以在源控制存储库（如Git）中维护OPA策略。 OPA提供了HTTP API以动态管理加载的策略。
• 将策略决策流式传输到您选择的外部日志记录/监视工具。
• 根据您的设置/实现自定义拒绝消息。

另外，咱们能够将OPA部署为变异许可控制器。这样，您还能够实现PSP Admission Controller的变异行为。

结论

咱们能够经过OPA有效实施Pod安全策略。此外，这使咱们可以将安全策略建模为代码。并且，全部这些都在一个OPA准入控制器中。

PS: 本文属于翻译，原文