kubectl-debug
kubectl-debug copied to clipboard
add an extend apiserver as the gateway
kubectl-debug
connect to the node agent directly, which is not secure. We should provide an extend apiserver to do centralized authorization & authentication. Extend apiserver should be an opt-in component, we can always use the simplest setup just like now.
The extend apiserver will also proxy the debug connection like kube apiserver, which addresses the inaccessible hostIP issue in #2
JOOC, how are you planning on doing authentication? Is it possible to piggy-back off of RBAC and have users authenticate with the user in their kubeconfig? Or will you need to implement your own authentication flow?
I've been thinking about this for a project I'm working on, so would love to hear your thoughts!
Ah, or are you planning on using this thing? https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
There's so many concepts in Kubernetes..
To be honest, I am not familiar with authz & authn in kubernetes. But yes, I plan to build an Extension API Server to serve as the gateway for kubectl-debug
, and the idea is mainly inspired by this document. The key API to integrate with Kubernetes RBAC is SubjectAccessReview
.
The same mechanism can be implemented in the agent, too. Kubelet does so for node
resources.
Ah that looks really interesting, thanks. Looking forward to reading more.
On Jan 2, 2019, at 11:51 PM, Yeh-lei Wu [email protected] wrote:
To be honest, I am not familiar with authz & authn in kubernetes. But yes, I plan to build an Extension API Server to serve as the gateway for kubectl-debug, and the idea is mainly inspired by the this document. The key API to integrate with Kubernetes RBAC is SubjectAccessReview.
The same mechanism can be implemented in the agent, too. Kubelet does so for node resources.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Maybe we could imagine an operator pattern waiting for new debug session asked via CRDs ? CRDs have full RBAC control and the operator could secure things enough with a service account and a Pod Security Policy. Maybe also some annotations on the pod to expliclty authorize debugging (meaning that if you can modify this annotation, then it's ok to debug this pod) ?
@jseguillon Great idea at a glance! I will carefully consider this idea days after.