Using secret values with source control

[inneon]

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:

meta {
  name: GET some protected data
  type: http
  seq: 1
}

get {
  url: {{base_url}}/protected/data
  body: none
}

headers {
  Authorization: shhh... please don't store this in source control
}

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.

[helloanoop]

Hi @inneon

2 approaches come to mind.

Option 1

The recommended way is to use an env variable. The environments are also stored as files inside the environments folder, which allows you to add some envs into .gitignore

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

# .gitignore
collection/environments/prod.bru

Option 2

Another approach I am thinking to support is dotenv
This is commonly used library in development, where a .env.local file is available in the repo without the secret vars, and the dev has to copy and create a .env file and add the secret credentials. The .env file is add to .gitignore so that it is not accidentally committed.

[inneon]

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. staging.bru and staging.secret.bru) and have the secrets file ignored.

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.

[helloanoop]

@inneon
I like the approach of staging.bru and staging.secret.bru

We should be able to get this functionality out over the weekend.

[helloanoop]

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 staging.secret.bru, qa.secret.bru appears excessive.

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.
A sample can .env.sample can be checked in to the repo.

DEV_OAUTH_CLIENT_SECRET = secret
QA_OAUTH_CLIENT_SECRET = secret
STG_OAUTH_CLIENT_SECRET = secret

The developer can then copy this sample to .env file (which is gitignored) and enter the secrets.

In the UI, you can enter the env variable value as {{env.DEV_OAUTH_CLIENT_SECRET}}

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 .env.vault where all the secrets get vaulted in the file, and can be decrypted with a single key. (This is a pattern used in for storing secrets in Ansible Playbooks)

[vrinek]

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:

• identifying the encrypted file (Rails uses filename.yaml.enc)
• ask user for a password (or read it from an environment variable)
• unencrypted the file in memory
• load the secrets

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 cat secrets.json.enc | gpg --decrypt. Bruno would run this in a subshell, and consider its output as the environment file's 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.

[fcr--]

From my experience in general, leaving secrets inside source code folders (even with .gitignore configured) ends up being a bad idea and a risky source of secrets being leaked. So, from my point of view what could be great is that we could have some way to mark environment variables as secrets, so that the value would get stored safely outside the actual environment file, eg: inside of an electron Store.

It would be great if those secret environments could still be used with bru.setEnvVar / bru.getEnvVar without having to worry about risking having those values in the same folder as where the collection is located.

[helloanoop]

@inneon

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.
If you want to store multiple access token across different envs, you may save in your .env

DEV_OAUTH_CLIENT_SECRET = secret
QA_OAUTH_CLIENT_SECRET = secret
STG_OAUTH_CLIENT_SECRET = secret

and reference it using the {{process.env.<secret-name>}} in your environments