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:
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
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
secrethub read your-company/your-project/dev/db-password
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
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.
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.