pub struct PodCertificateRequestSpec {
pub max_expiration_seconds: Option<i32>,
pub node_name: String,
pub node_uid: String,
pub pod_name: String,
pub pod_uid: String,
pub service_account_name: String,
pub service_account_uid: String,
pub signer_name: String,
pub stub_pkc_s10_request: ByteString,
pub unverified_user_annotations: Option<BTreeMap<String, String>>,
}Expand description
PodCertificateRequestSpec describes the certificate request. All fields are immutable after creation.
Fields§
§max_expiration_seconds: Option<i32>maxExpirationSeconds is the maximum lifetime permitted for the certificate.
If omitted, kube-apiserver will set it to 86400(24 hours). kube-apiserver will reject values shorter than 3600 (1 hour). The maximum allowable value is 7862400 (91 days).
The signer implementation is then free to issue a certificate with any lifetime shorter than MaxExpirationSeconds, but no shorter than 3600 seconds (1 hour). This constraint is enforced by kube-apiserver. kubernetes.io signers will never issue certificates with a lifetime longer than 24 hours.
node_name: StringnodeName is the name of the node the pod is assigned to.
node_uid: StringnodeUID is the UID of the node the pod is assigned to.
pod_name: StringpodName is the name of the pod into which the certificate will be mounted.
pod_uid: StringpodUID is the UID of the pod into which the certificate will be mounted.
service_account_name: StringserviceAccountName is the name of the service account the pod is running as.
service_account_uid: StringserviceAccountUID is the UID of the service account the pod is running as.
signer_name: StringsignerName indicates the requested signer.
All signer names beginning with kubernetes.io are reserved for use by the Kubernetes project. There is currently one well-known signer documented by the Kubernetes project, kubernetes.io/kube-apiserver-client-pod, which will issue client certificates understood by kube-apiserver. It is currently unimplemented.
stub_pkc_s10_request: ByteStringA PKCS#10 certificate signing request (DER-serialized) generated by Kubelet using the subject private key.
Most signer implementations will ignore the contents of the CSR except to extract the subject public key. The API server automatically verifies the CSR signature during admission, so the signer does not need to repeat the verification. CSRs generated by kubelet are completely empty.
The subject public key must be one of RSA3072, RSA4096, ECDSAP256, ECDSAP384, ECDSAP521, or ED25519. Note that this list may be expanded in the future.
Signer implementations do not need to support all key types supported by kube-apiserver and kubelet. If a signer does not support the key type used for a given PodCertificateRequest, it must deny the request by setting a status.conditions entry with a type of “Denied” and a reason of “UnsupportedKeyType”. It may also suggest a key type that it does support in the message field.
unverified_user_annotations: Option<BTreeMap<String, String>>unverifiedUserAnnotations allow pod authors to pass additional information to the signer implementation. Kubernetes does not restrict or validate this metadata in any way.
Entries are subject to the same validation as object metadata annotations, with the addition that all keys must be domain-prefixed. No restrictions are placed on values, except an overall size limitation on the entire field.
Signers should document the keys and values they support. Signers should deny requests that contain keys they do not recognize.
Trait Implementations§
Source§impl Clone for PodCertificateRequestSpec
impl Clone for PodCertificateRequestSpec
Source§impl Debug for PodCertificateRequestSpec
impl Debug for PodCertificateRequestSpec
Source§impl DeepMerge for PodCertificateRequestSpec
impl DeepMerge for PodCertificateRequestSpec
Source§fn merge_from(&mut self, other: Self)
fn merge_from(&mut self, other: Self)
other into self.