Enhancements: CertificateSigningRequest API

[liggitt]

CertificateSigningRequest API

• One-line enhancement description (can be used as a release note): CertificateSigningRequest API
• Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190607-certificates-api.md
• Primary contact: @liggitt
• Responsible SIGs: sig-auth
• Enhancement target (which target equals to which milestone):
  
  
  
  • Alpha release target v1.4
  
  
  • Beta release target v1.6
  
  
  • Stable release target v1.19
  
  

[liggitt]

/sig auth

[liggitt]

@jeremyrickard work is continuing on this API in 1.18, progressing in the beta state.

[jeremyrickard]

/milestone v1.18

[jeremyrickard]

Hey @liggitt as we were doing a review of all the items we were tracking last night, we noticed that the KEP for this is missing a test plan. Could you update the KEP and include that so that we can track for 1.18? Thanks and apologies for the very last minute request.

[liggitt]

Could you update the KEP and include that so that we can track for 1.18?

opened in https://github.com/kubernetes/enhancements/pull/1536

[VineethReddy02]

Hello, @liggitt, I'm 1.18 docs lead
Does this enhancement work planned for 1.18 require any new docs (or modifications to existing docs)? If not, can you please update the 1.18 Enhancement Tracker Sheet (or let me know and I'll do so)
If so, just a friendly reminder we're looking for a PR against k/website (branch dev-1.18) due by Friday, Feb 28th, it can just be a placeholder PR at this time. Let me know if you have any questions!

[liggitt]

Yes, there will doc updates for the work done in this feature in 1.18

[jeremyrickard]

Hey @liggitt,

Just a friendly reminder that code freeze for 1.18 is March 05, 2020.

As we track toward code freeze, please list out/link to any PRs you are working on toward graduating this enhancement!

[liggitt]

PRs in flight:

• https://github.com/kubernetes/kubernetes/pull/86933
• https://github.com/kubernetes/kubernetes/pull/86476

[jeremyrickard]

Thanks @liggitt 🙇

[munnerz]

Additional PR in-flight for tracking: https://github.com/kubernetes/kubernetes/pull/88246

[VineethReddy02]

Hello @liggitt
We are close to the docs placeholder PR deadline against the dev-1.18 branch. Having a placeholder PR in place will definitely help us in tracking enhancements much better.

Thanks! :)

[jeremyrickard]

Thanks for getting those PRs merged @liggitt @munnerz

Anything else to go before code freeze, or are you good now?

[liggitt]

All the k/k PRs I'm aware of are complete. The docs PR is outstanding.

[jimmyjones2]

I've read the proposal, is the plan in the future for this to be able to automatically provision server certificates for services (like OpenShift) and client certificates for service accounts to be used by user applications?

[liggitt]

/milestone v1.19

[liggitt]

1.19 targeted work:

• https://github.com/kubernetes/enhancements/pull/1691
• https://github.com/kubernetes/kubernetes/pull/90191

[msedzins]

Hey there @liggitt -- 1.19 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating in 1.19?

In order to have this part of the release:

1. The KEP PR must be merged in an implementable state
2. The KEP must have test plans
3. The KEP must have graduation criteria.

The current release schedule is:

• Monday, April 13: Week 1 - Release cycle begins
• Tuesday, May 19: Week 6 - Enhancements Freeze
• Thursday, June 25: Week 11 - Code Freeze
• Thursday, July 9: Week 14 - Docs must be completed and reviewed
• Tuesday, August 4: Week 17 - Kubernetes v1.19.0 released

If you do, I'll add it to the 1.19 tracking sheet (http://bit.ly/k8s-1-19-enhancements). Once coding begins please list all relevant k/k PRs in this issue so they can be tracked properly. 👍

Thanks!

[liggitt]

yes, the plan is for this to graduate in 1.19

[msedzins]

Awesome, thank you! I'll go ahead and add it to the tracking sheet :)

[palnabarun]

/stage stable
/milestone v1.19

[howardjohn]

@liggitt can we clarify if Kubernetes intends to support user applications requesting certs signed by the Kubernetes CA using this API, or if the Kubernetes CA is intended only for internal use and this API is to be used with other implementors (like cert-manager) for user applications? Currently this seems to be a bit of a grey area.

Istio currently is using it in this manner so we want to ensure we come up with alternative plans if this will not work in the future. See https://github.com/istio/istio/issues/22161 for a lot of discussion around this.

[liggitt]

The currently defined kubernetes.io signers are described at https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers:

• kubernetes.io/kube-apiserver-client and kubernetes.io/kube-apiserver-client-kubelet sign certificates valid for use as client certificates recognized by kube-apiserver
• kubernetes.io/kubelet-serving signs serving certificates valid for kube-apiserver -> kubelet connections
• kubernetes.io/legacy-unknown signs certificates with undefined trust properties, and will only be supported via the v1beta1 CertificateSigningRequest API.

