Comments (10)
I can add that we will also support password-less PKCS12 truststores in our next release, ref. #163 (with a few follow-up fix-PRs). 😉
from trust-manager.
To update this thread, trust-manager has changed a fair bit since raising this issue, but the question does still remain on how best to consume a Bundle
or the output of said resource.
We discussed this topic (thanks to @erikgb for bringing it up) on the cert-manager bi-weekly call yesterday (30th Nov 2023).
I created two action for myself to follow up:
- Review the trust-manager tutorial with the latest trust-manager release
- Initiate some contact with upstream on
ClusterTrustBundle
usage.
We also briefly mentioned some related issues / feature requests that might make Bundles
more useful:
Clearly on big topic we identified which has many possible options is auto-mounting a bundle into the default locations. But default locations change per image base. @SpectralHiss has kindly offered to gather a list of the commone places used by various language and OS bases as a starting point in this effort.
The other area was making use of Bundle
(or bundle output) in CRDs.
Both options are currently difficult or at the very least need something extra, or some documentation, so we will keep this issue open and hope to come to a clearer strategy for "how you use a Bundle".
from trust-manager.
Look at this project > https://github.com/smallstep/autocert < for inspiration. We're using it currently for injecting the pub. CA cert of the CA we're self-hosting. It's working pretty well. However, sometimes, the only caveat, is that at Pod
restart or re-schedule Pod
workloads using the autocert
project needs to be restarted twice before the autocert
init type container kicks in and does its thing.
from trust-manager.
Am I right in thinking that the best approach to update CA's trusted at runtime of a non-root container, is to effectively use a privileged init container with a shared volume with the application and some entrypoint.sh type magic? Something like the suggestion here
That's definitely an approach that can be taken! If we can rely on users to add init containers and update entrypoints that makes it a lot easier.
Part of the issue here is working out what's reasonable for users to do to be able to use the bundles we generate. Automating any of this is hard for several reason. I'll use "TMBundle" to mean "a bundle created by trust-manager".
- Users may have different opinions on whether they want TMBundles to replace the container's trust store or to add to it. I think they should replace where possible but it's easy to imagine some will want to add.
- We can't necc. rely on people running anything before their application (i.e. changing their entrypoint / adding an init container)
- We can't easily tell what distro people are running inside a given container, and each distro may have a different path at which it writes its own trust store
- We can't change application code which looks in a specific place for a trust store
- I'm sure there are more!
I think the long term is probably that there has to be some kind of upstream k8s standard for this. Without that, I think automating this is always going to miss some edge cases.
Documenting and improving usage is definitely a priority of mine but it's prioritised behind public trust bundles and bundle output formats!
from trust-manager.
Possibly related KEP for "Trust Anchor Sets": kubernetes/enhancements#3257
Some additional wrinkles:
- Some organizations may also build custom CA certs into their base images
- OpenSSL has a particular configuration with 7-letter (IIRC) symlinks to the actual cert files based on hashes of some of the CA data. I suspect these are scanned once when OpenSSL init is called, but I could be mistaken. For this reason,
SSL_CERT_FILE
may be easier to manage thanSSL_CERT_DIR
, though it may be possible to create non-symlink shortnames that will work in thetrust
ConfigMap. - Golang does not need the aforementioned symlinks.
- Java uses a different Trust Store mechanism; it seems to recommend using a java-specific tool (
keytool
) to add certs to the Java trust store. - I don't know enough about Rust, but I suspect the situation is similar to Golang.
from trust-manager.
Not only does java use a different Trust Store mechanism (which is sometimes tied to the distro's trust store), but different distros use different CA trust store configurations and different update commands:
update-ca-certificates
in Alpine and Debian-derived distrosupdate-ca-trust
on RedHat-derived distros
from trust-manager.
Thanks @evankanderson and @gclawes! I think we're aware of the points you both raised, which is great validation! JKS files for Java is definitely on the roadmap.
I don't think any of the issues raised should be serious problems. The openssl symlink stuff would be wild to try and solve but I'm not aware of a need for us to actually solve that.
from trust-manager.
Oh I really forgot that I opened this issue. Having a quick scan through there's a couple things that might help with the issues presented in comments:
- trust-manager now supports JKS output as well: #122. Since https://github.com/cert-manager/trust-manager/releases/tag/v0.5.0
- @SgtCoDFish wrote a blog that might be of use: https://venafi.com/blog/trust-manager/
- We also have this tutorial on cert-manager that I wrote about how you can use the bundle output.
I think particularly the last article (i wrote) should help address some of the comments about how to actually use this in Kubernetes with applications. It'll be different for certain languages of course and I don't cover all those previously mentioned, but it might be a good starting place.
I'm tempted to close out this issue and if there are specific challenges that haven't been addressed, they are raised as new concerns.
from trust-manager.
I have found it common that a cm and secret are both too small to store the needed certs plus additional certs requiring a pvc to be needed instead.
If we expect folks to use an initContainer then why have something in every namespace? We could just use curl to get the latest ca-bundle using a trust-manager rest api.
Along that line though, if using a pvc, could we not use a ReadOnlyMany pvc so we only need one? Or possibly create a pvc in every namespace... or use a namespace label to indicate a ca-bundle pvc should be created there?
from trust-manager.
I have found it common that a cm and secret are both too small to store the needed certs plus additional certs requiring a pvc to be needed instead.
If we expect folks to use an initContainer then why have something in every namespace? We could just use curl to get the latest ca-bundle using a trust-manager rest api.
Along that line though, if using a pvc, could we not use a ReadOnlyMany pvc so we only need one?
...
Perhaps we could create a stand-alone cli which, when given a docker image or oci reference, could go out and look up the image, performing checks to determine how the ca-bundle should be mounted. Then, later, trust-bundle can use that utility on the fly, with appropriate permissions granted via namespace labels to mount the ca-bundle to the correct location. ... if the k8s clusters are airgapped we can use the cli to get the technique needed and store that in a cm, perhaps the tool could output a configmap or label the namespace, and that could be used by trust-manager to add the ca-bundle on the fly.
from trust-manager.
Related Issues (20)
- Issue with CRDs when having trust-manager as chart dependency
- No flag to set structured logging format, e.g. JSON? HOT 2
- Using `trust-manager` for generating keystores HOT 5
- Evaluate trust namespace value as template
- Init Container cert-manager-package-debian Helm Chart should allow resource requests and limits HOT 1
- Bundle generating empty truststore.p12 when no password is provided HOT 2
- Allow all resources to be namespaced
- trust-manager deduplication doesnt work HOT 12
- Add support to s390x arch HOT 9
- Add support for kubectl installation HOT 3
- Add matchExpressions to Bundle's spec.target.namespaceSelector HOT 3
- Avoid multiple decode/encode of certificates HOT 6
- Provide deterministic bundle HOT 5
- Wrong labels in topologySpreadConstraints example in the Helm chart values
- Chart is not allowing to pass Certificate Issuer name through value.yaml
- Document a policy around immutable image tags HOT 1
- Support RSA Keys HOT 3
- Helm chart support dual stack clusters
- Allow to specify admission webhooks CA from Bundle HOT 3
- Empty Target field in kubectl get bundle HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from trust-manager.