kubeadm: Node fails to join if master's kube-apiserver has --anonymous-auth=false and basic auth
Is this a request for help?
No
What keywords did you search in kubeadm issues before filing this one?
Yes, could not find anything related to passing username/password for kube-apiserver
Is this a BUG REPORT or FEATURE REQUEST?
BUG REPORT
Versions
kubeadm version (use kubeadm version):
v1.11.3
Environment:
- Kubernetes version (use
kubectl version): v1.11.3 - Cloud provider or hardware configuration: Manually deployed coreos VMs in CloudStack
- OS (e.g. from /etc/os-release): coreos 1800.7.0
- Kernel (e.g.
uname -a): Linux k8s-kluster-k8s-master 4.14.63-coreos #1 SMP Wed Aug 15 22:26:16 UTC 2018 x86_64 QEMU Virtual CPU version 1.5.3 GenuineIntel GNU/Linux - Others:
What happened?
I deployed a master k8s coreos VM, after doing kubeadm init I changed the kube-apiserver yml to support basic auth using - --basic-auth-file=/etc/kubernetes/pki/auth.csv and disable anonymous auth using --anonymous-auth=false. After kube-apiserver was restarted, on the worker/node I installed the dependencies, and did /opt/bin/kubeadm join <ip>:6443 --token a4qgg6.84hjisyqzvth7yp6 --discovery-token-unsafe-skip-ca-verification I get:
[discovery] Trying to connect to API Server "10.1.1.59:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.59:6443"
[discovery] Failed to request cluster info, will try again: [Unauthorized]
With debug -v9, I can see the error is due to the apiserver trying to get the basic auth:
I0910 20:31:56.104645 6343 round_trippers.go:386] curl -k -v -XGET -H "Accept: application/json, */*" -H "User-Agent: kubeadm/v1.11.3 (linux/amd64) kubernetes/a452946" 'https://10.1.1.59:6443/api/v1/namespaces/kube-public/configmaps/cluster-info'
I0910 20:31:56.149999 6343 round_trippers.go:405] GET https://10.1.1.59:6443/api/v1/namespaces/kube-public/configmaps/cluster-info 401 Unauthorized in 45 milliseconds
I0910 20:31:56.150422 6343 round_trippers.go:411] Response Headers:
I0910 20:31:56.150439 6343 round_trippers.go:414] Content-Type: application/json
I0910 20:31:56.150453 6343 round_trippers.go:414] Www-Authenticate: Basic realm="kubernetes-master"
I0910 20:31:56.150521 6343 round_trippers.go:414] Content-Length: 129
I0910 20:31:56.150580 6343 round_trippers.go:414] Date: Mon, 10 Sep 2018 20:31:56 GMT
I0910 20:31:56.160465 6343 request.go:897] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}
[discovery] Failed to request cluster info, will try again: [Unauthorized]
What you expected to happen?
Either kubeadmin join prompts for the basic auth username/password, or allows a way to pass the username/password. I think it will be useful for people who may want to deploy nodes in future for a k8s cluster whose kube-apiserver may not allow anonymous requests.
How to reproduce it (as minimally and precisely as possible)?
See above ^^.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 31 (21 by maintainers)
/assign /lifecycle active
will get to this after kubeCon
i’m sure the kubadm team wouldn’t mind examining a detailed proposal e.g. in a google doc.
we had a talk about
--anonymous-auth=falseduring the kubeadm office hours meeting last week VOD/timestamp is here: https://youtu.be/XNOQS8JByxM?t=1840and we realized that it’s pretty much unsupported and even if we add basic auth your cluster will start failing liveness probe checks. it’s a design problem in k8s, see: https://github.com/kubernetes/kubeadm/issues/798#issuecomment-470579937
so while basic auth itself is not something we want to add,
--anonymous-auth=falsewill also fail unless you patch your control-plane manifests.closing this as a unsupported. again,
--anonymous-auth=true(default) is already secure. /closewhen join work node, kubeadm uses bootstrap token to access kube-apiserver, it will be transferred to anonymous user, but you set --anonymous-auth=false.
I personally don’t think that the default
--anonymous-auth=trueis secure. People host/use kubernetes cluster on publicly hosted cloud providers, many of such k8s apiservers are accessible over the public IP by default. The default allows anyone with the knowledge of the public IP address of such a k8s cluster to find the version and other details (that could be used to exploit a vulnerability) that I may not want to expose, at the same time provide a mechanism to join the cluster/master. I think I’ll explore non-token based approach to solve my problem.--anonymous-auth=trueis not exactly insecure, so if someone is setting--anonymous-auth=falsethey have to understand the implications.