Vault CertificateRequest controller

[JoshVanL]

What this PR does / why we need it:
Adds the vault CertificateRequest controller to resolve CertificateRequests that have vault issuer references.

TODO:

• Add suite unit tests
• Add e2e tests

Adds Vault CertificateRequest support.

/assign

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

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

/retest

[JoshVanL]

/retest

[JoshVanL]

/retest

[JoshVanL]

💚 😎

[munnerz]

t is not used here and this function smells a lot like functions in pkg/util/pki - can the callsites be refactored to pass in something that allows greater configuration? We are statically setting the CommonName to test here, which is awkward behaviour to integrate in other packages

[JoshVanL]

	if err != nil {
		t.Error(err)
		t.FailNow()
	}

t does get used here. How would you suggest the function look/be moved to?

[munnerz]

nit: pre-define this as baseIssuer so that the gen.SetCertificateRequestIssuer can reference the name as baseIssuer.Name

[munnerz]

Ah, because the Sign implementation never deep copies the CR resource (due to the way the certificaterequests controller works), you'll need to DeepCopy here too.. 😬

[munnerz]

I don't see any ExpectedActions here that ensure it was marked as failed?

[munnerz]

In order to use ExpectedActions, you're going to need to test the actual CertificateRequests controller itself with this issuer loaded. I think we discussed this before, but doing so will save you implementing/having to use additional logic in the CheckFn (and thus make our tests more consistent/easier to write IMO).

Whilst I see your point about testing at a lower level, given the nature of this code relies upon being run as a controller anyway (we absorb errors and return nil due to the controller-like design), given we actually use the same testing strategy as we do when testing controllers (yet can't test the full surface), I feel like so far we've only lost granularity in our tests with this.

[munnerz]

How come this is under pkg/internal and not pkg/internal/vault?

[JoshVanL]

Its so we can fake the struct and keep the name the same. Happy to move it change the naming?

[munnerz]

Is this necessary? If so, I think it'd be better to move it out of this package.. whilst maybe poorly named, test/unit/gen is meant to be for generating API types and this pulls in a dependency on client-go to this package 😅

[munnerz]

/lgtm
/hold cancel