Use multiple contexts with same user-name in kubectl config

Viewed 2729

I want to use multiple clusters with my kubectl so I either put everything into one config or add one config file per cluster to the KUBECONFIG env variable. That's all fine.

My problem is now, that I've users with the same user-name for each cluster but they use different client-key-data for each cluster (context) but somehow the context uses that user-name so it's not clear which user belongs to which cluster.

Better give an example:

Cluster 1:

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: https://10.11.12.13:8888
  name: team-cluster
contexts:
- context:
    cluster: team-cluster
    user: kubernetes-admin
  name: kubernetes-admin@team-cluster
users:
- name: kubernetes-admin
  user:
    client-certificate-data: XXYYYZZZ
    client-key-data: XXXYYYZZZ

Cluster 2:

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: https://10.11.12.14:8888
  name: dev-cluster
contexts:
- context:
    cluster: dev-cluster
    user: kubernetes-admin
  name: kubernetes-admin@dev-cluster
users:
- name: kubernetes-admin
  user:
    client-certificate-data: AABBCC
    client-key-data: AABBCC

As you see, in both cluster there's a user with name kubernetes-admin but from the context it's not clear which of those. Maybe there's another way to give it a unique identifier that is used by the context.

Maybe the solution is obvious but I've not found any example for such a case. Thanks for any help.

3 Answers

I had same issue with my config and found out that name in users is not username used to log in - its just name used to identify user section in config. In Your case only cert key is used to know who You are. So You can use:

users:
- name: kubernetes-admin-1
  user:
    client-certificate-data: AABBCC
    client-key-data: AABBCC
- name: kubernetes-admin-2
  user:
    client-certificate-data: XXYYYZZZ
    client-key-data: XXXYYYZZZ

and refer to that in context just by key:

contexts:
- context:
    cluster: dev-cluster
    user: kubernetes-admin-1

Full config:

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: https://10.11.12.13:8888
  name: team-cluster
- cluster:
    server: https://10.11.12.14:8888
  name: dev-cluster
contexts:
- context:
    cluster: team-cluster
    user: kubernetes-admin-1
  name: kubernetes-admin@team-cluster
- context:
    cluster: dev-cluster
    user: kubernetes-admin-2
  name: kubernetes-admin@dev-cluster
users:
- name: kubernetes-admin-1
  user:
    client-certificate-data: XXYYYZZZ
    client-key-data: XXXYYYZZZ
- name: kubernetes-admin-2
  user:
    client-certificate-data: AABBCC
    client-key-data: AABBCC

For auth methods that require username it's used something like this:

users:
- name: kubernetes-admin-with-password
  user:
    username: kubernetes-admin
    password: mySecretPass

Using more than one kubeconfig is not much comfortable - you need to specify them for each command. You can have as much contexts and users if You want in one config and select right context (and save selected context as default).

If you have multiple kubeconfig files in the KUBECONFIG variable, then kubectl internally merges them before usage (see here). So, if you have two users with the same name in your kubeconfig files, they will probably override each other and you get either one or the other.

The solution is to either use different names for the users in the various kubeconfig files, or to explicitly specify one of the kubeconfig files, e.g. kubectl --kubeconfig dev-cluster.conf or having only a single kubeconfig file in the KUBECONFIG variable at a time.

In general, I would recommend the first approach and use a unique name for each different set of credentials (i.e. user) across your entire local configuration.

User in kubeconfig doesn't matter it is used as a reference for respective context. actually the common-name(CN) from client cert being used for authorization.

Working config: (i copied all clusters ca,certs and keys to $HOME/pki dir)

apiVersion: v1
kind: Config
current-context: "c1"
preferences: {}
clusters:
- cluster:
    certificate-authority: ../pki/c1_ca.pem
    server: https://20.100.1.10:6443
  name: c1
- cluster:
    certificate-authority: ../pki/c2_ca.pem
    server: https://20.100.1.8:6443
  name: c2
- cluster:
    certificate-authority: ../pki/c3_ca.pem
    server: https://20.100.1.11:6443
  name: c3
contexts:
- context:
    cluster: c1
    namespace: default
    user: c1
  name: c1
- context:
    cluster: c2
    namespace: default
    user: c2
  name: c2
- context:
    cluster: c3
    namespace: default
    user: c3
  name: c3
users:
- name: c1
  user:
    client-certificate: ../pki/c1_client_cert.pem
    client-key: ../pki/c1_client_key.pem
- name: c2
  user:
    client-certificate: ../pki/c2_client_cert.pem
    client-key: ../pki/c2_client_key.pem
- name: c3
  user:
    client-certificate: ../pki/c3_client_cert.pem
    client-key: ../pki/c3_client_key.pem
Related