The API explicitly allows requesting a named signer in a CertificateSigningRequest, so that other signers can make use of it. Working with SPIFFE to define one or more spiffe.io/... signerNames based on https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md seems like a reasonable thing to build on top of this API. Part of defining the spiffe.io/... signerNames would involve describing how audiences for the issued certificates obtain/maintain trust roots. Istio could then use the CSR API as an integration point to request certificates for a well-defined spiffe.io/... signerName.

To add support for kubernetes-specific use cases like pod-specific client certificates or serving certificates valid for pods backing services, I'd see those as proposals building on top of this API, describing a distinct kubernetes.io/... signerName (along with the trust distribution mechanism where appropriate).

[howardjohn]

@liggitt makes sense, so the API will allow extension for our use case in general, but without extension we would not be supported, as legacy-unknown is removed. I am assuming using a signer like kubernetes.io/kube-apiserver-client for our own purposes is frowned upon as well? So if we want to continue to use this with v1, we should submit some proposals for this? Is that accurate?

Note - while we will possibly want to do our full spiffe mTLS certificate stuff with this stuff in the future, our current usage is actually just to create certificates to validate the identity of the Istio control plane to retrieve the mTLS certs (essentially for bootstrapping). We just create a DNS cert for istiod.istio-system.svc and "distribute" the root cert by using the serviceaccount/ca.crt mounted in the pod (which we understand is a hack).

Thanks for your help

[liggitt]

continuing discussion in https://github.com/istio/istio/issues/22161 to keep this issue lower-traffic :)

[msedzins]

Hi @liggitt ,

Note that recently the KEP format has changed.

1620 merged recently, adding production readiness review questions to the KEP template. Please take this opportunity to reformat your KEP and also answer the questions add to the template in that PR.

Thanks!

[neolit123]

@msedzins does this apply to all new KEP PRs that are in flight or only to those for core APIs?

[msedzins]

Hi @neolit123 , it applies to all KEPs that want to be part of the release. But for v.1.19 release the updated KEP format is not mandatory.

We appreciate if you manage to update your KEP so that it conforms to the new format but if you prefer not to do that for any reason - that's fine.

Regards,
Mirek

[savitharaghunathan]

Hi @liggitt - I am Savitha,1.19 Docs lead. Does this enhancement work planned for 1.19 require any new docs (or modifications to existing docs)? If not, can you please update the 1.19 Enhancement Tracker Sheet, or let me know, I can do it for you :)
If docs are required, just a friendly reminder that we are looking for a PR against k/website (branch dev-1.19) due by Friday, June 12, it can just be a placeholder PR at this time. Let me know if you have any questions!

[msedzins]

Hi @liggitt , enhancement shadow here -- Can you please link to all the implementation PR's here - k/k or otherwise? :slightly_smiling_face:

---

The current release schedule is:

• ~Monday, April 13: Week 1 - Release cycle begins~
• ~Tuesday, May 19: Week 6 - Enhancements Freeze~
• Thursday, June 25: Week 11 - Code Freeze
• Thursday, July 9: Week 14 - Docs must be completed and reviewed
• Tuesday, August 4: Week 17 - Kubernetes v1.19.0 released

[msedzins]

Hi @liggitt, just a friendly reminder on my question above.

[liggitt]

I will link PRs here and update the KEP format as I have the opportunity to.

[savitharaghunathan]

Hi @liggitt , we are 12 days away from docs placeholder PR deadline. Does this PR needs any docs update? If so, placeholder PR against dev-1.19 branch is due by June 12th. Thanks!

[liggitt]

the docs for this feature will be included in https://github.com/kubernetes/website/pull/21108

[savitharaghunathan]

the docs for this feature will be included in kubernetes/website#21108

Thanks for the update @liggitt :)

[msedzins]

Hi @liggitt, thank you very much for your update.

[msedzins]

Hi, @liggitt

This is a follow-up to the communication that went out to k-dev today. There has been a revision to the release schedule of v1.19 as follows.

Thursday, July 9th: Week 13 - Code Freeze
Thursday, July 16th: Week 14 - Docs must be completed and reviewed
Tuesday, August 25th: Week 20 - Kubernetes v1.19.0 released
Thursday, August 27th: Week 20 - Release Retrospective

You can find the revised Schedule in the sig-release Repo

Please let me know if you have any questions. 🖖

[liggitt]

Doc PR is ready for review

[msedzins]

Hi @liggitt , from what I can see this enhancement is Code complete so it's ready for Code freeze deadline which happens July 9th.
Please let me know if you think otherwise and there are any risks for that enhancement to be included in v.1.19.

[liggitt]

yes, this is code complete

[kikisdeliveryservice]

Hi @liggitt !

Enhancements Lead here. It looks like this KEP went stablein 1.19. Could you please update the KEP to have a status of implemented? Afterwards you can also close this issue once the PR updating it has merged?

Thanks!
Kirsten

[liggitt]

KEP update in https://github.com/kubernetes/enhancements/pull/1984

/close

[k8s-ci-robot]

@liggitt: Closing this issue.

In response to this:

KEP update in https://github.com/kubernetes/enhancements/pull/1984

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.