LinuxCommandLibrary

kubectl-certificate

Approve or deny certificate signing requests

TLDR

Approve a certificate signing request by name

$ kubectl certificate approve [csr_name]
copy

Deny a certificate signing request by name
$ kubectl certificate deny [csr_name]
copy

Approve a certificate signing request defined in a manifest file
$ kubectl certificate approve --filename [path/to/csr.yaml]
copy

Deny a certificate signing request defined in a manifest file
$ kubectl certificate deny --filename [path/to/csr.yaml]
copy

Force reapproval of a certificate signing request that was previously denied
$ kubectl certificate approve --force [csr_name]
copy

SYNOPSIS

kubectl certificate [options]

PARAMETERS

approve
    Approves a specific Certificate Signing Request (CSR) by its name. This action signals to the Kubernetes certificate controller to issue a certificate based on the request.

deny
    Denies a specific Certificate Signing Request (CSR) by its name. This prevents the Kubernetes certificate controller from issuing a certificate for the request.

--help
    Displays help information for the kubectl certificate command or its subcommands.

--dry-run=
    If specified, only print the object that would be sent without actually performing the action. Useful for testing commands without making changes. Possible values include client, server, or none.

DESCRIPTION

The `kubectl certificate` command is used to manage Certificate Signing Request (CSR) resources within a Kubernetes cluster. CSRs are a fundamental mechanism in Kubernetes for requesting X.509 certificates, primarily used by components like Kubelets for secure communication or by users/applications to obtain client certificates. This command provides subcommands to interact with these requests, allowing administrators to review, approve, or deny them.

When a component or user requests a certificate, a CSR object is created in the cluster. Administrators can then list these CSRs, inspect their details, and decide whether to sign the requested certificate (approve) or reject it (deny). Approving a CSR typically results in the Kubernetes certificate controller signing the request and issuing the certificate, which is then made available to the requester. Denying a CSR rejects the request, preventing the issuance of a certificate. This process is crucial for maintaining the security posture of a Kubernetes environment by controlling who can obtain valid certificates.

CAVEATS

Requires appropriate RBAC permissions (e.g., verbs approve or deny on certificatesigningrequests).
The argument must exactly match an existing Certificate Signing Request.
Approving a CSR does not immediately generate a certificate visible to the user; it signals the controller. The controller then signs the request and updates the CSR status with the issued certificate.

RBAC PERMISSIONS

Managing CSRs requires specific Role-Based Access Control (RBAC) permissions. Users or service accounts need approve or deny verbs on the certificatesigningrequests resource within the certificates.k8s.io API group to use these subcommands successfully. Without these permissions, the commands will fail with authorization errors.

CSR STATUS AND CERTIFICATE RETRIEVAL

After a CSR is approved, its status.conditions field is updated. Once the Kubernetes certificate controller processes the approved request, it adds the signed certificate to the status.certificate field of the CSR object. The requester can then retrieve this signed certificate, typically using kubectl get csr <name> -o jsonpath='{.status.certificate}' | base64 --decode.

CERTIFICATE LIFETIME AND RENEWAL

The certificates issued via CSRs often have a specific validity period. It's essential to consider certificate rotation and renewal strategies. While kubectl certificate handles approval, renewal processes typically involve creating new CSRs and repeating the approval workflow.

HISTORY

The `certificate` subcommand was introduced early in Kubernetes' development to manage `certificates.k8s.io` API resources, which are central to the cluster's internal security model. As Kubernetes matured, the Certificate Signing Request (CSR) API became the standard method for managing x509 certificates within the cluster, enabling secure communication for components like Kubelets and allowing external services to obtain trusted certificates. The approve and deny subcommands provide administrative control over this crucial security workflow, evolving with the increasing demand for automated and secure certificate management in cloud-native environments.

SEE ALSO

kubectl get csr(1), kubectl describe csr(1), openssl req(1), openssl x509(1)

Copied to clipboard