Skip to content

Add section on supporting intermediate certificates #1615

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Add section on supporting intermediate certificates #1615

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d861945
Add section on supporting intermediate certificates
jackkleeman Mar 15, 2020
05ba769
Wrap some lines
jackkleeman Mar 20, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions keps/sig-auth/20190607-certificates-api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,7 @@ status: implementable
- [Sequence of an Issuance](#sequence-of-an-issuance)
- [Signers](#signers)
- [Limiting approval and signer powers for certain signers.](#limiting-approval-and-signer-powers-for-certain-signers)
- [Supporting intermediate certificates.](#supporting-intermediate-certificates)
- [CertificateSigningRequest API Definition](#certificatesigningrequest-api-definition)
- [Manual CSR Approval With Kubectl](#manual-csr-approval-with-kubectl)
- [Automatic CSR Approval Implementations](#automatic-csr-approval-implementations)
Expand Down Expand Up @@ -235,6 +236,20 @@ Cluster admins can either:
2. grant signer-specific approval permissions using the bootstrap roles starting in 1.18
3. disable the approval-authorizing admission plugin in 1.18 (if they don't care about partitioning approver rights)

#### Supporting intermediate certificates.
It's important that the Certificates API fully supports using an intermediate certificate as the signer,
including the case where the signer is itself signed by an intermediate. As a result, the user must be able
to specify that the signing certificates are provided to the client, in which case their PEM values would
be appended to the Certificate in the CertificateSigningRequestStatus. Conforming clients will parse the
Copy link

@sftim sftim Apr 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend unambiguously specify the order in which intermediate certs are added into CertificateSigningRequest's status field or stating that the order is arbitrary / random.

Copy link
Author

@jackkleeman jackkleeman Apr 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, we could say it's the order given in the file in the controller, but I'm tempted to not make any guarantees here. I can update to say that it's arbitrary

full chain of certificates provided by the apiserver and present them all for new TLS handshakes.

Firstly, we will add a new bool flag to the controller, `cluster-signing-include-signers`, which requires
Copy link

@sftim sftim Apr 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a boolean field in the CSR spec or a boolean command line argument to the kube-controller-manager?

Copy link
Author

@jackkleeman jackkleeman Apr 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latter, I can clarify

that the signing certificate is always appended in this way. Currently the controller only allows a
single signing cert in `cluster-signing-cert-file`, so this approach would only work in the case where
the signing certificate is a child of the root CA, in which case it is the only certificate that needs
to be provided to the client. To support further nested signing certificates, we additionally need to
relax the contraint of the cert file parameter to accept multiple signers in a chain. The additional
certificates would only be used if the include signers option is set; they are not needed in signing.

### CertificateSigningRequest API Definition

Expand Down