CertificateSigningRequest v1 API

[liggitt]

What type of PR is this?
/kind api-change
/kind feature

What this PR does / why we need it:

• Adds the certificates.k8s.io/v1 CertificateSigningRequest API
• Switches UpdateApproval v1 client method to be generated
• Switches the certificate e2e tests to use the v1 API and promotes them to conformance tests (run history for gce-cos-master and kind-master-parallel), current API coverage of those tests against the beta API visible at https://apisnoop.cncf.io/ci-kubernetes-e2e-gci-gce/1268651207392497664/beta/certificates

Follow-up PRs:

• switch CSR controllers to v1 - CSR v1 - switch controllers #91713
• add v1 CSR support to the client-go certificate manager - CSR v1 - switch client-go certificate manager utility to v1 by default #91754
• add v1 CSR support to kubectl certificates approve/deny - CSR v1 - add support to kubectl certificate commands #91778
• add v1 CSR support to kubectl describe - CSR v1 - add support to kubectl describe #91779
• promote RotateKubeletClientCertificate feature to GA - CSR v1 - promote RotateKubeletClientCertificate to GA #91780
• remove exception for CSR beta API/feature from GA-only CI job - Tighten GA_ONLY configuration to drop CSR exception for 1.19 kubernetes-sigs/kind#1651

xref kubernetes/enhancements#1513

part of https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190607-certificates-api.md

Does this PR introduce a user-facing change?:

The CertificateSigningRequest API is promoted to certificates.k8s.io/v1 with the following changes:
* `spec.signerName` is now required, and requests for `kubernetes.io/legacy-unknown` are not allowed to be created via the `certificates.k8s.io/v1` API
* `spec.usages` is now required, may not contain duplicate values, and must only contain known usages
* `status.conditions` may not contain duplicate types
* `status.conditions[*].status` is now required
* `status.certificate` must be PEM-encoded, and contain only CERTIFICATE blocks

/sig auth
/cc @munnerz @smarterclayton

[liggitt]

/priority important-soon

[liggitt]

/hold for API review and conformance test review

[smarterclayton]

Nits and improvements to godoc (i really want to be able to read kubectl explain and understand what CSR does without referencing the code). Tests and validation looks fine.

[liggitt]

