search

swiftkube / client

Swift client for Kubernetes
Apache License 2.0
129 stars 20 forks source link

Support `exec` authentication plugin #5

Open t089 opened 3 years ago

t089 commented 3 years ago

k8s.io/client-go and tools using it such as kubectl and kubelet are able to execute an external command to receive user credentials. Have you thought about supporting this feature for this client implementation as well? For example, for AWS managed EKS clusters, you need to call aws eks get-token to obtain an (expiring) k8s bearer token to access the cluster from your development machine. For now this can be done before creating a client instance and the use the result as the bearer token.

iabudiab commented 3 years ago

Hey 👋 sorry for the delayed reply. I was trying to enjoy the last couple of days in my short vacation 😬

Yes, I've thought about this and it's currently not on the "near" roadmap, because I want to focus on the whole API part first, then proper CRD support second.

IMHO, supporting the exec auth only makes sense in cli or desktop apps, which should handle this scenario. This client can be used in such apps with no problem, and it would be the responsibility of the wrapping app/tool to handle the external process call, parsing the response, mapping it to a client-config instance and passing it to the client init. This is what kubectl does.

Having said that, we could however provide an abstraction for the exec plugin, that is processed by an external auth plugin implementation. If you want to, we could bounce some ideas around 😉

t089 commented 3 years ago

Hey, yes, makes sense. The only problem with the external approach is, that if the token expires, you have to recreate the whole client instance and make sure that only this new instance is used in the app. But I totally get that this is not high priority at the moment and would also be fine with closing the issue for now.

iabudiab commented 3 years ago

Token expiry could be handled by a callback through the plugin abstraction API, i.e. the external implementation should be able to create a new authentication and also refresh it when the client reports an auth error. This would however mean, that the client config should become mutable. No need to close the issue, it's not like there is too many, yet 😉