OPA Gatekeeper 筆記整理 - I

Posted on 2022-03-13 Edited on 2022-03-13 In 工作 Views: Disqus:

研究 Open Policy Agent Gatekeeper(a.k.a OPA Gatekeeper)的起因還是在準備考 CKS(Certified Kubernetes Security Specialist) 這張證照的過程中有看到這個工具。

一般來說，在管理 Kubernetes 時如果有想要做部署規範管理，會想到 Kubernetes 原生的 Pod Security Policies(PSP) 。

但是有在關注 Kubernetes 的公告的人，就會發現 PSP 在 Kubernetes 1.21 版本標示為 deprecated，並且在 Kubernetes 1.25 版本將完全被移除 (fully removed)，取而代之的是使用 Pod Security Standards (PSS) 。這意味這如果你是使用原生的方式去撰寫這些管理的 Policies 的話，未來會需要花費一番功伕去升級、改寫這些 Policies，所以就開始研究第三方 (3rd-Party) 的規範管理工具。

♖ 環境

AWS EKS, Kubernetes Version: 1.21
OPA Gatekeeper, Version: release-3.7

♖ OPA 是什麼？和 OPA Gatekeeper 有什麼差別

建議可以先參照這幾篇文章：

由上而下，理解 OPA 以及 OPA Gatekeeper 的差別，會有比較詳細的背景知識。

在開發服務的時候，我們會需要注意到服務的 驗證(Authentication) 和 授權(Authorization) 這兩套機制要怎麼實作，區別如下：

Authentication（驗證）：確認使用者是否存在於系統當中，比方你在登入公司系統，系統會先確認你是否是這家公司的員工。
Authorization（授權）：根據使用者的角色來授予應有的權限，成功登入公司系統後，系統會根據你的職等，決定你可以看什麼資料、做什麼事情。

而 OPA 的概念就是要把 授權(Authorization) 的概念從服務中獨立出來，讓不同的服務都能夠呼叫同一個 OPA Server 做 授權(Authorization) 這件事，概念圖如下：

upload successful

比方說 API Server 接收到了一個 Request，在已經確認這個 Request 是由合法的使用者發出的請求後，API Server 會再發出一個請求到 OPA Server，確認這個 Request 要做的事情和不合乎規範，若合乎系統規範，回傳成功，反之則回傳失敗。

那 OPA Gatekeeper 又是什麼？ OPA Gatekeeper 封裝了 OPA 的程式碼，讓 OPA 可以以 Webhook Server 的方式運作在 Kubernetes 裡面，解決了 Kubernetes 各種部署的審核問題。當然 OPA 本身是可以不需要 Kubernetes 以 Daemon 的方式運行，比較通用的做法是透過程式碼呼叫 library 去實作 Policy [註：Policy 是用 Rego 語法寫的，來自於一種數據查詢語言 – Datalog]，比方說 Golang 有 Rego package 可以載來用。

差別如下，這是 Policy:

package k8s.labels

parameters.labels = {"front-end" : ["front-end", "dashboard"]}

deny[msg] {
    namespace := input.request.namespace
    required := {label | label := parameters.labels[namespace][_]}
    provided := input.request.object.metadata.labels["app"]
    not required[provided]
    msg := sprintf("Missing required label %v",[required])
}

這是 Kubernetes 用的 ConstraintTemplate :

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: podrequiredlabels
spec:
  crd:
    spec:
      names:
        kind: PodRequiredLabels
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package podrequiredlabels

        violation[{"msg": msg, "details": {"required_labels": required}}] {
          required := {label | label := input.parameters.labels[_]}
          provided := input.review.object.metadata.labels["app"]
          not required[provided]
          msg := sprintf("Missing required labels %v",[required])
        }

♖ 挑選 OPA Gatekeeper 的原因

在經過一番研究之後，目前在 CNCF 生態系中，關於 策略(Policies) 以及 治理(governance) 的工具，大宗分為兩支：

Open Policy Agent Gatekeeper(a.k.a OPA Gatekeeper)
Kyverno (發音類似於：凱 verno)

先簡短講一下兩者的差異性好了。沿用上面的 ConstraintTemplate，同樣規範 Pod 需要帶有特定 label 的情況來看，Kyverno 的寫法不需要額外學習新的語法，並且相容於 Kubernetes 原生的 yaml 撰寫方式：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
  annotations:
    policies.kyverno.io/title: Require Labels
    policies.kyverno.io/category: Best Practices
    policies.kyverno.io/severity: medium
    policies.kyverno.io/subject: Pod, Label
    policies.kyverno.io/description: >-
      Define and use labels that identify semantic attributes of your application or Deployment.
      A common set of labels allows tools to work collaboratively, describing objects in a common manner that
      all tools can understand. The recommended labels describe applications in a way that can be
      queried. This policy validates that the label `app.kubernetes.io/name` is specified with some value.      
spec:
  validationFailureAction: audit
  background: true
  rules:
  - name: check-for-labels
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "The label `app.kubernetes.io/name` is required."
      pattern:
        metadata:
          labels:
            app.kubernetes.io/name: "?*"

這張圖是 Kyverno 官方文件上描述的關係圖，非常清楚易懂：
upload successful

但是最後我還是選擇 OPA Gatekeeper 來研究，網路上的比較文章很多，OPA Gatekeeper 在星星數以及實際的使用人數上也略勝一籌。雖然 Kyverno 簡單易用，Cluster Policy 和沿用它的 Rules 之間的關係也寫得蠻清楚易懂。但正所謂由奢入儉難，學習了 Rego 語法後，未來若有不是部署在 Kubernetes 的服務，也適用於這套部署規範管理工具，而且難保服務變多之後會需要更精細的控制程度。

♖ Reference

♞ Kubernetes Pod Security Policy Deprecation: All You Need to Know
♞ Kyverno 介紹
♞ intro-to-gatekeeper-policies
♞ Open Policy Agent - REST API
♞ RBAC and PSP
♞ Differences between OPA and Gatekeeper for Kubernetes Admission Control
♞ Open Policy Agent – 快速導入 Authz 至 Microservice 架構

♖ 環境

♖ OPA 是什麼？ 和 OPA Gatekeeper 有什麼差別

♖ 挑選 OPA Gatekeeper 的原因

♖ Reference

♖ OPA 是什麼？和 OPA Gatekeeper 有什麼差別