Load of users with client-certificate and client-key paths
hirishh opened this issue · comments
Hello all,
I was playing with the official python and c library and there is a difference in how the kubeconfig is loaded.
For example if we have a kubeconfig like this:
users:
- name: userA
user:
client-certificate-data: LS0tLS1C...S0tCg==
client-key-data: LS0tLS1CRU...LQo=
- name: userB
user:
client-certificate: /path/to/client.crt
client-key: /path/to/client.key
The python lib is able to load both users, instead the C lib is able to load only userA. I've checked the code and indeed the load of the second variant of the configuration is not implemented.
Is it a known limitation of the C lib?
I'm pretty sure that multiple users are loaded:
https://github.com/kubernetes-client/c/blob/master/kubernetes/config/kube_config_yaml.c#L285
However, only the current user (selected by the current context in the kubeconfig file) will be used for authentication.
Are you looking to be able to chose a different user than the current user in the kubeconfig file?
Or does the python client somehow try both users (that would be surprising)
If you can clarify what your use-case is, we may be able to help.
(alternately, we may be able to guide you to create a PR to add more functionality :)
Thank you for your reply. I was not clear enough about my use case. Sorry.
Both the C lib and the python lib are loading the current context. During my tests I'm switching the current context between userA and userB via kubectl (kubectl config use-context userA-context). Both users have the same rights via RBAC on a specific namespace. Python Lib are processing fine both userA and userB requests (so it loads both base64 and file certs).
The C lib instead loads correctly only when the context is userA with base64 encoded certificates. In the C library the load of certificates by file is not implemented and while using userB-context it calls api with anonymous user so I get 403 Forbidden.
It should be easy to check for the existence of client-certificate and client-key properties and do fopen of them. I could try to implement it indeed.
It's simple to reproduce this with minikube. After minikube start it sets the current context with minikube user with auth by file paths like userB. Then, if you try to run the list_pod example (https://github.com/kubernetes-client/c/blob/master/examples/list_pod/main.c) you get 403 Forbidden.
Ok, I will try to reproduce this, if you have cycles to fix we'd gladly take a PR, but we'll otherwise get to it eventually.
@hirishh thanks for the PR and apologies, I misinterpreted the problem you were reporting, very much appreciate the fast PR!
Closing this via #167