enhancements
enhancements copied to clipboard
kubernetes
KEP-4317: PodIdentity certificates, PodCertificate volumes, and in-cluster kube-apiserver client certificates
This PR adds the initial content for KEP-4317, which outlines machinery for:
- Representing pod identities in X.509 certificates and certificate requests,
- Generically provisioning certificates to pods,
- Specifically provisioning kube-apiserver client certificates to pods, and
- Using pod identity certificates to authenticate to kube-apiserver,.
This KEP is still in the draft/discussion phase. Significant changes are anticipated based on review and discussion in SIG Auth.
- Issue link: https://github.com/kubernetes/enhancements/issues/4317
- Draft implementation: https://github.com/kubernetes/kubernetes/pull/121596
Is this related to ClusterTrustBundles?
They're intended to work together. It's not needed for the kube-apiserver client certificate use case, but if someone were to build a pod-to-pod mTLS solution on top of this, they would need to use both ClusterTrustBundle and PodCertificate projected volumes.
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle stale - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle rotten - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
Capturing some notes from discussion with Jordan:
- For Alpha, we are unsure about how much we want existing things that understand client certs to understand these new certs. To keep our options open, we will put a random UID as the CN, and not encode groups. In the future, we might decide to encode a meaningful CN and groups.
- New flag for pod client certificate CA, no sort of fallback logic.
- On kube-apiserver, continue to use one flag for all client certificate CAs.
- Use PEM in the PCR.
@ahmedtd please don't forget to creating a PRR file (see template in https://github.com/kubernetes/enhancements/blob/master/keps/prod-readiness/template/nnnn.yaml) and answering the questions, feel free to assign me for the PRR approval.
@ahmedtd please don't forget to creating a PRR file (see template in https://github.com/kubernetes/enhancements/blob/master/keps/prod-readiness/template/nnnn.yaml) and answering the questions, feel free to assign me for the PRR approval.
I added the yaml file to the PR. However, I don't see any questions in it. Are you referring to the PRR questions in the main KEP body?
Capturing some notes from discussion with Jordan:
- For Alpha, we are unsure about how much we want existing things that understand client certs to understand these new certs. To keep our options open, we will put a random UID as the CN, and not encode groups. In the future, we might decide to encode a meaningful CN and groups.
- New flag for pod client certificate CA, no sort of fallback logic.
- On kube-apiserver, continue to use one flag for all client certificate CAs.
- Use PEM in the PCR.
All of these points are now reflected in the text.
@soltysh
This holds, especially the rollout when you have api enablement + 3 various feature gates. Although I believe the overall recommendation will be to turn all at once.
I'm sorry, can you elaborate? Are you saying that I should go ahead and fill this section out?
@soltysh
This holds, especially the rollout when you have api enablement + 3 various feature gates. Although I believe the overall recommendation will be to turn all at once.
I'm sorry, can you elaborate? Are you saying that I should go ahead and fill this section out?
I mean that it would be nice to see this section filled in, but it's not a hard requirement for alpha. Although usually going through that kind of exercise allows unlocking potential problems, which then leads to better designs of the feature.
@soltysh approved PRR here https://github.com/kubernetes/enhancements/pull/4318#pullrequestreview-2354184037 but looks like the bot must have missed the GH event, tagging it manually.
[APPROVALNOTIFIER] This PR is APPROVED
Approval requirements bypassed by manually added approval.
This pull-request has been approved by: ahmedtd, enj
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
