為何使用OPA安全策略

為何使用OPA安全策略，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

我們將演示如何使用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，所以建議使用它來創建跨越所有相關資源的集群級策略文檔。

看完上述內容，你們掌握為何使用OPA安全策略的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！