Understanding how Kubernetes Api Server authenticates kubectl admin requests

7/19/2018

I have a k8s cluster created with kubeadm. It's kube-apiserver has the following configuration:

spec:
  containers:
  - command:
    - kube-apiserver
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --insecure-port=0
    - --enable-bootstrap-token-auth=true
    - --requestheader-allowed-names=front-proxy-client
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --allow-privileged=true
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
    - --advertise-address=10.0.0.52
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --requestheader-username-headers=X-Remote-User
    - --service-cluster-ip-range=10.96.0.0/12
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    - --secure-port=6443
    - --authorization-mode=Node,RBAC
    - --etcd-servers=https://127.0.0.1:2379
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key

I am trying to undertand how kubectl requests (with the generated admin kubeconfig file) are authenticated/authorized.

First off, there is this user info in the kubeconfig file:

users:
- name: kubernetes-admin
  user:
    client-certificate-data: XXXX
    client-key-data: YYYY

I have checked that this client certificate is issued to an organization system:masters and common name kubernetes-admin.

The authorization part is kind of clear, there is a ClusterRoleBinding definition that assigns the cluster-admin role to the system:masters group.

What I don't get is how the kubectl requests are authenticated (I don't see any authentication configuration in the kube-apiserver configuration), can you explain it in detail?

-- codependent
kubeadm
kubernetes

1 Answer

7/19/2018

Just found this in the kube-apiserver documentation:

--client-ca-file string If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.

So API requests that present a client certificate are authenticated if they are signed by one of the configured ca files.

-- codependent
Source: StackOverflow