ctl experimental create certificatesigningrequest

[JoshVanL]

This PR adds the command:

ctl experimental create certificatesigningrequest
ctl x create csr

This behaves the same as the ctl create certificaterequest command, expect that it creates Kubernetes CertificateSigningRequest resources, rather than CertificateRequest resources.

Note that the signerName is built using the discovery API to determine whether the signer is namespaced or not.

Documentation: cert-manager/website#615

Adds CLI command: `ctl experimental create certificatesigningrequest` for creating a Kuberenetes CertificateSigningRequest based upon a cert-manager Certificate manifest file

/milestone v1.5

[irbekrm]

Looks good to me and seems like a really useful command

I've read through the code and also tested the new command by:

1. Building the plugin with bazel build //cmd/ctl and adding to path
2. Deploying cert-manager v1.4 with the experimental csr feature gate enabled
3. Creating a csr with the kubectl plugin using the example commands
4. Manually approving the csr (Do we intend to have a default approver for CSRs like we do with CRs? There may have been a discussion about this that I've forgotten about)
5. Observing the X.509 certificate added to csr's status/written to a file

I had a couple of issues along the way, so added a few minor suggestions.

[JoshVanL]

Manually approving the csr (Do we intend to have a default approver for CSRs like we do with CRs? There may have been a discussion about this that I've forgotten about)

Not today we don't. It would be a nice chance for us to not have a blanket auto-approver.

I've mentioned before that it does make me nervous that we have an internal auto-approver which is simple to forget to disable. Not disabling that auto-approver makes any other approver pointless.

[irbekrm]

Looks good to me!

Thanks for the changes, I've tested that namespace is now defaulted if not provided and panic no longer thrown.

I realized that we don't apply defaults or validate the certificate template, specifically the duration (i.e I could issue myself an X.509 cert with a duration 1s with the CA issuer).
I guess it might be ok for this, since the certs aren't going to be auto-renewed.

Going to lgtm with a hold in case @maelvls too wants to leave a review

/hold
/lgtm

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: irbekrm, JoshVanL

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:

• OWNERS [JoshVanL,irbekrm]

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

[maelvls]

I would love to have an option -oyaml to see the manifest itself 😅

[maelvls]

/unhold

[irbekrm]

/kind feature