Skip to main content
10 events
when toggle format what by license comment
Nov 20, 2024 at 10:20 answer added Rory McCune timeline score: 2
Nov 19, 2024 at 16:13 history edited PatPanda CC BY-SA 4.0
added 525 characters in body
S Nov 19, 2024 at 16:07 history suggested Ali Khan CC BY-SA 4.0
enhanced filepaths and question structure
Nov 19, 2024 at 16:07 comment added PatPanda I took away BASH, i.e. there is no way to exec inside the container (updating the question to reflect that) What you said would still hold even if there is no way to exec inside the container?
Nov 19, 2024 at 13:41 comment added Margaret Bloom Having said that, you can tell Spring to use vault directly: spring.io/guides/gs/vault-config. This should make Spring read the secrets directly from Vault and keep them in memory (double check that). Note that a root attacker can still dump the secret from the memory of each (containerized) process.
Nov 19, 2024 at 13:40 comment added Margaret Bloom If someone controls the k8s worker node, they can surely run a process inside the kernel namespace of each container. I.e., they can surely run a shell inside each pod, don't they? So they can read every secret, envars or files, that Vault created in the pods (and can also read the Vault credentials). Vault didn't solve the problem of how to securely configure an application, just the problem of how to securely manage secrets. If your TM includes root on the worker, you need to move to enclaves to keep the pods safe.
Nov 19, 2024 at 11:54 review Suggested edits
S Nov 19, 2024 at 16:07
Nov 18, 2024 at 17:56 comment added CommunityBot Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.
S Nov 18, 2024 at 17:43 review First questions
Nov 18, 2024 at 17:56
S Nov 18, 2024 at 17:43 history asked PatPanda CC BY-SA 4.0