Home / server / Questions / 1080471
Accepted
Chris G.
Asked: 2021-10-14 13:20:48 +0800 CST

Custom root cert for kubeconfig files

  • 772

Running kubeadm init phase certs apiserver --config kubeadm.yaml

Is it possible to have multiple/custom root certificate to be used for group of users/kubectl/config files?

I am asking because, I would like to give access, on a per project basis - and then afterwards remove the custom root cert - but keep the the "original" root cert for special kubectl administrators.

I have seen that you can use ssh tunneling as a first line of defence, to protect the root certificate public key. But you still need to distribute the public signed cert, even it is behind the ssh public private key. Therefore maybe there is a way around using ssh tunneling - and putting a custom cert in certificatesDir: /etc/kubernetes/pki?

kubeadm.yaml

apiServer:
  extraArgs:
    authorization-mode: Node,RBAC
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta1
certificatesDir: /etc/kubernetes/pki

I know you can use --insecure-skip-tls-verify in config file, but it seems like a bad idea.

kubernetes kubeadm

1 Answers

  1. Best Answer

    Is it possible to have multiple/custom root certificate to be used for group of users/kubectl/config files?

    No, there's only one "root" certificate, that's why it's called the root.

    However, x509 is a chain of trust, meaning it's quite possible to issue subordinate CAs under that root, then issue the user certificates under those CAs, choosing to remove the subordinate CAs when the project ends, which will orphan all those leaf certificates. Be aware that to the very best of my knowledge changing the certificates or their chain requires restarting the control-plane, since it does not hot-reload those certificate files. I believe there's a GitHub issue for it, just like all the rest of the 15,000 of them

    The other choice, depending on your needs, is to issue short leases for the user certs such that the "revocation" process isn't so much altering the x509 chain of trust as much as it is just failing to reissue a credential. That's closer to the Hashicorp Vault and Let's Encrypt school of thought

    I have personally implemented the 2nd one (using Vault), but I believe the first one is possible because the apiserver uses x509 chains for some of its in-cluster component auth, so I don't see why you couldn't similarly take advantage of that mechanism

    I know this isn't what you asked, but using x509 for transient auth like that is the road to ruin because -- as you are experiencing -- both sides, issuing and revocation, are a huge pain. If it's at all available to you, the OIDC auth mechanism is much easier to reason about and kubectl has more-or-less built-in support for it

    • 1