cert-manager maintainter chiming in to say that yes, cert-manager should support IP address certs - if anyone finds any bugs, we'd love to hear from you!
We also support ACME profiles (required for short lived certs) as of v1.18 which is our oldest currently supported[1] version.
We've got some basic docs[2] available. Profiles are set on a per-issuer basis, so it's easy to have two separate ACME issuers, one issuing longer lived certs and one issuing shorter, allowing for a gradual migration to shorter certs.
As an active maintainer of cert-manager (which is CNCF graduated), I can shed some light here. It's not just "give away trademarks for nothing"!
The CNCF pays for cert-manager's testing, web hosting and infrastructure costs and they paid for a professional security audit of the project. We get marketing help, exposure, talks, booths and other bits too. When we graduated last year, we got popcorn!
What I personally like too is that the CNCF provide a kind of "business continuity" aspect for open source, which is something I think about a lot. If the current maintainers got hit by an asteroid at an in-person event, there are CNCF people in our testing infra account and in GitHub who can log in and save the project. At the end of the day businesses have continuity plans for their projects, and for open-source projects of cert-manager's size it makes sense to do the same - and the CNCF neatly solves that problem for us.
They might try - that's why it's important if you're generating + committing generated code that you also have a CI step that runs before merging anything which ensures that the generated code is up-to-date and rejects any change request where generated code is out of date.
Mostly this helps with people simply forgetting to re-run the generator in their PR but it's a useful defence against people trying to smuggle things into the generated files, too!
Plug (but it's open source and free - and mentioned in the article!): We've been trying to address this in Kubernetes with trust-manager. [1] Trust bundles need to be a runtime concern and they need to support trusting both the old a new version of a cert to safely allow for rotation. It's pretty simple but it seems to work well!
trust-manager also supports pulling in the Mozilla trust bundle which most Linux distros (and therefore most containers) use!
Handling trust of private [2] certificates is done poorly generally across many orgs and platforms, not just Kubernetes. There are lots of ways of shooting yourself in the foot - particularly when it comes to rotating CA certificates. I think there's a lot of space here for new solutions here!
[2] I try to avoid "self-signed" in this use case because its literal meaning is that the certificate signs itself using its own key, which is what root certificates do. The Let's Encrypt ISRG X1 root certificate is self-signed but it's definitely not what I'd call a 'private CA'; see https://letsencrypt.org/certificates/
Having the communication in cleartext also makes it much easier for attackers to interfere with!
Sure, they can't modify the .deb without failing signature verification, but they _can_ inject arbitrary delays in downloads or interfere with anything else which isn't signed (e.g. HTTP headers)
Plus, if a vulnerability was discovered in the signing tool which enabled signature verification bypass with a certain signature format, HTTP makes it easy for attackers to perform that attack.
TLS shouldn't be optional for installing packages today IMO - the extra guarantees it provides are worth it even with signature verification enabled.
This is super interesting; we had a fairly long discussion about whether or not to add this action to cert-manager[1], and ended up rejecting it in part because it increased the risk of supply-chain attacks and that risk wasn't, in our opinion, outweighed by the potential benefit of catching more spelling mistakes.[2]
For me, I think there's a wider point here that GitHub Actions are pretty scary in terms of these kinds of attacks. Pre-packaged actions are easy to add to a project but come with risks, as this security advisory shows! There are a few aspects to Actions which made me a little uneasy in terms of my threat models when building software, and personally I've tended to avoid them.
This mirrors my experience, too. Building a simple RPM isn't too bad, even if spec files are a little arcane. Packaging for the AUR isn't super complicated as far as I've seen.
The "standard" way to build even the simplest deb file seems super overcomplicated whenever I've tried to do it, with layers of complexity, shims and fudges.
For most simple stuff you just want to specify a bit of metadata, a couple of install scripts and specify "X goes in /usr/bin/X, Y goes in /usr/share/...".
I tend to find that fpm (https://fpm.readthedocs.io/en/latest/) does that for me, and I now use it for building my own deb files pretty much everywhere.
We also support ACME profiles (required for short lived certs) as of v1.18 which is our oldest currently supported[1] version.
We've got some basic docs[2] available. Profiles are set on a per-issuer basis, so it's easy to have two separate ACME issuers, one issuing longer lived certs and one issuing shorter, allowing for a gradual migration to shorter certs.
[1]: https://cert-manager.io/docs/releases/ [2]: https://cert-manager.io/docs/configuration/acme/#acme-certif...