OPA 中 kubernetes.admission 政策之間的隔離

Question

我使用 vanilla Open Policy Agent 作為 Kubernetes 上的部署來處理准入 webhook。

我不清楚多策略評估的行為，請參見以下示例：

## policy-1.rego

package kubernetes.admission

check_namespace {
   # evaluate to true
   namespaces := {"namespace1"}
   namespaces[input.request.namespace]
}

check_user {
    # evaluate to false
    users := {"user1"}
    users[input.request.userInfo.username]
}

allow["yes - user1 and namespace1"] {
  check_namespace
  check_user
}

.

## policy-2.rego

package kubernetes.admission

check_namespace {
   # evaluate to false
   namespaces := {"namespace2"}
   namespaces[input.request.namespace]
}

check_user {
    # evaluate to true
    users := {"user2"}
    users[input.request.userInfo.username]
}

allow["yes - user2 and namespace12] {
  check_namespace
  check_user
}

.

## main.rego

package system

import data.kubernetes.admission

main = {
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": response,
}

default uid = ""

uid = input.request.uid

response = {
    "allowed": true,
    "uid": uid,
} {
    reason = concat(", ", admission.allow)
    reason != ""
}
else = {"allowed": false, "uid": uid}

.

 ## example input
{
  "apiVersion": "admission.k8s.io/v1beta1",
  "kind": "AdmissionReview",
  "request": {
    "namespace": "namespace1",
    "userInfo": {
        "username": "user2"
    }
  }
}

.

## Results

"allow": [
    "yes - user1 and namespace1",
    "yes - user2 and namespace2"
]

似乎我的所有政策都被評估為一個平面文件，但我希望每項政策都將獨立於其他政策進行評估

我在這里想念什么？

Answer 1

文件對 OPA 沒有任何意義，但包有。 由於您的兩個策略都在kubernetes.admission模塊中定義，因此它們基本上將作為一個附加在一起。 這僅適用於您的情況，因為根據您的輸入， check_user和check_namespace分別評估為 undefined 。 如果他們沒有，您將看到有關沖突的錯誤消息，因為完整的規則無法評估不同的結果（即allow不能同時為true和false ）。

如果您更願意為每個政策使用單獨的 package，例如kubernetes.admission.policy1和kubernetes.admission.policy2 ，這不會是一個問題。 不過，您需要更新您的主要策略以從您的所有策略中收集allow規則的聚合。 就像是：

reason = concat(", ", [a | a := data.kubernetes.admission[policy].allow[_]])

這將遍歷kubernetes.admission中的所有子包，並從每個子包中收集allow規則結果。 這種模式稱為動態策略組合，我在 這里寫了一篇關於該主題的較長文本。

（作為旁注，您可能想要聚合拒絕規則而不是允許。據我所知，像 kubectl 這樣的客戶端不會從響應中打印出原因，除非它實際上被拒絕了......而且知道它通常不太有用為什么某事成功而不是失敗。如果您想了解更多有關請求成功或失敗的原因，您仍然可以查閱 OPA 決策日志）。