CertificateSigningRequest [page]deterministic

`apiVersion: certificates.k8s.io/v1`

`import "k8s.io/api/certificates/v1"`

## CertificateSigningRequest {#CertificateSigningRequest}

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.

<hr>

<table> <thead><tr><th>Field</th><th>Description</th></tr></thead> <tbody> <tr> <td><code>apiVersion</code><br/><em>string</em></td> <td>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</td> </tr> <tr> <td><code>kind</code><br/><em>string</em></td> <td>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</td> </tr> <tr> <td><code>metadata</code><br/><em><a href="">ObjectMeta</a></em></td> <td></td> </tr> <tr> <td><code>spec</code>&nbsp;<strong>*</strong><br/><em><a href="">CertificateSigningRequestSpec</a></em></td> <td>spec contains the certificate request, and is immutable after creation. Only the request, signerName, expirationSeconds, and usages fields can be set on creation. Other fields are derived by Kubernetes and cannot be modified by users.</td> </tr> <tr> <td><code>status</code><br/><em><a href="">CertificateSigningRequestStatus</a></em></td> <td>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.</td> </tr> </tbody> </table>

## CertificateSigningRequestSpec {#CertificateSigningRequestSpec}

CertificateSigningRequestSpec contains the certificate request.

<hr>

<table> <thead><tr><th>Field</th><th>Description</th></tr></thead> <tbody> <tr> <td><code>expirationSeconds</code><br/><em>integer</em></td> <td>expirationSeconds is the requested duration of validity of the issued certificate. The certificate signer may issue a certificate with a different validity duration so a client must check the delta between the notBefore and and notAfter fields in the issued certificate to determine the actual duration. The v1.22+ in-tree implementations of the well-known Kubernetes signers will honor this field as long as the requested duration is not greater than the maximum duration they will honor per the --cluster-signing-duration CLI flag to the Kubernetes controller manager. Certificate signers may not honor this field for various reasons: 1. Old signer that is unaware of the field (such as the in-tree implementations prior to v1.22) 2. Signer whose configured maximum is shorter than the requested duration 3. Signer whose configured minimum is longer than the requested duration The minimum valid value for expirationSeconds is 600, i.e. 10 minutes.</td> </tr> <tr> <td><code>extra</code><br/><em>object</em></td> <td>extra contains extra attributes of the user that created the CertificateSigningRequest. Populated by the API server on creation and …(trimmed)