У нас установлен OPA в нашем кластере Kubernetes. Не привратник. "Оригинальная" ОПА...
Я не понимаю, как я могу посмотреть, что OPA получает в качестве входного запроса от API-сервера?
=> Если бы я точно знал, как выглядит полезная нагрузка, то написать Rego было бы просто.
Я попытался использовать опцию -v=8
в kubectl
, чтобы увидеть запрос и ответ от api-сервера следующим образом:
$ kubectl get pod -v=8
...
GET https://xxxx.k8s.ovh.net/api/v1/namespaces/default/pods?limit=500
...
Request Headers: Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json
...
Response Body: {"kind":"Table","apiVersion":"meta.k8s.io/v1","metadata":{"resourceVersion":"37801112226"},"columnDefinitions":[{"name":"Name","type":"string","format":"name","description":"Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/identifiers#names","priority":0},{"name":"Ready","type":"string","format":"","description":"The aggregate readiness state of this pod for accepting traffic.","priority":0},{"name":"Status","type":"string","format":"","description":"The aggregate status of the containers in this pod.","priority":0},{"name":"Restarts","type":"string","format":"","description":"The number of times the containers in this pod have been restarted and when the last container in this pod has restarted.","priority":0},{"name":"Age","type [truncated 4024 chars]
К сожалению, указанная выше полезная нагрузка JSON не соответствует тому, что я вижу в разных руководствах.
Как кто-нибудь может написать правила OPA для Kubernetes ???
Спасибо
У вас есть два варианта:
Запустите сервер OPA с ведением журнала уровня отладки:
opa run --server --log-level debug ...
Это, очевидно, очень шумно, так что будьте осторожны.
Запустите сервер с ведением журнала решений. Это почти всегда предпочтительнее и позволяет либо выводить решения (включая входные данные) на консоль, либо для производственных развертываний на удаленный сервер, собирающий журналы. Система регистрации решений — это на самом деле родной способ сделать это, и она поставляется с кучей функций, таких как маскирование конфиденциальных данных и т. д., но если вы просто хотите что-то напечатать на консоли, вы можете запустить OPA, например:
opa run --server --set decision_logs.console=true ...