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 have not created one at sign up, you can create one with the
org init command:
secrethub org init
You will be asked to type in a name for your organization. Pick something short and recognizable, e.g. your company name.
Shared workspaces work just like personal workspaces, so you can create repositories and directories too.
To follow along, create a repository named
secrethub repo init your-company/start
What you can do next is create a directory per environment or stage you have in your infrastructure, e.g.
secrethub mkdir your-company/start/dev echo "Hello Development" | secrethub write your-company/start/dev/hello secrethub mkdir your-company/start/prod echo "Hello Production" | secrethub write your-company/start/prod/hello
You can decide to give admins access to the
prod directory, but developers only to the
dev directory, for example.
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, let’s invite Alice to collaborate on the
secrethub repo invite your-company/start alice
Step 3: Set access rules
With Alice now invited into the repo, she cannot do too much without the proper ACL.
To give her access to all the secrets in the
dev directory, create an access rule:
secrethub acl set your-company/start/dev/ alice read
Access rules determine the permissions of users on a directory and its subdirectories, e.g.
Alice can now read all secrets in the
your-company/start/dev directory, including the
secrethub read your-company/start/hello
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/start/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 set up your SecretHub account using the CLI, 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.