使用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: 本文屬於翻譯，原文