Share your secrets between your teams and applications with Secret Manager on Google Cloud Platform
First of all, what is Secret Manager? From documentation, “Secret Manager allows you to store, manage, and access secrets as binary blobs or text strings. With the appropriate permissions, you can view the contents of the secret”. A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a certificate.
But wait, there is already a key management system on GCP called Cloud KMS. What are the differences between Secret Manager and Cloud KMS?
- Cloud KMS is focused in the management of the cryptographic keys and use them to encrypt and decrypt data; but you cannot view, extract, or export the key material itself.
- Secret Manager provides a central place to manage, access, and audit secrets.
Let’s start with Secret Manager. To access to the Secret Manager console, from Google Console, go to “Security” > “Secret Manager”:
First time, we have to enable the “Secret Manager API”Share your secrets between your teams with Secret Manager on Google Cloud Platform
When the API is enabled, we can create our first secret (we need the Secret Manager Admin role (roles/secretmanager.admin) on the project).
In this page, we have to fill in the following properties:
- Name: choose a name for your secret.
- Secret value: you can upload or enter your secret. Nowadays the maximum payload is 64KBi.
- Regions: We have to choose a replication strategy. By default is automatic and the payload could be replicated without restrictions. For billing purposes, it’ll count as a single location. We can select where our payload will be replicated (see supported locations); but in this case, each location will be considered a separate location (see billing section at the end of this article).
- Encryption: by default it uses a Google-managed key, but you can use your own encryption key too.
- Labels: add the desired labels to your keys.
Notice that we have created the first version of our secret. We can rotate our key creating a new version (we can’t modify a version, we have to create a new one).
We can enter or upload the content and we can check “Disable all past versions”.
After pressing the “Add new version” button, we will see in the console that we have a new version enabled and the old one has been disabled.
You have to know that if a secret has been disabled, you can’t access to its content:
In case you need to access, you have to re-enable it.
An important point to keep in mind is that you will be billed for secrets that are in “Enabled” or “Disabled” status (active secrets). You have to destroy the secret version to avoid being billed but then you can’t access the secret payload anymore.
In summary, the lifecycle of a secret version is:
- Enabled: we can access the secret payload and we will be billed for it.
- Disabled: we want to deprecate this version (we are going to delete it in the near future) and we don’t give access to the secret payload (we will have to enable it if we have to gain access to the payload another time). Important to note that we will be billed for these as well.
- Destroyed: we will not have access to the payload anymore and we don’t be billed for it.
We are going to create a few more secrets. At the end, we have the following structure:
Our goal are going to set up the following policy:
- team1: only accessed by team members of the team1 group (create, manage and access)
- team2: only accessed by team members of the team2 group (create, manage and access) and allow team1 (only access)
But we haven’t seen any method to give access to our secrets during the creation. How are we going to achieve our goal?
Before moving on, we are going to explain the roles associated with Secret Manager service.
- Secret Manager Admin (roles/secretmanager.admin): Full access to administer Secret Manager resources.
- Secret Manager Secret Accessor (roles/secretmanager.secretAccessor): Allows accessing the payload of secrets.
- Secret Manager Secret Version Adder (roles/secretmanager.secretVersionAdder): Allows adding versions to existing secrets.
- Secret Manager Secret Version Manager (roles/secretmanager.secretVersionManager): Allows creating and managing versions of existing secrets.
- Secret Manager Viewer (roles/secretmanager.viewer): Allows viewing metadata of all Secret Manager resources.
Note: Please, don’t be confused by “Secret Manager Viewer” and “Secret Manager Secret Accessor”. To see the secret payload, we need the Secret Manager Secret Accessor role, the Secret Manager Viewer only allows to access to the secret metadata (e.g., to list the secrets).
If we want to give control the access to our secrets from Secret Manager console, we have to select one secret and press “Show Info Panel” button
In the info panel, we want review the actual permission and we can add new member:
And from the info panel, we can modify the access (only if the role is not inherited)
But we need a better way to give access to the team secrets because this way we have to give the permissions one by one.
If our project is part of an organization, the best way to assign permission is to use groups.
At organization level, go to “IAM & Admin” > “Groups”
And we are going to create the groups grp_team1 and grp_team2 (we can only add member of our own organization, no external users):
And we need a secret ingredient: IAM Conditions.
Go back to the project and go to “IAM & Admin” > “IAM”
Click “Add” button
Firstly, we are going to give access to team1. We add the “Secret Manager Viewer”, “Secret Manager Secret Accessor” and “Secret Manager Secret Version Adder” roles to the team members; but we need to restrict the access to only the own secrets adding a condition:
We are going to create a condition that allow permission to the resource which name starts with “projects/xxxxxx/secrets/team1_” (you can see the resource name if you access to the secret details or remember that the format is “projects/project-number/secrets/secret-id”)
Note: we don’t add any condition to the “Secret Manager Viewer” to allow list all the secrets (don’t grant access to the payload).
Now it’s time to check if everything is working fine. Login to the Google Cloud console with a team1 member, and go to Secret Manager console and check that you can list all the secrets:
And we can access to our team secrets:
And we can add a new version
But we don’t have access to the team2 secrets
If we want to grant team1 members read access to the team2 secrets, we need to modify the condition and add “Secret Manager Secret Accessor” to the team2 secrets:
Wait a couple a minutes until the policy will be applied and then you can access to the team2 secret:
One interesting option with IAM condition is that we can grant access for a limited period of time., e.g., if we want to grant temporary access to a consultant, you can add a “Expiring Access” condition to our rules
One more thing, we can follow the same procedure for applications via service accounts. Imagine that we create a secret for an application named app1 and we want to restrict access only for this application.
We need to a service account for this application in “IAM & Admin” > “Service Accounts”
After creation, download the key for the new service account
And go to “IAM & Admin” > “Admin” to allow access to the app1 secrets (grant the “Secret Manager Secret Accessor” role):
Then we can access from our application to their secrets:
But we can’t access to other application secrets:
Source code: https://github.com/daveresbk/gcpsecretmanager
But we have to answer the question: “Who and when our secrets has been accessed?”. The answer is Cloud Audit Logs.
The following table summarizes the which API operations correspond to each audit log type in Secret Manager:
By default, only Admin Activity (retention period: 400 days) is enabled in our projects. In this situation, as you can see in the table, if you access a secret payload, we don’t have any record of anyone accessing our secrets.
To enable Data Access audit logs (retention period: 30 days), from the Cloud Console, go to“IAM & Admin” > “Audit Logs”, and filter by “Secret Manager API” and in the Info Panel check “Data Read” logging
And now we can review that a log is created every time a user access to one secret
Finally, about pricing, nowadays the cost is based on the following two concepts:
- Active secrets version: $0.06 per version per location. A secret version is “active” if it is in an “enabled” or “disabled” state.
- Access operations: $0.03 per 10,000 operations. Management operations including creating secrets, destroying secrets, or changing the state of secret versions aren’t billed.
To wrap up, Secret Manager is a fully managed service that provides a central place to manage, access, and audit secrets on Google Cloud.
Compared with other commercial solutions, the price is more interesting if you have a large number of users because associated billing doesn’t depend on the number of users. And if your organization uses Google Workspace, your users will be automatically authenticated and gain quick access to their secrets. The only thing to have under control is the number of secret versions as the cost depends mainly on the number of active secrets. An improvement that I hope Google will implement in the future is to be able to apply a lifecycle policy on secret versions).
If you have a problem, maybe you should call the Bluekiri-Team
