Kubeadm: apiServerExtraArgs should be appended to kube-api pod definition not prepended

[iMartyn]

BUG REPORT

Versions

Kubeadm 1.8.5

Environment:

• kubernetes version : 1.8.5
• cloud : minikube (but any)
• OS: boot2docker (but any)
• Kernel: 4.9.13 (but any)
• Other: minikube v0.24.1 (but again, any)

What happened?

Minikube translates --extra-config=apiserver.authorization-mode=AlwaysAllow into apiServerExtraArgs and kubeadm reads this configuration and generates a list of args to pass to kube-api-server pod. It however PREpends these and kube-api-server overrides previous arguments with later arguments.

This means that the following command :
minikube --kubernetes-version v1.8.5 start --bootstrapper kubeadm --extra-config=apiserver.authorization-mode=AlwaysAllow
creates a cluster with RBAC enabled and the following api-server commandline running inside the container :
kube-apiserver --authorization-mode=AlwaysAllow --requestheader-group-headers=X-Remote-Group --service-cluster-ip-range=10.96.0.0/12 --service-account-key-file=/var/lib/localkube/certs/sa.pub --tls-private-key-file=/var/lib/localkube/certs/apiserver.key --secure-port=8443 --proxy-client-cert-file=/var/lib/localkube/certs/front-proxy-client.crt --allow-privileged=true --requestheader-allowed-names=front-proxy-client --tls-cert-file=/var/lib/localkube/certs/apiserver.crt --kubelet-client-certificate=/var/lib/localkube/certs/apiserver-kubelet-client.crt --enable-bootstrap-token-auth=true --insecure-port=0 --requestheader-username-headers=X-Remote-User --requestheader-extra-headers-prefix=X-Remote-Extra- --kubelet-client-key=/var/lib/localkube/certs/apiserver-kubelet-client.key --proxy-client-key-file=/var/lib/localkube/certs/front-proxy-client.key --admission-control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --advertise-address=192.168.99.100 --client-ca-file=/var/lib/localkube/certs/ca.crt --requestheader-client-ca-file=/var/lib/localkube/certs/front-proxy-ca.crt --authorization-mode=Node,RBAC --etcd-servers=http://127.0.0.1:2379

What you expected to happen?

The cluster should be running with full access, no RBAC.

How to reproduce it (as minimally and precisely as possible)?

Run minikube with --bootstrapper kubeadm --extra-config=apiserver.authorization-mode=AlwaysAllow and attempt to create a service from within a pod.

Anything else we need to know?

https://github.com/kubernetes/minikube/issues/2342 is a colleagues' report on minikube's github so that they can track the issue, but I belive it to be in kubeadm itself.

[luxas]

I think this is working well as-is, but in the RBAC case, kubeadm enforces RBAC no matter what you specify, so if you want to disable it you need to create a permissive role instead: https://kubernetes.io/docs/admin/authorization/rbac/#permissive-rbac-permissions

However, that is not recommended.

[erayaslan]

Uhm, why the push back? This is a valid bug report. In my case

apiServerExtraArgs:
  authorization-mode: "RBAC"

becomes a noop while running kubeadm init --config kubeadminit.yaml

[iMartyn]

IMO it's a bug and the fix is simple. APPEND extra arguments, don't PREPEND.

[temujin9]

@luxas We, respectfully, disagree that this is "working well as is". kubeadm enforcing RBAC is exactly what we're saying is the bug.

Please reopen this issue; it is still an issue, and we'd like to see it fixed.

[fabriziopandini]

I think that we should preserve a consistent behaviour for all the extra args instead of designing specific exceptions for each component/flag like e.g. apiServerExtraArgs.authorization-mode in this case.
Accordingly IMO this discussion should be generalised and moved into #911

[iMartyn]

Whilst moving the discussion to there (which is an extremely abstract description that us probably not clear enough for most people who are facing the issue) is one thing, I have to agree with @temujin9, this bug should remain open. @fabriziopandini / @luxas please re-open this bug.