Auditing - proposal
JoshVanL opened this issue · 10 comments
Write a proposal on how we can expose requests to enable auditing and monitoring.
We should check first, how the audit log on the real apiserver looks like. E.g. what audit information is not available any more. I guess you are aware of this https://github.com/kubernetes/enhancements/blob/39b8b3966229a09a3abdf50fca13851e62dd54ba/keps/sig-auth/0014-dynamic-audit-configuration.md
What are you thinking about monitoring? A metrics endpoint?
@simonswine i'd love to work on this story, for compliance reason we would like to use the oidc-proxy and audit all the req/responses.
i've almost identified all the changes I need but i'm failing in setup kube-oidc-proxy in my staging cluster, do you have any other channel we can communicate faster than github issues?
@simonswine @JoshVanL i'm able to use the proxy deployed in the k8s cluster but i'm unable to use it locally.. and for rapid deployment cycles i need it running locally.. this are the options i am using:
--server="https://api.cluster.mydomain.com" \
--token="MY_TOKEN" \
--tls-cert-file="certs/certificate.crt" \
--tls-private-key-file="certs/key.pem" \
--oidc-issuer-url="https://dex.mydomain.com" \
--oidc-client-id="auth" \
--oidc-ca-file="certs/root" \
--oidc-groups-claim="groups" \
--v=5
i'm generating MY_TOKEN trying:
kubectl get secret/default-token-kg96x --namespace=kube-oidc-proxy -o jsonpath='{.data.token}' | base64 --decode
i'm receiving:
error: No Auth Provider found for name "oidc"
Hi @ltagliamonte-dd!
We have an internal planning meeting Friday and auditing is definitely on the agenda - I'm keen to see this happen to.
Regarding your problem, this is just a bug - I'm ganna put together a fix and backport it to 0.1. I'll open up an issue and put context what's happened there.
Added a fix @ltagliamonte-dd here #77
I guess you're using master instead of v0.1.1?
This issue came about as we removed k8s.io/kubernetes as a dependency
@JoshVanL do you want me to use v0.1.1 for my development or master?
Do you have a slack you can add me to so we can have faster iterations?
Not particularly, that should be fine - master should be quite stable atm.
Are you kubernetes.slack? That is probably the best place. I've also requested for a channel kubernetes/community#3944
When we put kube-oidc-proxy in path, we had to accept for the time being that we lose visibility of the real client IP. At our site we have other controls to mitigate that loss of client IP visibility. Kube API server does not have any support for XFF or similar at this time (nearest thing I found is this request for PROXY protocal support - kubernetes/kubernetes#76928).
The only other thing I had to do when introducing kube-oidc-proxy was adjust our Kube audit log Splunk queries to look at both username and impersonated username.
@JoshVanL thank you for working on this, but i think we should re-open this issue (or if you want i can open a new one)
My issue is more about having visibility in the exec sessions, having the same audit the api server already offers is nice but not a fully audit of what get processed by oidc-proxy.
Hi @ltagliamonte-dd :)
Indeed, this is the plan and I'm actively working on this in the background. The base auditing was definitely a pre-courser to this work. I'll open up an issue to track things.