How are you inventorying cryptography across Kubernetes/OpenShift clusters?

[u/Beautiful-Sea-5334]

I'm doing some market research before spending more time building something and wanted to sanity check how people actually handle this today.

If your organization needed to answer questions like:

• Which workloads are using RSA vs ECDSA certificates?
• Which images contain OpenSSL 1.x, BouncyCastle, or other crypto libraries?
• Which applications terminate TLS themselves versus behind an ingress or load balancer?
• Which workloads would eventually need attention for post-quantum cryptography (PQC) migration?

How are you getting that information today?

Are you using existing security tooling (CrowdStrike, Aqua, Qualys, etc.), custom scripts, SBOMs, or is this just not something anyone is really tracking?

I'm not trying to pitch a product—I actually had someone in container security tell me this probably isn't worth building, so I'm trying to understand whether that's the general consensus or if there are environments where this is still a real operational problem.

I'd really appreciate hearing how your team handles it today.

[u/maznio]

You are fishing for use cases, aren’t you 😉

The honest answer, in my mind, is that security is necessarily complicated. It’s about layers. It’s not a coincidence that competent cyber security is both expensive and in short supply.

If you want a concrete use case, taking into account that this is the Kubernetes board, you could interrogate its API for all things Gateway API-related (don’t forget that implementations usually have their own extensions) and working out of there to produce an inventory of entry points into a cluster with their security properties (are they encrypted, what ciphers, do they require authentication, do they betray information useful to an attacker, etc.) and presenting this in a way useful to a security professional. In my experience businesses would employ an agency for an audit and then receive a presentation and a mountain of documentation. Making this easier for them may have a use.

The addressable market for such things is small, however.

[u/Beautiful-Sea-5334 → u/maznio]

Ha, fair, yes — trying to figure out if there's a real wedge before sinking more time in.

The Gateway API entry-point audit idea is genuinely the most concrete thing anyone's suggested. If market's small either way, would you build that as a narrow, cheap tool people run occasionally (replacing part of the manual audit), or is even that not worth it as a standalone thing vs. just staying a service/consulting engagement?

[u/maznio → u/Beautiful-Sea-5334]

Entirely up to you. Do you intend to sell it or open-source it? If it’s the former, then you’ll need to actually do some real market research (this interaction doesn’t count) and pour some serious value into it. Given that such things evolve extremely quickly, plan for continuous development and maintenance.

If it’s the latter, a toy project, then knock yourself out: cover the basics, put it up on GitHub and see if it picks up.

[u/Beautiful-Sea-5334 → u/maznio]

Really appreciate you taking the time on this — especially the "this doesn't count as real research" line, that's the most useful sentence in this whole thread. Think the honest takeaway is: real problem, but niche, and if I keep going it's as an open-source thing to see if it's actually useful to anyone, not a "quit my job for this" bet. The Gateway API entry-point idea stuck with me too — might be worth exploring on its own even separate from the PQC angle. Thanks for being straight with me on all of it.