Repository navigation
Use more clever certificate subject #617
Description
Well, currently all certificates get the subject CN=generated certificate for pod.
This imposes real security problems as shown in the code links below.
We should change that, so that one can actually use the subject for authorization. Things that come to my mind:
- OPA rules for Kafka using mTLS
- NiFi OPA rules and config
- @siegfriedweber mentioned the OpenSearch implementation also struggles with our current subject
Activity
nightkr commentedon Jul 8, 2025
The question is.. what would a good subject DN be? Node name is too broad to be useful (and is gonna cause bleed between different services that may or may not have a trust relationship..), the service scope should generally die in a fire, and pod name is too specific (you don't really want to distinguish between different replicas of the same service). The listener scope suffers from all of these problems at the same time, in addition to not really having a "primary" identity at all (it's just a bag of addresses, which works fine for SANs that we can have multiple of, but not so much for having to pick one subject DN).
I think a reasonable way to do it would be to use the Pod's ServiceAccount (and Namespace), which gives the user a reasonable amount of control but is also already treated as the permission boundary for accessing the K8s API itself. In an ideal world, it might have been worth using SPIFFE (like Istio already does), but in practice (at least last I checked) tooling support for URI SANs is abysmal (and of course generally even worse for things that assume that the subject DN is the only meaningful part of the certificate, or that the subject DN is meaningful at all).
NickLarsenNZ commentedon Oct 10, 2025
Do our products require that the Serving cert is also the one used for Client auth?
I've always used completely separate certificates for that (for one or both of ZooKeeper and Kafka). That way you can use a general CA for the server cert (eg: internal PKI), and for mTLS you can use a super restricted CA that is added to the client auth trust store for node-to-node comms.
I assume some of our products can't differentiate.
lfrancke commentedon Dec 15, 2025
We decided to look at this for real now as it's needed for OpenSearch.
The next/first step is a refinement where we discuss/brainstorm what a solution could look like, what we want to do and a recommendation how to continue so we can do a final go/no-go decision.
siegfriedweber commentedon Feb 19, 2026
The common name field has a limit of 64 characters (refer to RFC 5280). In contrast, pod names can be up to 253 characters, while namespaces are limited to 63 characters. FQDNs are therefore completely out of scope. As a result, addressing this issue will likely require the use of a non-meaningful identifier.
lfrancke commentedon Mar 19, 2026
Please feel free to ignore me. The current subject is entirely static and non helpful at all. To me it seems as if anything we do is better than what we have today.
@nightkr had the suggestion of using ServiceAccount + Namespace. If I understand her correctly it'd be something along the lines of
CN=hdfs-datanode, O=defaultas a subject then. That seems reasonable to me. We just need some truncation logic but that's also fine with me. I guess the service accounts are mostly under our control anyway and it's just the namespace that's up to the user so I'd truncate that.nightkr commentedon Mar 19, 2026
I don't remember saying that but it does make sense to me. :P
I would suggest still keeping some kind of "this was generated by secret-operator" tag, both to discourage people (and especially pre-SAN legacy code) from trying to parse it (instead of looking at the SAN) and to avoid confusion w/ people expecting it it to map cleanly onto DNS/LDAP/whatever else.
Can't speak for the OpenSearch case… "OpenSearch expects the CNs to be distinct, but doesn't care otherwise"?
siegfriedweber commentedon Mar 19, 2026
This approach may present a potential solution. However, if users have the ability to deploy pods within a namespace, they could easily create a pod that uses the OpenSearch ServiceAccount. Such a pod could impersonate an OpenSearch node, potentially joining an existing OpenSearch cluster and gaining access to read or modify its data.
I am actively seeking a solution that prevents this scenario. Currently, I am exploring the feasibility of utilizing the UID of the root of the managing controllers (identified via
ownerReferences) as the CN. In the case of OpenSearch, this would refer to the UID of the OpenSearchCluster, which is known to the operator and could be set as a trusted CN.siegfriedweber commentedon May 21, 2026
Pull requests:
siegfriedweber commentedon Jul 7, 2026
Release notes are in the linked pull requests.