Share Secrets with Your Team

Next to creating service accounts for your apps, SecretHub is also built for secrets management within your team.

You can limit access to certain secrets to certain people and apply least privilege. Every user has its own key that can be revoked indepedently, which is much preferable over having some sort of master key that everyone shares to decrypt the entire treasure trove of secrets.

And you don’t need much to set all of this up:

  1. Create a shared workspace
  2. Invite your team
  3. Set access rules

Step 1: Create a shared workspace

To collaborate with team members, you can use a shared workspace. If you haven’t created a shared workspace yet on signup, do so now using the org init command:

secrethub org init

In your shared workspace you can create repositories and directories to organize your secrets, just like in your personal workspace. Check out the recommonded repository structure to find out the recommended approach to organize your secrets.

Step 2: Invite your team

It’s no fun working alone, so let’s invite some team members over.

SecretHub user accounts are personal accounts that are not tied to a single organization. This means that your team members need to have created an account before you can invite them to your organization.

After your colleague created an account – say that her name is Alice and she signed up with the username alice – you can invite her to your organization workspace using the org invite command:

secrethub org invite your-company alice

Next, you can invite her to collaborate on your project’s repository:

secrethub repo invite your-company/your-project alice

Step 3: Set access rules

After inviting your colleague to the repository, you should set access rules to grant them access to secrets. Access rules can be set on directories and the repository root and provide the account read, write or admin access on all secrets in the directory and its subdirectories.

For example, if you have all secrets for your dev environment stored in a directory named dev, you can give Alice access to read all of them using this command:

secrethub acl set your-company/your-project/dev alice read

Alice can now read all secrets in the your-company/your-project/dev directory, for example the db-password secret:

secrethub read your-company/your-project/dev/db-password

The prod directory is still hidden to her as she does not have rights on it. Under the hood all the encryption gets taken care of.

To allow Alice to also write to the dev directory, change the access rule to write permissions:

secrethub acl set your-company/your-project/dev alice write

With the updated access rule in place, she can now both read the secret and write a new version of it.


What’s Next?

So you’ve learned the basic SecretHub CLI commands, set up an application to automatically load the secrets it needs, and created a shared workspace for your team. That was it for the quickstart guide! 🎉

Having these building blocks in place, you can go ahead and start replacing every single plaintext secret that’s floating throughout your infrastructure with a reference, and inject the secret value the moment it’s needed.

🌏 See How SecretHub Integrates with Your Entire Stack