3 ms·

Have a question about the safety of using environment variables to store sensitive information. e.g. suppose you have your postgres db url in an environment va

by pizza 5y ago

Have a question about the safety of using environment variables to store sensitive information. e.g. suppose you have your postgres db url in an environment variable - with the password in the string - isn't that a big no-no? If someone found an exploit in your web app container then they would also in theory get access to valuable secret info - the db data is by far most valuable part of your app imo. Is there a more managed way to handle this kind of secret?

jffry 5y ago
If your web app container can query the database, and your web app container is compromised, then yes the attacker could query the database. This is an issue independent of how you conveyed that access to the web app container. If you want to limit the blast radius, you will need to find ways to limit what parts of the database the web app has access to.
reportt 5y ago
> If someone found an exploit in your web app container [...] A good pattern here is to reverse proxy all requests to the application through something like nginx. My applications tend to have a back-end application that is not accessible to the internet, with an nginx instance that proxies all API requests itself. Only port 80 is public facing. If someone can get console access to an nginx container and then use that to springboard to another container and get root access there (again, where the only open ports are ports 80, maybe 8000?) to get envvars, they should get access to it all. If you are worried about secrets, check out the Docker Compose 3.9 documentation: https://docs.docker.com/compose/compose-file/compose-file-v3/#secrets https://docs.docker.com/compose/compose-file/compose-file-v3...
deckard1 5y ago
if the exploit is in your web app, then you're already too late. Security is about layering. Which is why postgres/mysql have users and permissions. One thing I typically do is prevent DELETE statements from the web app db user. You can also prevent access to tables or even columns. Or you can go in the opposite direction and YOLO-it by putting SQLite right in your web app process, following the recent craze. Environment variables are typically how secrets are used. Anything else is going to add further complexity and have another set of caveats. Env vars are simple and all devs (and programming languages) know how they work.

by pizza 5y ago

jffry 5y ago

If your web app container can query the database, and your web app container is compromised, then yes the attacker could query the database. This is an issue independent of how you conveyed that access to the web app container. If you want to limit the blast radius, you will need to find ways to limit what parts of the database the web app has access to.

reportt 5y ago

> If someone found an exploit in your web app container [...] A good pattern here is to reverse proxy all requests to the application through something like nginx. My applications tend to have a back-end application that is not accessible to the internet, with an nginx instance that proxies all API requests itself. Only port 80 is public facing. If someone can get console access to an nginx container and then use that to springboard to another container and get root access there (again, where the only open ports are ports 80, maybe 8000?) to get envvars, they should get access to it all. If you are worried about secrets, check out the Docker Compose 3.9 documentation: https://docs.docker.com/compose/compose-file/compose-file-v3/#secrets https://docs.docker.com/compose/compose-file/compose-file-v3...

deckard1 5y ago

if the exploit is in your web app, then you're already too late. Security is about layering. Which is why postgres/mysql have users and permissions. One thing I typically do is prevent DELETE statements from the web app db user. You can also prevent access to tables or even columns. Or you can go in the opposite direction and YOLO-it by putting SQLite right in your web app process, following the recent craze. Environment variables are typically how secrets are used. Anything else is going to add further complexity and have another set of caveats. Env vars are simple and all devs (and programming languages) know how they work.