Skip to content

Instantly share code, notes, and snippets.

@SgtCoDFish
Created December 14, 2022 15:59
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save SgtCoDFish/c61cf17b07381af744a5252b44d20f0a to your computer and use it in GitHub Desktop.
Save SgtCoDFish/c61cf17b07381af744a5252b44d20f0a to your computer and use it in GitHub Desktop.
Trust bundles in resources discussion

Comes under "How to pass trust stores in resource YAML when specifying external services?" as discussed in the cert-manager biweekly meeting

Problem Statement

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.

Scope of the Problem

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

Question

Do we need to solve this generally? How do we solve this generally?

Suggested Answers

  1. Everywhere there's an HTTPS URL field, we also have a caBundle field (simple, hard to manage)
  2. 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)
  3. Like (2) but if the ref is to a Secret, can also include client cert (maybe some things won't ever need client certs)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment