← Back to context Comment by burnished 15 hours ago There isn't really a way around it. 7 comments burnished Reply jimnotgym 10 hours ago Run your own servers so the .env isn't shared with your hosting provider? otabdeveloper4 13 hours ago There is -- you can expose a UNIX socket for serving credentials and allow access to it only from a whitelist of systemd services. rcxdude 12 hours ago They would still exist in plaintext, just the permissions would make it a little harder to access. otabdeveloper4 9 hours ago No, UNIX sockets work over SSL too.You can, theoretically, decompile the system memory dump and try to mine the credentials out of the credential server's heap, but that exploit is exponentially more difficult to do that a simple `cat /proc/1234/environ`. lemagedurage 10 hours ago That works on a single persistent box, but unfortunately, that means giving up on autoscaling, which is not so nice for cloud applications. otabdeveloper4 9 hours ago You can proxy the UNIX socket to a network server if you want to. You can even use SSL encryption at all times too. 1 reply →
otabdeveloper4 13 hours ago There is -- you can expose a UNIX socket for serving credentials and allow access to it only from a whitelist of systemd services. rcxdude 12 hours ago They would still exist in plaintext, just the permissions would make it a little harder to access. otabdeveloper4 9 hours ago No, UNIX sockets work over SSL too.You can, theoretically, decompile the system memory dump and try to mine the credentials out of the credential server's heap, but that exploit is exponentially more difficult to do that a simple `cat /proc/1234/environ`. lemagedurage 10 hours ago That works on a single persistent box, but unfortunately, that means giving up on autoscaling, which is not so nice for cloud applications. otabdeveloper4 9 hours ago You can proxy the UNIX socket to a network server if you want to. You can even use SSL encryption at all times too. 1 reply →
rcxdude 12 hours ago They would still exist in plaintext, just the permissions would make it a little harder to access. otabdeveloper4 9 hours ago No, UNIX sockets work over SSL too.You can, theoretically, decompile the system memory dump and try to mine the credentials out of the credential server's heap, but that exploit is exponentially more difficult to do that a simple `cat /proc/1234/environ`.
otabdeveloper4 9 hours ago No, UNIX sockets work over SSL too.You can, theoretically, decompile the system memory dump and try to mine the credentials out of the credential server's heap, but that exploit is exponentially more difficult to do that a simple `cat /proc/1234/environ`.
lemagedurage 10 hours ago That works on a single persistent box, but unfortunately, that means giving up on autoscaling, which is not so nice for cloud applications. otabdeveloper4 9 hours ago You can proxy the UNIX socket to a network server if you want to. You can even use SSL encryption at all times too. 1 reply →
otabdeveloper4 9 hours ago You can proxy the UNIX socket to a network server if you want to. You can even use SSL encryption at all times too. 1 reply →
Run your own servers so the .env isn't shared with your hosting provider?
There is -- you can expose a UNIX socket for serving credentials and allow access to it only from a whitelist of systemd services.
They would still exist in plaintext, just the permissions would make it a little harder to access.
No, UNIX sockets work over SSL too.
You can, theoretically, decompile the system memory dump and try to mine the credentials out of the credential server's heap, but that exploit is exponentially more difficult to do that a simple `cat /proc/1234/environ`.
That works on a single persistent box, but unfortunately, that means giving up on autoscaling, which is not so nice for cloud applications.
You can proxy the UNIX socket to a network server if you want to. You can even use SSL encryption at all times too.
1 reply →