additional ca-bundle source options: pvc, url

[lknite]

My source ca-bundle location is via a url, specifically vault provides a url to access its public ca-bundle which includes root and intermediate. (e.g. https://vault.vc-prod.home.net:8200/v1/prod-intermediate-ca/ca_chain)

I can access this via kubernetes by using an initContainer & pvc:

• mount the pvc as a volume with initContainer
• inside the initContainer use curl to pull the latest ca-bundle, save to pvc mount location

Now I just need to provide this location to trust-manager in the ca-bundle resource.

• either by providing the pvc & location in the usual way
• OR, we could get around the initContainer & pvc, if it were possible to provide a url location in the Bundle resource

[cert-manager-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale

[cert-manager-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
/remove-lifecycle stale

[cert-manager-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close

[cert-manager-prow]

@cert-manager-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close

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-sigs/prow repository.

[denniskniep]

Can someone reopen this?

I am also interested to have a solution for this.
I would prefer the solution to specify a url location as source in the Bundle custom resource

Link to docs:
https://developer.hashicorp.com/vault/api-docs/secret/pki#read-issuer-certificate

Example:
curl https://<vault>/v1/<nameOfPki>/issuer/<nameOfIssuer>/pem --output -

[erikgb]

/reopen

[cert-manager-prow]

@erikgb: Reopened this issue.

In response to this:

/reopen

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-sigs/prow repository.

[b-dean]

Another reason to get CA public keys from a URL are authorities like DigiCert who have a bunch of CAs that are not in Mozilla's bundle.

Currently we'd need some other process to regularly get them and put them in a ConfigMap probably.

[lknite]

Came here to reopen this, happy to see someone else opened it back up. Still working with vault, and it would still be nice to be able to add via a url like vault provides, though we can use an initContainer to put the data in a pvc if a pvc is preferred over a url.

Additional idea:

• if we can add via url, and that url was updated ... that trust-manager would handle that and update the certs its deploying out to name spaces without having to kill the pod so that it reloads via the url, a once a day poll should do it because odds are, if a new cert was released the wouldn't immediately disappear but rather the old cert and new cert would both be valid for awhile
• or maybe trust-manager could provide a webhook/api that could be called to reload from url, that would allow automation somewhere else to communicate with trust-manager that the url has been updated so it can reload, (without having to kill the pod) ... of course trust-manager doing this automatically, as in the previous bullet item, would be preferred