Comes under "How to pass trust stores in resource YAML when specifying external services?" as discussed in the cert-manager biweekly meeting
We often refer to external services in our CRDs. How do users configure the TLS trust bundle to use for those services?
Example modified from cert-manager ACMEDNS docs:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: example-issuer
spec:
acme:
server: https://my-acme-server.example.org # EXTERNAL SERVICE !!! Signed by "BarCorp CA"
...
solvers:
- dns01:
acmeDNS:
host: https://203.0.113.50 # EXTERNAL SERVICE !!! Signed by "FooCorp CA"
...
This issuer refers to two external services, both of which are using external CAs, one signed by FooCorp and one by BarCorp.
cert-manager should be able to talk to both, but shouldn't need to trust the CAs of both universally.
That is:
- I only want to trust "BarCorp CA" when talking to the ACME server.
- I only want to trust the "FooCorp CA" when solving the DNS-01 challenge
- I never want to trust either CA for any other task.
This happens in a lot of places in our CRDs
- As above, ACME issuers all require a server URL for the ACME server
- Some ACME solvers will require a URL for the challenge solver
- All Vault issuers need a URL for the Vault server
- Venafi TPP issuers need a URL for the TPP instance
- Many external issuers will also need a URL (e.g. step-issuer)
There are several approaches I've found to how we're doing this today:
- Vault, Venafi TPP and step-issuer all allow for a
caBundle
which allows a CA to be hardcoded into the resource - ACME servers do not support custom CA bundles, but do have the (dangerous) option to skip verification
- ACMEDNS solvers don't accept any bundle or allow for verification to be skipped
- The Nokia NCM issuer allows a reference to a secret which specifies the caCert and the client cert to use
Do we need to solve this generally? How do we solve this generally?
- Everywhere there's an HTTPS URL field, we also have a
caBundle
field (simple, hard to manage) - Everywhere there's an HTTPS URL field, we add a
tlsConfigRef
field which points to the (PEM) CA bundle in a ConfigMap / Secret (more complicated, better enables trust-manager) - Like (2) but if the ref is to a Secret, can also include client cert (maybe some things won't ever need client certs)