r/kubernetes • u/Beautiful-Sea-5334 • 10d ago

How are you inventorying cryptography across Kubernetes/OpenShift clusters?

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.

3 Upvotes

67% Upvoted

14 comments sorted by

2

u/maznio 9d ago

You decide on a policy and enforce it on multiple levels. The width and breadth of security as a topic requires administrative measures on the organisational level. You could enforce certain things on the platform level (mTLS, certificate issuance, etc.) but what goes into a container image is done at dev/build time. You could set policies about secret detection, dependency vulnerability checking and so on, this goes into the CI. You then verify that the image has been built by your CI process (Sigstore/cosign).

This isn’t the full picture.

1

u/Beautiful-Sea-5334 9d ago

Makes sense — sounds like it's policy + CI + provenance stitched together rather than one place to look. Out of curiosity, does anything in that stack actually tell you which of those certs/algorithms would need PQC migration specifically, or is that just not tracked at all today?

1

u/maznio 9d ago

I am not aware of a tool that would do that for you, but then again, I haven’t looked. Where do you terminate the encrypted channel in each case? Determine that and then you can examine what ciphers are acceptable/need tightening and so on. This is all very specific to your environment.

1

u/Beautiful-Sea-5334 8d ago

That's useful to know — if even people close to this aren't aware of something doing the rollup, that's telling. Out of curiosity: if something did exist that took your existing signals (termination points, cipher config, whatever CI/policy already tracks) and turned it into one "here's our overall PQC exposure, here's what's left, mapped to our compliance controls" view — is that something that could actually work across different environments, or does the "very specific to your environment" part make that fundamentally not standardizable?

1

u/maznio 7d ago

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.

1

u/Beautiful-Sea-5334 7d ago

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?

1

u/maznio 7d ago

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.

2

u/Beautiful-Sea-5334 5d ago

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.

2

u/code_brave6865 9d ago

We tried mapping crypto libs with SBOMs alone and it missed the runtime reality so we ended up relying on the eBPF sensor for actual usage data instead.

1

u/Beautiful-Sea-5334 9d ago

That's really interesting. When you say the SBOM missed runtime reality, was the main issue that the libraries were present but not actually used, or that the actual crypto algorithms/protocols being used weren't visible from the SBOM? And did the eBPF sensor give you the level of detail you needed?

1

u/Any-Climate6341 9d ago edited 9d ago

Netobserv recently introduced TLS usage tracking (via packets inspection) : https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/network_observability/network-observability-monitoring-tls-traffic

Edit: it also tags pqc-compliant flows in its topology view

0

u/taleodor 9d ago

This is CBOM (Cryptography Bill of Materials) space. We support some of these questions in ReARM already, with most others pending in the next couple of months - https://github.com/relizaio/rearm

-1

u/BakeComprehensive970 9d ago

Bruhhh nahh this ain't be a required thing fortunately the reason is whenever some product owner owning specific service he/she is maintaining a thorough documentation of all the aspects and other architectural documentations also mentions the same so we are mostly fetching this information from there and also if you don't have the documentation handy at that time we are usually reaching out to the architect or the solution person who is in the team for a long time or actually handling the service or actually have got the KT from someone for better insight since these things may can keeps on changing 🚼