[10:18:27] elukey and I have been debugging a tls-related issue when trying to deploy an opensearch cluster using tls certificates from our own PKI issuer. The details are there https://phabricator.wikimedia.org/T406876#11284651 and TLDR, we were thinking about creating a new profile for the `discovery` issuer, that would have `client auth` added to its set [10:18:27] of usages [10:19:05] if any of that rings a bell to you, would you mind reading the ticket comment and reaching out if you think we're completely wrong? [10:53:03] <_joe_> I think client auth is needed for etch peer certs as well [10:53:09] <_joe_> Cc swfrench-wmf [11:48:06] Are you saying that we could re-use an existing profile, or that we both need the same profile to be created? [12:01:45] brouberol: the alternative is to add client-auth to the discovery's dse profile, so that other use cases like Spark etc.. would be able to leverage mTLS [12:02:06] I think it is fine to keep it disabled by default if not needed, but for DSE we should be ok [12:07:16] but I am not 100% sure if we want to keep discovery "free" from mTLS entirely for whatever reason [12:08:59] the only risk that I see is that a compromised application/deployment could require discovery certs to do mTLS with other services, but there is nothing requiring mTLS atm and using discovery [12:09:06] (at least afaics) [12:09:38] etcd (bare metal) has its own intermediate, separate from discovery [12:15:42] understood, thanks [12:16:35] > the alternative is to add client-auth to the discovery's dse profile, so that other use cases like Spark etc.. would be able to leverage mTLS [12:16:35] according to btullis, the spark/tls issue he'd been observing isn't mtls related, so I think opensearch really is the only app we currently have that requires mTLS [12:24:03] okok, and mTLS will be used only by the pod that boostrap "security configs" since it needs to properly authenticate to the opensearch API IIRC [12:24:27] so creating a new intermediate for a single TLS certificate (or just a bunch of them, one for each cluster) seems to be overkill [12:24:50] I mean I don't see the big security benefit, other than being paranoid :D [12:44:02] agreed. So a new profile for the discovery intermediate sounds like a good compromise [13:05:30] I think we can just extend the dse one, not sure if a new one would make a lot of difference [13:06:48] ack. I can send a patch that we can merge next week [13:07:15] Please make sure to include a comment with a link to your explanation etc.. [14:14:15] I submitted https://gerrit.wikimedia.org/r/c/operations/puppet/+/1196920 [14:26:42] super [14:30:40] I asked to my team an opinion, we'll sort it out on Monday [14:33:10] interesting ... IIRC, k8s etcd uses the PKI discovery issuer for peer <> peer connections and sets `ETCD_PEER_CLIENT_CERT_AUTH=true`. I've not looked closely yet, but I'm curious why that works if this doesn't ... [14:35:26] oh wait, no ... I forgot it's a dedicated issuer :) [14:37:18] s/issuer/intermediate/ [14:37:23] * swfrench-wmf needs more coffee