https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# k3s
a
This message was deleted.
l
Also, if k8s handles the decryption on the fly for pod access, what is the threat model for secret encryption? It is literally just protecting against etcd compromise from outside the cluster?
c
the downside is that its slower because the apiserver has to encrypt/decrypt the resources whenever they are written or read
I personally don’t think it makes a huge difference from a threat model perspective, as the only thing it changes is that the secrets are now encrypted at rest in the datastore and in datastore backups. They’re still mounted unencrypted for any pods that use them as volumes, and the decryption key is stored on disk on the servers (because it has to be stored somewhere for the apiserver to read it).
l
Yeah okay, that's kinda what I was thinking too
c
I think it would make more sense if you were using an external datastore that was managed by a different team and you were worried about them pulling stuff out of it?
but if you’re using etcd or sqlite and everything is self-contained I don’t think it adds much
l
The only thing I can think of is if I accidentally had etcd accessible from the internet
Then that level of access in isolation means they can't read my secrets. But they can sure do some other stuff
But if they had access to the node in any other way, I don't see this doing anything
Thanks @creamy-pencil-82913, I just needed a sanity check there. I will proceed without
Outlines my thinking exactly
b
I think it would make more sense if you were using an external datastore that was managed by a different team and you were worried about them pulling stuff out of it?
I think you ended up summing up the reason in the previous reply
the secrets are now encrypted at rest in the ... backups
Generally speaking, this would be required for various compliance reasons at some of the places I've worked, regardless of whether there is other attack surface.
This article is compelling, but from my years hacking and attending defcon talks, I can already see a bunch of logical pitfalls.
l
Does secret encryption solve said logical pitfalls?
b
Nothing solves all of this. It's just about reducing attack surface
hacking is about getting through layers. the more layers, generally the better.
l
The most compelling part was pointing out that secret encryption doesn't really solve any part of the threat model
Yeah, it's always a tradeoff with complexity, eh?
💯 1
c
I just don’t believe that much is added by encrypting something if you stick the keys right next to the encrypted data. you’ve just increased overhead without increasing security.
🎯 1
b
yeah, there are a lot of assumptions in that threat model. i mean.. he even tries to use pcileech as an example, but that's a physical tool - how does that relate to most users that are in the cloud? there's just a lot of assumptions about scope
I understand, but your comment about in database backups was very relevant. the backups could end up in places where it's not next to the keys, and that would be a valid leak.
c
that was why I said it’s the only place I think it makes sense
external db service, or saving db snapshots to an external service
b
yeah, to wit i agree - and this is really about assessing the level of security you have to comply with. emphasis on comply
c
most k3s users dont do either
b
agreed
@late-barista-75996 btw, as evidenced by this discussion - never a question to be embarrassed about. I watch seniors debate this stuff all the time
2 Views
Open in Slack
PreviousNext
Powered by