Shouldn't secrets never be present in the codebase but instead be retrieved via env variables that are populated from the configuration interface of your host provider? Furthermore, quite often those secrets will all change depending on the environment the application is on (local, ci, staging, production,...)
Technical Director Marketing Intelligence & Marketing Technology
at ABOUT YOU
❤️ #Development, mostly in #PHP via #Docker and #DataEngineering in Google #BigQuery
In general, yes. But that's kinda the point of the tool: Allow to store them in the codebase - but encrypted. Regading multiple environments: That's where I find it particularly helpful, because it's much easier to keep an overview if all secrets are "in one place". See e.g. pascallandau.com/blog/deploy-docke... for a concrete example.
I agree with you, keeping track of all environment vars across environments, and inside the team, is painful and is a real need that needs to be explored. Your work here is really helpful and interesting but I wonder couldn't it be less complicated ? For example, it could be simpler to store those vars in a vault (that is normally already used in the team), to avoid adding one more specific workflow.
Technical Director Marketing Intelligence & Marketing Technology
at ABOUT YOU
❤️ #Development, mostly in #PHP via #Docker and #DataEngineering in Google #BigQuery
Can you go into more detail how a vault solution would look like? E.g. we use keepersecurity.eu/vault/ in another team, but that's not easily integratable with a development process. Plus, "reviewing changes" is harder, because it's "another tool" than we use for our code reviews. Though that is also not perfect with git-secret, tbh, see pascallandau.com/blog/git-secret-e... ;)
That was an idea. I didn't even mean that it should be integrated with the development process directly nor reviewable. The idea is just to have a place to store them, just in case, to avoid getting all secrets by hand the day you need them.
But I think it all depends on the needs of your team.
Shouldn't secrets never be present in the codebase but instead be retrieved via env variables that are populated from the configuration interface of your host provider? Furthermore, quite often those secrets will all change depending on the environment the application is on (local, ci, staging, production,...)
In general, yes. But that's kinda the point of the tool: Allow to store them in the codebase - but encrypted. Regading multiple environments: That's where I find it particularly helpful, because it's much easier to keep an overview if all secrets are "in one place". See e.g. pascallandau.com/blog/deploy-docke... for a concrete example.
I agree with you, keeping track of all environment vars across environments, and inside the team, is painful and is a real need that needs to be explored. Your work here is really helpful and interesting but I wonder couldn't it be less complicated ? For example, it could be simpler to store those vars in a vault (that is normally already used in the team), to avoid adding one more specific workflow.
Can you go into more detail how a vault solution would look like? E.g. we use keepersecurity.eu/vault/ in another team, but that's not easily integratable with a development process. Plus, "reviewing changes" is harder, because it's "another tool" than we use for our code reviews. Though that is also not perfect with git-secret, tbh, see pascallandau.com/blog/git-secret-e... ;)
That was an idea. I didn't even mean that it should be integrated with the development process directly nor reviewable. The idea is just to have a place to store them, just in case, to avoid getting all secrets by hand the day you need them.
But I think it all depends on the needs of your team.
I was wondering the same thing?