Secret Manager: protect your secrets from inside threats

The secrets are the ultimate piece to protect: password, API Keys, private keys, root certificates,… There are several types of secrets but all needs to be kept safe and private. On Google Cloud, Secret Manager service helps to achieve this by keeping the secrets encrypted and protected by IAM.

IAM secret protection

Out of the box, Secret Manager offers a fine grained policy to grant access on individual secrets to enforce the least privilege principle. Like this, only the accounts (user account, or service account) that need to access to some secrets are allowed to reach them, but they can’t access the other secrets, even inside the same project.
It’s true for the accessor role (to read the secret), but also for creating new secret versions for instance.

Seth Vargo has released a great video on that topic.

However, the difficulties begin when several set of users need to administrate the secrets. Let’s say :

• A DevOps team which manages the certificates resources, the database, and the secrets related to them.
• A Development team which use API keys to access to third party service and needs to keep this secret safe.

All the project longs, some secrets no longer exist and must be created by each teams, in their perimeter. And because the secrets no longer exist, you can’t grant IAM role on them and achieve least privilege as described before.

So the teams have a Secret Manager admin role at the project level, and thus, can view and delete any secrets in the project!

How to achieve the least privilege principle when 2 teams work on the same project?

There are solutions, such as “Create a new project” or “Let all the secrets creation done by the DevOps team”.
Yes, but there is another way: IAM conditions.

IAM conditions on Secret Manager

The IAM service has a feature named “condition”. Obviously explicit, you can grant role only in the condition is met.

To apply that on our use case, there are 2 requirements

• The users account (or groups) haven’t legacy roles (Viewer, Owner, Editor). IAM conditions can’t be applied on legacy roles.
• Each group of users use a naming convention and prefix all the secrets with the same value. For instance, devops- for the devops team and dev- for the dev team.

Then, use IAM condition to configure the access.

• The devops accounts have only access to the devops- prefixed secrets
• The developer accounts have only access to the dev- prefixed secrets

Go to the IAM page and click on the add button. For the dev team, you can have that

Click on Add condition. Select the Resource -> Name type of condition

Then the operator Starts with and finally the secret prefix

!!! STOP !!!

It won’t work. Several reasons

• The value must be the fully qualified name of the secret with this pattern

projects/<projectNb>/secrets/dev-

Note that the project number is required, not the project ID!!

• The rule means “You have the Secret Manager Admin role when the full name of the secret starts with…”. But, when you want to create a secret, the secret name no longer exists, you are going to create it! So you also need the role when no secret exists

Correct IAM condition expression

To solve that, you need to express the opposite:

• The developer accounts don’t have access to the devops- prefixed secrets

For that, you need to go to the condition Editor tab, and enter this condition

!(resource.name.startsWith("projects/<projectNb>/secrets/devops-"))

Name the condition, save it and validate the IAM roles.

If you prefer the CLI, you can do that like this

gcloud projects add-iam-policy-binding <projectId> \
  --condition=expression='!(resource.name.startsWith("projects/<pojectNb>/secrets/devops"))',\
title='no devops secret access' \
  --role=roles/secretmanager.admin \
  --member=group:dev-accounts@gblaquiere.dev

Now, the developer accounts don’t have access to the devops secrets, with the condition that the devops teams name correctly the secrets.
And the developer accounts can also create new secrets

Protect your secrets, anytime

With Secret Manager, your secrets are safe and you can trust this service.

However, you need to configure smartly your roles and permissions on your project to prevent secret leaks and thus security breaches, even from inside.

IAM condition is an elegant way to achieve this use case and can do much more!