Implement csi templating on select attributes

[blaggacao]

Added attribute templating for `csi.cert-manager.io/common-name`, `csi.cert-manager.io/dns-names` and `csi.cert-manager.io/uri-sans` via go templates.
The available pod values are:
- `PodName`
- `PodNamespace`
- `PodUID`

Docs: https://cert-manager.io/docs/usage/csi/#templating

closes #20

Contrary to suggestion in #20, I figured plain golang templating would be more friction-less / less friction-full.

Docs are ready: cert-manager/website#271

[jetstack-bot]

Hi @blaggacao. Thanks for your PR.

I'm waiting for a jetstack or cert-manager member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[blaggacao]

/joke

[jetstack-bot]

@blaggacao: What kind of dog lives in a particle accelerator? A Fermilabrador Retriever.

In response to this:

/joke

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[blaggacao]

@JoshVanL I'd iterate on this with some practical experience. Since we're in alpha, I hope we have the freedom to break things.
Therefore, maybe you'd not too eagerly merge the related docs PR if this is accepted.

Some ideas that are more oriented towards one practical use case (the one I have in mind):

• default common name to fqdn (if not set)
• default include IP and fgdn in SAN list (with a switch to turn that behaviour off)
• expose low level templating API for special constructs (that should only serve as last resort)

[blaggacao]

/assign @JoshVanL

[JoshVanL]

Sorry for the slow response @blaggacao, thanks for putting this together!

Just the one comment to add 🙂

/approve
/assign @blaggacao

[JoshVanL]

Can we move this file out of the API and into cert-manager-csi/pkg/util/template?

Also rename file to template.go.

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: blaggacao, 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]

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

[JoshVanL]

@JoshVanL I'd iterate on this with some practical experience. Since we're in alpha, I hope we have the freedom to break things.
Therefore, maybe you'd not too eagerly merge the related docs PR if this is accepted.

Some ideas that are more oriented towards one practical use case (the one I have in mind):

• default common name to fqdn (if not set)
• default include IP and fgdn in SAN list (with a switch to turn that behaviour off)
• expose low level templating API for special constructs (that should only serve as last resort)

I would be happy with all of those changes as attributes given to the driver, as a shorthand for the templating in this PR.

Indeed can be a follow up PR, but not a blocker for v0.1.

---

Will also merge the website PR when this gets merged.

[blaggacao]

Actually, I'm starting to think if this marginal PR should be merged, since the real problem is workload identity. And after some additional research, it appears to me as if workload identity and mTLS is better handled by something like https://spiffe.io.

So I'm not sure if we're being fair to users presenting them with a "half-way" / "somewhat of a" solution.

I mean cert-manager still has it's well defined use case, apart from workload identity management.
There is an appeal having CSI doing the job, but doing things like with spire, only keeping certs in memory, couldn't be achieved with this approach, nor does it easily extend to non-k8s workloads.

I'm going to close this, for that reason, maybe if we can develop a fairer and more educational stance towards user, this workload attestation might be reconsidered.

Maybe, rather than going down the road of this PR, cert-manager could join the effort and implement it's own SPIFFE implementation based on Certificates (and leaving out on JWT) - that might make more sense to users, future and existing - why not via CSI 😉 ...

---

Thank you for your review! I was about to decide upon this PR anyway since I made a deep dive into spiffe the last few days.