.env files should only be used locally in a dev environment. Not sure using them in production is a thing anyone does?
Using something like KeyVault for production makes sense but I prefer to use CI/CD secret services that github / gitlab provide. Makes sense to me that secrets belong to the build / deploy process.
Can you explain why? If you're configuring secrets in your environment at the build step, they would still be accessible in the deployed system, thus no less vulnerable than if they're in a .env file aren't they?
I mean, if I have enough privilege to access a private file on a server, then theoretically, I can inspect the server's environment anyway.
Using secrets in CI/CD adds an additional level of protection for secret values through additional access controls but it isn't the only security needed. Assume you have a public repo but want to keep the secrets safe from people who have access to the source code, or you are a company with contractors who need to access the source code but should not have access to secrets.
If someone is able to access the server then other security should be considered such as using a VPC for private API's. Security should have lots of layers, protecting secrets by moving them outside the source code is just one layer.
I think this depends on what kind of secrets. CI/CD secret can be used for CI/CD, eg: secrets to access Docker, K8s cluster, artifact stores ... Application secrets are different layer, so we need extra tool to provide those. All artifacts should be stateless, loading application secrets is likely effect that happens on runtime instead build/deploy time.
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.
.env files should only be used locally in a dev environment. Not sure using them in production is a thing anyone does?
Using something like KeyVault for production makes sense but I prefer to use CI/CD secret services that github / gitlab provide. Makes sense to me that secrets belong to the build / deploy process.
A word of caution with this approach - make 100% sure you're not exposing your secrets in your artifacts!
Can you explain why? If you're configuring secrets in your environment at the build step, they would still be accessible in the deployed system, thus no less vulnerable than if they're in a
.envfile aren't they?I mean, if I have enough privilege to access a private file on a server, then theoretically, I can inspect the server's environment anyway.
I just feel like I'm missing something here...
Using secrets in CI/CD adds an additional level of protection for secret values through additional access controls but it isn't the only security needed. Assume you have a public repo but want to keep the secrets safe from people who have access to the source code, or you are a company with contractors who need to access the source code but should not have access to secrets.
If someone is able to access the server then other security should be considered such as using a VPC for private API's. Security should have lots of layers, protecting secrets by moving them outside the source code is just one layer.
I think this depends on what kind of secrets. CI/CD secret can be used for CI/CD, eg: secrets to access Docker, K8s cluster, artifact stores ... Application secrets are different layer, so we need extra tool to provide those. All artifacts should be stateless, loading application secrets is likely effect that happens on runtime instead build/deploy time.