4 ms·
Something else pulls from the vault and exposes it as a regular env var to your process. The .env file is a workaround to get this running locally! For open sou
by freeone3000 2y ago
Something else pulls from the vault and exposes it as a regular env var to your process. The .env file is a workaround to get this running locally! For open source, the simplest to explain is using a k8s secret mounted to a pod — pod identity allows access to the secret via rbac, which cannot be faked. Only that pod has access to that secret. But your process, running on the pod, sees it as an env var.
- boarnoah 2y agoThat doesn't cover what the GP was talking about with > (i.e. if someone were to gain access to a running Kubernetes container) right? Since those would still be secrets available in the env. I get that if someone has access to read your envvars, its a foregone conclusion already (about how compromised you are). However IIUC, the part of the point of doing things in memory with reading secrets (like with a Secrets Manager, is to eliminate having to keep secrets around as envvars/secret files in the runtime?
- freeone3000 2y agoIf they can snoop on env vars of a running pod, it can snoop on the process. A k8s secret could be a file in the pod or a env var in the process, but neither are a persistent file distributed to developers
- deleted 2y ago[deleted]