-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using secret values with source control #122
Comments
Hi @inneon 2 approaches come to mind. Option 1The recommended way is to use an env variable. The environments are also stored as files inside the Ex: folder structure | - payments -api-service
| - src
| - collection
| - environments
| - qa.bru
| - prod.bru
- request1.bru
- request2.bru Assuming you don't want to store prod credentials, you can add them in # .gitignore
collection/environments/prod.bru Option 2Another approach I am thinking to support is dotenv |
Thanks for the quick reply @helloanoop . Option 2 sounds like it will work well for us if/when it happens. I had also wondered if #109 were to be implemented then maybe the secrets could be exported to a separate env file (e.g. Option 1 will not work for us. We would want a combination of shared and not shared variables in staging, prod and local environments. For now I think we will go with Postman :,( and keep an eye on Bruno when it is closer to a v1 . Feel free to close my question or convert it to a feature request or whatever is best for your issue list. Thanks. |
@inneon We should be able to get this functionality out over the weekend. |
I've given some time to think about how to manage secrets in a simpler way. I now feel that having individual secret files for every env like Here's my reasoning: While each environment may contain numerous variables, only a small subset of them actually require secrecy. Instead, a more streamlined approach would be to store the secrets in a single ".env" file, utilizing prefixes (e.g., DEV, QA, STG) to distinguish between different environments. I am thinking of dotenv approach. DEV_OAUTH_CLIENT_SECRET = secret
QA_OAUTH_CLIENT_SECRET = secret
STG_OAUTH_CLIENT_SECRET = secret The developer can then copy this sample to In the UI, you can enter the env variable value as This solves the problem of not having to checkin secrets into the repo. But the problem of sharing the secrets within the company remain. This problem is not unique to Bruno, but exists within all development codebases. While the ideal solution is to utilize a secret management platform, it is common for companies to resort to sharing secrets through channels like Slack or email. In the future, We can also support a |
One way I've seen this solved (eg Rails) is to check in the encrypted version of a secret into source control and only share the decryption key via a team password manager. The software (in this case Bruno) would handle:
Of course the opposite direction would need to be supported: take a secret, encrypt it, add it to the encrypted file. I am not familiar with dotenv, but it might be able to unencrypt something like this by itself. Another way, maybe simpler to implement and more versatile, is to support a sort of "shell script evaluation" environment file. I could have a file with the following contents I assume this would be easy to implement, but it would only serve power users. A more user-friendly secrets management feature would still need to be designed and implemented in the long term. One benefit of this two step approach is that the pioneers that write their own shell scripts might want to share their scripts for inspiration on how Bruno can solve this for everyone else. |
From my experience in general, leaving secrets inside source code folders (even with It would be great if those secret environments could still be used with |
I am pleased to share that we have introducing 2 ways to manage secrets. You can read more about it in the documentation I am sure you will like the dotenv based approach.
and reference it using the |
Question
Is it possible to use secrets with collections that are stored in source control without storing the secrets themselves?
Example
Imagine I had a request like this:
If I were to share this with my team then I will be checking in my auth token to the source control, which hopefully obviously is bad. I could extract it out to an environment, but that will still be checked in. Or alternatively I could remove it each time I commit, but that is prone to error.
The text was updated successfully, but these errors were encountered: