Distribute Credentials Securely in a Multi-Team Organization

In a small development team at a startup, it's generally okay for each developer to have access to all of the team's secrets (passwords, API tokens, private keys, .etc). But this approach becomes insecure as the size of the organization grows — a software engineering intern probably shouldn't have the password to your production database. Ideally, each employee in the organization should have access to the secrets they need to perform their job duties, and nothing more. This is essentially the principle of least privilege .

A Motivating Example

To make this discussion more concrete, let's imagine a hypothetical company, the Magura Group. The Magura Group has two teams: developers and marketing. The development team builds the company's flagship product, a web-based CRM platform, while the marketing team advertises the product and converts leads into sales. These teams both need to store and access secret credentials:

• The development team needs to store arbitrary secrets for use in the web app, such as the Stripe API key for processing payments and the SendGrid API key for sending email notifications.
• The marketing teams needs Zapier integration between TypeForm and Slack, so that when a customer submits the form, an alert is posted in a Slack channel. This requires Zapier to be configured with authentication tokens for both TypeForm and Slack.

It's clear that the two teams' access to secrets is mutually exclusive. The development team shouldn't be able to access the TypeForm web hook secret, and the marketing team shouldn't be able to access the SendGrid API key.

Introducing Zero's Teams Feature

Zero's solution for securely sharing secrets in an organization like the Magura Group is Teams. Here's an overview of how teams work:

• A team is simply a group of users. A single user can belong to multiple teams.
• A team can be assigned to one or more projects, giving each member of the team access to those projects' secrets.
• Multiple teams can be assigned to the same project if necessary.
• Only project owners can manage which teams are assigned to the project.

In this case of the Magura Group, the admin would create two teams, developers and marketing:

Employees can be invited to the appropriate team by entering their email.

The Magura Group essentially has two projects: website-dev, which houses the secrets necessary to develop and run the CRM web app, and marketing-integrations, which houses the authentication tokens needed to link TypeForm and Slack to Zapier. As expected, the developers team should be assigned to the website-dev project, and the marketing team should be assigned to the marketing-integrations project.

With this setup, developers will only see the website-dev project and marketing employees will only see the marketing-integrations project. Each project has a unique Zero token, meaning users can only retrieve secrets from projects their team is assigned to. Therefore, it is impossible for developers to retrieve the TypeForm / Slack keys, and it is impossible for marketing employees to retrieve the API keys used by the CRM web app.

Important to note that projects owners are responsible for assigning teams to projects. Also each team member can share his owned project with the team he participates in. This means that teams members can access projects from any other team member.

Wrapping Up

Zero's Teams feature gives you fine-grained control over access to your organization's secrets. While teams are simple to grasp, the feature is flexible enough to accommodate companies from small to large. Zero does not impose any restrictions on how your teams and projects are organized, so you are free to configure them to match the real-life structure of your organization.