kubeadm: Clusters built with kubeadm don't support basic auth
From @kelseyhightower on October 25, 2016 18:15
Some people are having trouble authenticating to the Kubernetes dashboard when the cluster is built with kubeadm. Seems like the deployed api server does not support basic auth, which makes it impossible to hit the Dashboard UI without using kubectl proxy.
Copied from original issue: kubernetes/kubernetes#35536
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 35 (15 by maintainers)
dex v2 is ready to go and I am sure @ericchiang and @rithujohn191 would be excited to support this happening. They can’t hack directly on this at the moment as they are super busy with Dex itself but the entire system is designed to run trivially as a deployment on top of Kubernetes and this is what we do for Tectonic.
@smarterclayton I don’t think anyone is talking about lock-in here, Dex is just built on top of the bog standard OIDC integration in API server and
kubectlthat went into 1.3.@pires Dex backs by Kubernetes TPRs and we could add an etcd backend but I feel like using TPRs is more correct.
Couple of “paths of exploration”. Also there is Keystone, Keycloak, and IAM integrations to consider.
One really useful point is ensuring some authentication and authorization can be local to a cluster (to isolate failure domains), while still being federated meaningfully.
I think having a couple of exploration to go down here makes sense. Dex is decoupled from Kube, the OpenShift OAuth server is partially decoupled but also has some integrations I think will be important in the long run. Being able to credibly integrate auth doesn’t necessarily mean locking into one solution.
Being a password managing product moves us into the territory of an authentication provider and that’s not the kind of product that I want to be. I’d prefer to use an authentication provider to get identity information. I don’t think that kube’s mission should expand to providing authentication and identity management solutions as part of administering container engines.
Making it easy to use an existing authentication provider: definitely. Maybe even choosing one as a “simple” default: possibly. Providing it as an in-tree option backed in the same persistent storage as our container orchestration: I don’t think this is reasonable.