As I mentioned, it's essential to encrypt your secrets rather than storing them as plain text. This way, even if someone can read your env variables, they won't be able to use it because it is a useless scrambled string of characters. Additionally, you can set the file permissions so that only the owner can read it, further protecting your secrets. Take the following Unix command as an example:
chmod 400 .env
This will ensure that only the file owner can read it and that no one else can access it. This is a great way to keep your sensitive information safe and secure and ensure that only those who need to see it can do so.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Now, the problem becomes tied to the party that you are sharing it with rather than the .env file itself. There is a risk in giving away your secrets to a centralized third party(Like Config servers), as it can become the main target for hacky wacky organizations. It is important to consider who you are sharing this information with and whether or not they can be trusted.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
The best solution sounds like hosting your own config server so you don't have to consider if the person you're sharing information with can be trusted while utilizing permissions and access restrictions. Win:Win.
Exactly. However, many startups nowadays are content to take the easy way out, opting for quick and easy solutions that don't really offer much in the long-term. They don't understand the risks involved in this approach, and only realize it when it costs them time and money.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As I mentioned, it's essential to encrypt your secrets rather than storing them as plain text. This way, even if someone can read your env variables, they won't be able to use it because it is a useless scrambled string of characters. Additionally, you can set the file permissions so that only the owner can read it, further protecting your secrets. Take the following Unix command as an example:
This will ensure that only the file owner can read it and that no one else can access it. This is a great way to keep your sensitive information safe and secure and ensure that only those who need to see it can do so.
What about sharing a secret to other? With a config server it’s as simple as ‘corp.secrets.com/config/DB_PASS/v2’.
In this case, you can create an Inbound firewall rule or add an entry in the ACL to allow only specific users to access this file.
Again giving full access to every secret in the file to that user.
Now, the problem becomes tied to the party that you are sharing it with rather than the
.envfile itself. There is a risk in giving away your secrets to a centralized third party(Like Config servers), as it can become the main target for hacky wacky organizations. It is important to consider who you are sharing this information with and whether or not they can be trusted.The best solution sounds like hosting your own config server so you don't have to consider if the person you're sharing information with can be trusted while utilizing permissions and access restrictions. Win:Win.
Exactly. However, many startups nowadays are content to take the easy way out, opting for quick and easy solutions that don't really offer much in the long-term. They don't understand the risks involved in this approach, and only realize it when it costs them time and money.