Change:
// Base64-encoded PKCS#10 CSR data Request []byte <del> // Requested signer for the request. It is a qualified name in the form: // `scope-hostname.io/name`. // Distribution of trust for signers happens out of band. // You can select on this field using `spec.signerName`. </del> <ins> // 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. </ins> SignerName string // usages specifies a set of usage contexts the key will be

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I spent some time helping a customer figure out they were misusing the recently field in a CSR. They had been using CSRs for several releases to generate server certs for Kubernetes services that were only used within the cluster. They found and read the Signers section of the . The predefined Kubernetes signers didn't seem to fit their use case so they made up their own . When they approved the CSRs no certs were issued; it looked much as if the CSR controller was failing or not even running. It was an area I was unfamiliar with as well and it took a long time to realize the signerName they were using was the cause of the behavior and this was actually working correctly. The PR that this function has a sentence that makes the intent of the signerName field clear: Some ideas coming out of this exercise: Could the signer code add a condition or an event for the CSR resource indicating that the control plane is not issuing a certificate for an approved CSR because the signerName represents an external signer? Could the documentation on clarify that other names are allowed and that those are external signers and as such the control plane signer will not issue certificates - that is function the administrator must provide or install ? For people who have been using the v1beta1 API, would it be appropriate for the "Kubernetes signers" section to suggest that CSRs for internal Kubernetes services "can use as described in " What you expected to happen: How to reproduce it (as minimally and precisely as possible): Create a CSR Send a CertificateSigningRequest resource to Kubernetes using:Approve the CSR: CSR is Approved but not Issued: Anything else we need to know?: Environment: Kubernetes version (use ): I've repeated this on 1.18 through 1.20.1 Cloud provider or hardware configuration: IBM Cloud Kubernetes Service OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance.

The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig auth
I would not expect kubernetes signers to add conditions to CSR objects requesting different signers. This sounds like a good idea to add to the signerName API documentation (in ) and to the website documentation at No, the signerName is only intended for serving certificates issued to kubelets. I know and (and maybe had interest in the "pod/service serving certificate" use case (xref ), but that would be implemented as a (new) distinct signerName.
/assign