cert-manager cannot communicate with Vault, if Vault is using an internal CA.

[jeroenjacobs79]

Bugs should be filed for issues encountered whilst operating cert-manager.
You should first attempt to resolve your issues through the community support
channels, e.g. Slack, in order to rule out individual configuration errors.
Please provide as much detail as possible.

Describe the bug:
When Vault is secured with a TLS key/cert issued by an internal CA, Cert-Manager is unable to issue certificates, as communication with Vault cannot be established:

  1 sync.go:71] Error initializing issuer: error reading Vault token from AppRole: error logging in to Vault server: Post https://vault.kube-security:8200/v1/auth/approle/login: x509: certificate signed by unknown authority
E0815 12:34:17.556694       1 controller.go:149] clusterissuers controller: Re-queuing item "vault-issuer" due to error processing: error reading Vault token from AppRole: error logging in to Vault server: Post https://vault.kube-security:8200/v1/auth/approle/login: x509: certificate signed by unknown authority
I0815 12:34:18.196955       1 controller.go:140] clusterissuers controller: syncing item 'vault-issuer'

Expected behaviour:
I expected I could pass a root CA to cert-manager, that should be used in communication with Vault. Using a public CA is not an option of course.

Steps to reproduce the bug:
Setup Vault with internal certificates, and configure cert-manager to use it for issuing certs.

Anything else we need to know?:

Environment details::

• Kubernetes version (e.g. v1.11.2):
• Cloud-provider/provisioner: None (bare-metal)
• cert-manager version (e.g. v0.4.0):
• Install method (e.g. helm or static manifests): static

/kind bug

Since securing Vault with an internal CA is common practice (nobody in their right mind would expose their Vault infrastructure to the internet), it should be possible to use a custom CA.

Maybe it's already possible, but in that case the documentation does not explain how to add a trusted ca to cert-manager. In this case, the documentation should be updated.

[munnerz]

As this is not a regression, I'm marking this as a feature request.

We're going to be cutting the v0.5 release later this week (we release monthly) and so unless someone is able to pick this ticket up to get the feature in, this may have to wait until v0.6.

I'm unsure how we should best represent this - Kubernetes API conventions would probably have us use the caBundle field on the actual issuer.spec.vault stanza. I'm not sure if people would prefer it be read from a secret instead however.

That said, there are security advantages imo from requiring it be explicit on the Issuer resource.

/cc @vdesjardins

[vdesjardins]

Personally I would prefer a field in the issuer too. Much simpler and it is not security sensitive element.

If all agree I could work on it soon.

[munnerz]

SGTM - that does potentially bring up issues in future if a user wants to secure vault itself with cert-manager, but this is a recurring issue and we can probably solve it by including something like caBundleSecretRef in future.

[lrolaz]

I use an init container as a workaround

      initContainers:
      - name: add-vault-ca
        image: quay.io/jetstack/cert-manager-controller:v0.5.0  
        command: ['/bin/sh']
        args: ['-c', "cd /etc/ssl/certs && cp /var/run/secret/ca/vault-ca.pem . && /usr/sbin/update-ca-certificates && cp * /etc/ssl/new"]
        securityContext:
          runAsUser: 0   
        volumeMounts:
          - name: ca-volume
            mountPath: /etc/ssl/new  
          - name: vault-ca
            mountPath: /var/run/secret/ca
...
      volumes:
      - name: ca-volume
        emptyDir: {}      
      - name: vault-ca
        secret:
          secretName: vault-ca   

[adamhosier]

SGTM - that does potentially bring up issues in future if a user wants to secure vault itself with cert-manager, but this is a recurring issue and we can probably solve it by including something like caBundleSecretRef in future.

@munnerz hey! has this caBundleSecretRef field been given any more thought? we're in a position where it would be super helpful. happy to help out if needed.

[s-newman]

I am also interested in the caBundleSecretRef field, and would be willing to help. The above init container workaround no longer works, unfortunately :(

[meyskens]

Can you open up a new issue for caBundleSecretRef? that makes it easier for us to track!