When developing rules for the proxy, it can be frustrating to get no information back out for a failed request that you expected to succeed.
We could provide an API, kind of like SubjectAccessReview, that client can talk to debug a request.
Strawman design:
apiVersion: authzed.com/v1alpha1
kind: ProxyRuleDebug
spec:
verb: get | list | etc
resource: pods
apiVersion: v1
# for requests that require a body:
body:
apiVersion: v1
kind: Pod
spec:
containers: [ ... ]
status:
matchedRules:
# showing the check resolved from the request
- check: namespace:foo#create_pod@user:evan.
result: false
# show the list of values generated as a prefilter
- prefilter:
- foo/bar
- foo/baz
- foo2/baz2
This new API should be protected; perhaps by requiring an annotation with a specific preshared key:
Note that for this to provide detailed debug info, it should run the actual request; i.e. any writes will result in changes to the backing SpiceDB and kube-apiserver.
Like SubjectAccessReview, this object isn't stored anywhere, the response is ephemeral.
When developing rules for the proxy, it can be frustrating to get no information back out for a failed request that you expected to succeed.
We could provide an API, kind of like SubjectAccessReview, that client can talk to debug a request.
Strawman design:
This new API should be protected; perhaps by requiring an annotation with a specific preshared key:
Note that for this to provide detailed debug info, it should run the actual request; i.e. any writes will result in changes to the backing SpiceDB and kube-apiserver.
Like
SubjectAccessReview
, this object isn't stored anywhere, the response is ephemeral.