Join Log in
Score:0
avatar Server

Custom root cert for kubeconfig files

jp flag
Chris G.

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.

53
0 + 0
Score:1
avatar Server
in flag
mdaniel

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

0 + 0
jp flag
Chris G.
Thanks for you answer - I think I will go with your recommendation using OpenID(OIDC). I will try to combine this https://github.com/micahhausler/k8s-oidc-helper with github https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.