updated docs, as seen by kubectl explain (with formatting-preserving improvements from #91801):

kubectl explain csr
...
DESCRIPTION:
     CertificateSigningRequest objects provide a mechanism to obtain x509
     certificates by submitting a certificate signing request, and having it
     asynchronously approved and issued.

     Kubelets use this API to obtain:
     1. client certificates to authenticate to kube-apiserver (with the
     "kubernetes.io/kube-apiserver-client-kubelet" signerName).
     2. serving certificates for TLS endpoints kube-apiserver can connect to
     securely (with the "kubernetes.io/kubelet-serving" signerName).

     This API can be used to request client certificates to authenticate to
     kube-apiserver (with the "kubernetes.io/kube-apiserver-client" signerName),
     or to obtain certificates from custom non-Kubernetes signers.

FIELDS:
...
   spec	<Object> -required-
     spec contains the certificate request, and is immutable after creation.
     Only the request, signerName, and usages fields can be set on creation.
     Other fields are derived by Kubernetes and cannot be modified by users.

   status	<Object>
     status contains information about whether the request is approved or
     denied, and the certificate issued by the signer, or the failure condition
     indicating signer failure.

kubectl explain csr.spec
...
DESCRIPTION:
     spec contains the certificate request, and is immutable after creation.
     Only the request, signerName, and usages fields can be set on creation.
     Other fields are derived by Kubernetes and cannot be modified by users.

     CertificateSigningRequestSpec contains the certificate request.

FIELDS:
   extra	<map[string][]string>
     extra contains extra attributes of the user that created the
     CertificateSigningRequest. Populated by the API server on creation and
     immutable.

   groups	<[]string>
     groups contains group membership of the user that created the
     CertificateSigningRequest. Populated by the API server on creation and
     immutable.

   request	<string> -required-
     request contains an x509 certificate signing request encoded in a
     "CERTIFICATE REQUEST" PEM block. When serialized as JSON or YAML, the data
     is additionally base64-encoded.

   signerName	<string> -required-
     signerName indicates the requested signer, and is a qualified name.
     List/watch requests for CertificateSigningRequests can filter on this field
     using a "spec.signerName=NAME" fieldSelector.

     Well-known Kubernetes signers are:
     1. "kubernetes.io/kube-apiserver-client": issues client certificates that
     can be used to authenticate to kube-apiserver. Requests for this signer are
     never auto-approved by kube-controller-manager, can be issued by the
     "csrsigning" controller in kube-controller-manager.
     2. "kubernetes.io/kube-apiserver-client-kubelet": issues client
     certificates that kubelets use to authenticate to kube-apiserver. Requests
     for this signer can be auto-approved by the "csrapproving" controller in
     kube-controller-manager, and can be issued by the "csrsigning" controller
     in kube-controller-manager.
     3. "kubernetes.io/kubelet-serving" issues serving certificates that
     kubelets use to serve TLS endpoints, which kube-apiserver can connect to
     securely. Requests for this signer are never auto-approved by
     kube-controller-manager, and can be issued by the "csrsigning" controller
     in kube-controller-manager.

     More details are available at
     https://k8s.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers

     Custom signerNames can also be specified. The signer defines:
     1. Trust distribution: how trust (CA bundles) are distributed.
     2. Permitted subjects: and behavior when a disallowed subject is requested.
     3. Required, permitted, or forbidden x509 extensions in the request
     (including whether subjectAltNames are allowed, which types, restrictions
     on allowed values) and behavior when a disallowed extension is requested.
     4. Required, permitted, or forbidden key usages / extended key usages.
     5. Expiration/certificate lifetime: whether it is fixed by the signer,
     configurable by the admin.
     6. Whether or not requests for CA certificates are allowed.

   uid	<string>
     uid contains the uid of the user that created the
     CertificateSigningRequest. Populated by the API server on creation and
     immutable.

   usages	<[]string>
     usages specifies a set of key usages requested in the issued certificate.
     Requests for TLS client certificates typically request: "digital
     signature", "key encipherment", "client auth".

     Requests for TLS serving certificates typically request: "key
     encipherment", "digital signature", "server auth".

     Valid values are:
     "signing", "digital signature", "content commitment", "key encipherment",
     "key agreement", "data encipherment", "cert sign", "crl sign", "encipher
     only", "decipher only", "any", "server auth", "client auth", "code
     signing", "email protection", "s/mime", "ipsec end system", "ipsec tunnel",
     "ipsec user", "timestamping", "ocsp signing", "microsoft sgc", "netscape
     sgc"

   username	<string>
     username contains the name of the user that created the
     CertificateSigningRequest. Populated by the API server on creation and
     immutable.

kubectl explain csr.status
KIND:     CertificateSigningRequest
VERSION:  certificates.k8s.io/v1

RESOURCE: status <Object>

DESCRIPTION:
     status contains information about whether the request is approved or
     denied, and the certificate issued by the signer, or the failure condition
     indicating signer failure.

     CertificateSigningRequestStatus contains conditions used to indicate
     approved/denied/failed status of the request, and the issued certificate.

FIELDS:
   certificate	<string>
     certificate is populated with an issued certificate by the signer after an
     Approved condition is present. This field is set via the /status
     subresource. Once populated, this field is immutable.

     If the certificate signing request is denied, a condition of type "Denied"
     is added and this field remains empty. If the signer cannot issue the
     certificate, a condition of type "Failed" is added and this field remains
     empty.

     Validation requirements:
     1. certificate must contain one or more PEM blocks.
     2. All PEM blocks must have the "CERTIFICATE" label, contain no headers,
     and the encoded data must be a BER-encoded ASN.1 Certificate structure as
     described in section 4 of RFC5280.
     3. Non-PEM content may appear before or after the "CERTIFICATE" PEM blocks
     and is unvalidated, to allow for explanatory text as described in section
     5.2 of RFC7468.

     If more than one PEM block is present, and the definition of the requested
     spec.signerName does not indicate otherwise, the first block is the issued
     certificate, and subsequent blocks should be treated as intermediate
     certificates and presented in TLS handshakes.

     The certificate is encoded in PEM format.

     When serialized as JSON or YAML, the data is additionally base64-encoded,
     so it consists of:

         base64(
         -----BEGIN CERTIFICATE-----
         ...
         -----END CERTIFICATE-----
         )

   conditions	<[]Object>
     conditions applied to the request. Known conditions are "Approved",
     "Denied", and "Failed".

kubectl explain csr.status.conditions
...
DESCRIPTION:
     conditions applied to the request. Known conditions are "Approved",
     "Denied", and "Failed".

     CertificateSigningRequestCondition describes a condition of a
     CertificateSigningRequest object

FIELDS:
   lastTransitionTime	<string>
     lastTransitionTime is the time the condition last transitioned from one
     status to another. If unset, when a new condition type is added or an
     existing condition's status is changed, the server defaults this to the
     current time.

   lastUpdateTime	<string>
     lastUpdateTime is the time of the last update to this condition

   message	<string>
     message contains a human readable message with details about the request
     state

   reason	<string>
     reason indicates a brief reason for the request state

   status	<string> -required-
     status of the condition, one of True, False, Unknown. Approved, Denied, and
     Failed conditions may not be "False" or "Unknown".

   type	<string> -required-
     type of the condition. Known conditions are "Approved", "Denied", and
     "Failed".

     An "Approved" condition is added via the /approval subresource, indicating
     the request was approved and should be issued by the signer.

     A "Denied" condition is added via the /approval subresource, indicating the
     request was denied and should not be issued by the signer.

     A "Failed" condition is added via the /status subresource, indicating the
     signer failed to issue the certificate.

     Approved and Denied conditions are mutually exclusive. Approved, Denied,
     and Failed conditions cannot be removed once added.

     Only one condition of a given type is allowed.

[liggitt]

comments addressed

[liggitt]

/retest

[liggitt]

/retest

[smarterclayton]

/approve

API changes.

Was there anyone else who needed to review? If not I think I'm ready to tag this.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: johnbelamaric, liggitt, smarterclayton

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• api/OWNERS [liggitt,smarterclayton]
• build/OWNERS [liggitt,smarterclayton]
• cmd/kube-apiserver/OWNERS [liggitt,smarterclayton]
• hack/OWNERS [liggitt,smarterclayton]
• pkg/apis/OWNERS [liggitt,smarterclayton]
• pkg/master/OWNERS [liggitt,smarterclayton]
• pkg/registry/certificates/OWNERS [liggitt,smarterclayton]
• staging/src/k8s.io/api/OWNERS [liggitt,smarterclayton]
• staging/src/k8s.io/client-go/OWNERS [liggitt,smarterclayton]
• staging/src/k8s.io/kubectl/OWNERS [liggitt,smarterclayton]
• test/conformance/testdata/OWNERS [johnbelamaric,smarterclayton]
• test/e2e/auth/OWNERS [liggitt,smarterclayton]
• test/integration/apiserver/OWNERS [liggitt,smarterclayton]
• test/integration/etcd/OWNERS [liggitt,smarterclayton]
• vendor/OWNERS [liggitt,smarterclayton]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[liggitt]

All set from my perspective

[smarterclayton]

/lgtm

[liggitt]

/hold cancel