Find out what is OPA getting as request from api-server?-CodePudding

We have OPA installed in our Kubernetes cluster. Not Gatekeeper. The "original" OPA...

I don't understand how I can look at what OPA is receiving as input request from the API-server ?
=> If I knew exactly what the payload looks like then writing the Rego would be simple.

I tried to use -v=8 option in kubectl to see the request and response from api-server like so:

$ 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]

Unfortunatly the above JSON payload doesn't match what I see in the different tutorials.

How is anybody able to write OPA rules for Kubernetes ???
Thx

CodePudding user response：

You have two options:

Run the OPA server with debug level logging:

opa run --server --log-level debug ...

This is obviously very noisy, so beware.
Run the server with decision logging enabled. This is almost always preferable, and allows you to either dump decisions (including input data) to console, or for production deployments, to a remote server aggregating the logs. The decision logging system is really the native way of doing this, and comes with a bunch of features, like masking of sensitive data, etc.. but if you just want something printed to the console, you can run OPA like:

opa run --server --set decision_logs.console=true ...