Table of contents
1.
Introduction
2.
Create, access, and add a secret version
3.
Secret Manager Best Practices
3.1.
Access Control
3.2.
Coding practices 
3.3.
Administration
4.
Encryption of secrets
5.
Access control with IAM
5.1.
Principle of least privilege
5.2.
IAM conditions
6.
Secret Manager Audit Logging
6.1.
Available audit logs
6.2.
Enable audit logging
6.3.
Permissions and roles
6.4.
View logs
6.5.
Route audit logs
7.
Choosing a Replication Policy
7.1.
Automatic 
7.2.
User managed 
8.
Enabling Customer-Managed Encryption Keys (CMEK) for Secret Manager
8.1.
Working of CMEK 
8.2.
Prerequisites 
8.3.
CMEK with automatic replication
8.4.
CMEK with user-managed replication
9.
Creating and managing expiring secrets
9.1.
Safely using expiring secrets
9.2.
Creating an expiring secret
9.3.
Updating a secret's expiration
10.
Event notifications for Secret Manager 
10.1.
Working of event notifications work in Secret Manager
10.2.
Event types
10.3.
Notification format
10.4.
Creating a service agent identity
10.5.
Misconfigured topics
11.
Rotating secrets 
11.1.
Working
11.2.
Updating a secret's rotation settings
12.
Secret Manager Service Level Agreement (SLA)
12.1.
Definitions
12.2.
Maximum Financial Credit
12.3.
SLA Exclusions
13.
Frequently Asked Questions
13.1.
What is a Cloud Technology?
13.2.
What are the primary components of the cloud ecosystem?
13.3.
What do cloud computing serverless components entail?
14.
Conclusion 
Last Updated: Mar 27, 2024
Medium

Secret Manager

Author Shivani Singh
0 upvote
Career growth poll
Do you think IIT Guwahati certified course can help you in your career?

Introduction

We sometimes save account information when we check in to a website ( user-id & password ). It facilitates our access to a website.

Similar to this, we require encrypted information to operate a program, such as a database connection details that include a password.

You can use Secret Manager to safely handle your keys if you use the GCP (secrets). Your secrets are encrypted by Secret Manager using a key that Google controls. Additionally, authorized users can see your secrets.

One or more secret versions are included with a secret, along with replication details and metadata-like labels. A secret version contains the real contents of a secret.

For the safe and easy storing of API keys, passwords, certificates, and other private information, use Secret Manager. For managing, accessing, and auditing secrets throughout Google Cloud, Secret Manager offers a centralized location and a single source of truth.

You can save the text in the encrypted secret data section of a secret using Secrets Manager. This normally comprises the database or service's connection information. These specifics may include the service's user name, password, server's name, IP address, and port number.

Create, access, and add a secret version

The Secret and Secret Version is made by:

Step 1: Navigate to the console's Secret Manager page.

Step 2: Click Create Secret on the Secret Manager page.

Step 3: Enter my secret in the Name field on the Create secret page.

Step 4: Enter my top-secret information in the Secret value area.

Step 5: Select "Create secret" from the menu.

 

To view the information in the unreleased version:

Step 1: Navigate to the console's Secret Manager page.

Step 2: Click my-secret on the Secret Manager page.

Step 3: Find version 1 in the Versions table on the Secret information page.

Step 4: To view moremore_vert, select View in the Actions column.

the menu, select View secret value.

Step 5: A dialogue window with the secret value appears. To close the dialogue, click Done.

 

To create a secret version, do the following:

Step 1: Navigate to the console's Secret Manager page.

Step 2: Select Add new version under View more more_vert on the Secret Manager page.

Step 3: Enter a value for the secret in the Secret value field of the Add new version dialogue (e.g. abcd1234).

Step 4: Select Add New Version from the menu.

Secret Manager Best Practices

Some best practices for using Secret Manager are introduced in this section.

Access Control

IAM restricts access to the Secret Manager API. When providing rights to secrets, adhere to the least privilege concept.

  1. Restrict ownership of the organization to a safe super admin account.
  2. As per the Best Practices for enterprise organizations, divide apps and environments (staging/production) into distinct projects. This makes sure that quotas are enforced individually and can assist isolate setups with project-level IAM binding.
  3. Select a position that has the bare minimum of permissions required, or, if necessary, establish a custom role.
  4. To restrict access to the necessary subset of secrets when secrets for numerous services are contained in a single project, utilize secret level IAM bindings or IAM Conditions.
  5. IAM Recommender can also help in locating excessively privileged IAM bindings.

Coding practices 

It is common practice to pass secrets to your application over the filesystem or environment variables, however, it is best to avoid doing so if possible:

  1. Application flaws like directory traversal attacks might become more severe when a secret is exposed on the filesystem since the attacker may be able to read the secret data.
  2. Misconfigurations like enabling debug endpoints or having dependencies that log process environment information may cause secrets to leak when they are consumed through environment variables.
  3. Consider the access controls of the data store before synchronizing confidential information to a different data store (like Kubernetes Secrets).

Administration

Unless your workload has specified location requirements (enforceable using the constraints/gcp.resourceLocations constraint), select the automatic replication strategy when establishing secrets.

Rather than utilizing the most recent alias, refer to secrets by their version number. Use the release procedures you now use to deploy updates to version numbers. While utilizing the most recent alias could be practical, if the hidden version has a bug, your workload might be prevented from using it.

Before erasing or deleting secrets, disable secret versions. Putting the secret in a state that appears to be destroyed but is reversible, aids in preventing outages. That is, before permanently eliminating, you can disable and wait a week to ensure there are no lingering dependencies.

Encryption of secrets

Your confidential data is always encrypted by Secret Manager before being saved to disc. The same hardened key management methods, including stringent key access controls and auditing, that we employ for our own encrypted data are used by Secret Manager to manage server-side encryption keys on your behalf. User data is encrypted at rest by Secret Manager using AES-256. There is no need to change how you access the service, there is no setup or configuration needed, and there is no discernible performance impact. When viewed by an authorized person, your private data is automatically and visibly decrypted.

The term "customer-managed encryption keys" (CMEK) describes the capacity to regulate and manage the encryption keys utilized to safeguard data associated with a Google Cloud service.

Access control with IAM

The Secret Manager API can only be used in accordance with the Identity and Access Management (IAM) roles.

Principle of least privilege

When you adhere to the principle of least privilege, you only give people the minimal amount of access to the resources they need in order to do a specific task. For instance, do not grant principals access to all the secrets in the project or organization only because they need access to one secret. Don't give a principal the authority to alter a secret if they simply need to read it.

IAM may be used to assign IAM roles and permissions at the level of a project, folder, organization, or Google Cloud secret. Permissions should always be granted at the lowest level of the resource hierarchy.

Don't give principals access to all secrets if they only require access to the value of one secret. For instance, for a single secret, you can provide a service account access to the Secret Manager Secret Accessor role (roles/secretmanager.secretAccessor).

Don't give a principal the authority to manage all secrets if they only need to manage one secret. For instance, you can grant the Secret Admin role (roles/secretmanager.admin) to a service account on a single secret.

IAM conditions

Some Google Cloud resources, such as Secret Manager resources, can have conditional, attribute-based access control defined and enforced using IAM Conditions.

You can implement conditional access in Secret Manager depending on the following characteristics:

  • Use date/time attributes to configure limited-duration, scheduled, or expirable access to Secret Manager resources. You might, for instance, permit access to a secret up until a particular date.
  • Resource names, resource types, and resource service attributes can be used to configure conditional access. You can configure conditional access in Secret Manager by using attributes of secrets and secret versions.

Secret Manager Audit Logging

To assist you in determining "Who did what, where, and when?" regarding your Google Cloud resources, Google Cloud services keep audit logs.

Only the audit logs for resources that are directly within your Google Cloud projects are included. The audit logs for the entity itself are contained in other Google Cloud resources including files, organizations, and billing accounts.

Available audit logs

There are several audit log kinds available for Secret Manager, including:

  • Audit logs for admin activity

Comprises "admin write" activities that store settings or metadata.

Audit logs for admin activity cannot be turned off.

  • Records of data access audits

Contains "admin read" actions that read configuration or metadata. comprises "data write" and "data read" actions that read or write data supplied by the user.

You must specifically enable Data Access audit logs in order to receive them.

Enable audit logging

Audit logs for admin activity are never disabled; they are always enabled.

Except for Data Access audit logs for BigQuery, which cannot be disabled, data access audit logs are disabled by default and are not written unless expressly enabled.

Permissions and roles

Your ability to view audit log data in Google Cloud resources is determined by IAM permissions and roles.

Consider the following when determining which Logging-specific permissions and roles apply to your use case:

  • You have read-only access to the audit logs for Admin Activity, Policy Denied, and System Event when you have the Logs Viewer role (roles/logging.viewer). You cannot examine Data Access audit logs in the _Required and _Default buckets if you only have this role.
  • Along with the rights found in roles/logging.viewer, the Private Logs Viewer role (roles/logging.privateLogViewer) also has the ability to read Data Access audit logs in the _Required and _Default buckets.

View logs

You must know the audit log name, which contains the resource identifier of the Cloud project, folder, billing account, or organization for which you wish to view audit logging information, in order to conduct a query for audit logs.

Step 1: Navigate to the Logging> Logs Explorer page in the console.

Step 2: Choose a project, folder, or organization that is already in the Cloud.

Step 3: Make the following changes in the Query builder pane:

  • Choose the Google Cloud resource you want to view the audit logs for under Resource type.
  • Choose the audit log type you want to view under Log name:
  • Select activity to view the audit logs for admin activity.
  • Select data access to view the audit logs for Data Access.
  • Select system events to view the audit logs for System Events.
  • Select policy to view audit logs for Policy Denied.

If you don't see these choices, then the Cloud project, folder, or organization doesn't have any audit logs of that kind.

Route audit logs

The same methods used to route other types of logs can also be used to route audit logs to supported destinations. You may want to route your audit logs for the following reasons:

  1. You can route copies of your audit logs to Cloud Storage, BigQuery, or Pub/Sub if you want to preserve them for a longer time or utilize more robust search tools.
  2. You can establish aggregated sinks that can route logs from any or all Cloud projects in the business in order to manage your audit logs throughout the entire organization.
  3. You can build sinks that exclude the Data Access audit logs from Logging if your enabled Data Access audit logs are pushing your Cloud projects beyond your log allotments.

Choosing a Replication Policy

Secrets have global names and globally duplicated metadata, but the replication policy allows for control over where the secret payload data is stored. Each secret has a unique replication policy that is set when the secret is created. The replication policy's sites cannot be changed.

Automatic 

The payload data of a secret with an automatic replication policy can be reproduced without limitations. The most common user-recommended configuration is this one because it's the simplest. This is the replication policy that will be used by default when generating a secret using the web UI or Google Cloud CLI.

A secret with an automatic replication policy is regarded as being kept in a single location for billing purposes.

User managed 

Data from a secret's payload is duplicated to a user-configured list of sites under a user-managed replication strategy. The secret can be copied to as many supported locations as desired. If there are restrictions on where the secret payload data can be stored, this might be helpful.

Each location in the user-managed replication policy is treated separately for billing purposes.

Enabling Customer-Managed Encryption Keys (CMEK) for Secret Manager

Tools are available from Secret Manager to store, manage, and access secret data in your apps. Secrets kept in Secret Manager are automatically encrypted using Google's default encryption. Without any setup needed, secret payloads are encrypted using Google-managed keys before being written to persistent storage when using Google-default encryption. For many enterprises, Google's default encryption is the best option.

CMEK support for Secret Manager enables you to customize the Cloud KMS key that safeguards data at rest in Secret Manager for businesses that desire more control.

Working of CMEK 

Secret Manager encrypts the data with a special data encryption key prior to writing a secret version to persistent storage in a specific location (DEK). This DEK is then encrypted using a key encryption key (KEK) that belongs to the Secret Manager service and is replica-specific.

The KEK is referred to as a CMEK key and is a symmetric key that you control within Cloud KMS when using CMEK for Secret Manager. The secret version replica it encrypts must be in the same GCP location as the CMEK key. In the CMEK policy, a Cloud EKM key can also be used for encryption and decryption.

Prerequisites 

To set up Secret Manager with Cloud KMS, finish the following requirements:

Unknown Manager:

  • Use a new project or one that already exists to store your Secret Manager resources.
  • Follow the instructions in the Secret Manager quickstart's Configuring Secret Manager section, if necessary.

Cloud KMS

  • To store your Cloud KMS resources, either create one or use a current project.
  • Enable the Cloud KMS API if necessary.

CMEK with automatic replication

Your CMEK key needs to be situated in the global Cloud KMS multi-region for secrets that adhere to the automatic replication policy. Because Cloud EKM keys aren't accessible in the global region, using one prevents you from configuring your secret to use automatic replication.

Use an existing key or generate a new symmetric Cloud KMS key in the global Cloud KMS region. In this example, a new key called my-cmek-key is created on a new key ring called secret-manager-cmek.

CMEK with user-managed replication

You have control over the GCP location where the secret is kept when you employ a user-managed replication policy. Access to secrets is always possible from any GCP location.

Cloud KMS keys for secrets with a user-managed replication policy must precisely correspond to the places where the secret versions are kept. The examples in this manual conceal a secret in the us-east1 and us-central1 locations, respectively. One of these places receives requests to access the secret.

Create a key ring and a Cloud KMS key for encryption in each of the two regions, or use an existing key. In this example, a new keyring named "secret-manager-cmek" is created, and then a key named "my-cmek-key" is created in each region.

Creating and managing expiring secrets

By default, secrets kept in Secret Manager stay active until they are deleted by the user. You can give a secret an expiration date if it should only be kept for a specific period of time. A secret is automatically erased when it reaches its configured expiration time.

Consider using IAM Conditions or the Disabled version state to safely revoke access if there are no requirements that the secret must be erased.

A timestamp or a duration can be used to express an expiration when entering it. Regardless of how it was provided, the expiration will always be returned when accessing secret metadata as a timestamp. A secret's expiration can at any moment be added, changed, or eliminated.

Safely using expiring secrets

A secret in Secret Manager is permanently deleted after it expires. Using IAM Conditions to revoke rights from the accounts that utilize the secret before it expires is the most effective technique to identify soon-to-expire secrets.

Attach a time-based condition to the binding when granting permissions on a secret to doing this. The secret should cease to be utilized before the binding expires, but it should do so early enough for the revoked rights to be observed. After rights are revoked, it is possible to immediately mitigate if workflows that were believed to no longer use the secret break. The secret expiration can be changed or even eliminated if more time is needed.

Creating an expiring secret

  1. To make an expiring secret with a timestamp, do the following:
gcloud secrets create "SECRET_ID" \
    --replication-policy "automatic" \
    --expire-time "TIMESTAMP"

2. How to use a duration run to make a secret that expires:

gcloud secrets create "SECRET_ID" \
    --replication-policy "automatic" \
    --ttl "DURATION"

Updating a secret's expiration

Any secret, regardless of whether it already has one, can have a new expiration assigned to it. There can only ever be one specified expiration for each secret. A secret's existing expiration will be overwritten if its expiration is updated.

Using a timestamp, modify the expiration date of a secret:

gcloud secrets update "SECRET_ID" \
    --expire-time "TIMESTAMP"

Using a duration run, modify the expiration date of a secret:

gcloud secrets update "SECRET_ID" \
    --ttl "DURATION"

To remove a secret's expiration run:

gcloud secrets update "SECRET_ID" \
    --remove-expiration

Event notifications for Secret Manager 

Event notifications notify Pub/Sub of updates to your secrets and secret versions. These alerts can be used to initiate any workflow you want, like restarting an application when a new secret version is added or alerting security engineers when a secret is destroyed.

Working of event notifications work in Secret Manager

Up to 10, Pub/Sub topics may be set for Secrets. The secret Manager will instantly publish a message to each of the secret's Pub/Sub topics whenever an operation is carried out that alters the secret or one of its versions. Message publications are not the result of getting, List, and Access calls.

Pub/Sub messages include a "data" field that contains a complete JSON serialization of the Secret or SecretVersion resource that was created or modified, as well as a collection of "attribute" key-value pairs containing metadata about the event. This JSON is a UTF-8 encoded string that precisely matches the format required by the Secret Manager public API. It is encoded in JSON in accordance with the proto3 JSON Mapping.

Event types

These are the following types of events:

  • SECRET CREATE sent after successfully creating a new secret.
  • When a new secret is successfully updated, a SECRET UPDATE is sent.
  • SECRET DELETE is sent when a secret is removed, either at the user's request or when the secret has expired.
  • When a new secret version is successfully added, the message SECRET VERSION ADD is sent.
  • SECRET VERSION ENABLE sent if the hidden version setting is active.
  • SECRET VERSION DISABLE sent when a hidden version is turned off.
  • SECRET VERSION DESTROY is sent whenever a hidden version is wiped off.
  • SECRET ROTATE sent whenever a secret is ready to be rotated. For further details, see Creating and controlling rotation policies on secrets.

Notification format

Attribute: Key-value pairs called attributes are seen in alerts that Secret Manager sends to your Pub/Sub topic.

Data: The metadata of the modified object is contained in the data field, which is a UTF-8 string. Either a Secret Version or Secret Data exists. The metadata in the data field for SECRET DELETE notifications corresponds to the object metadata prior to the delete.

Creating a service agent identity

For any project that needs secrets with event notifications, you must build a service agent identity.

Run the following command to create a service identity using Google Cloud CLI:

gcloud beta services identity create \
    --service "secretmanager.googleapis.com" \
    --project "PROJECT_ID"

The aforementioned command provides a service account name in the format:

service-PROJECT_NUMBER@gcp-sa-secretmanager.iam.gserviceaccount.com

The service account name should be saved as an environment variable:

# This is from the output of the command above

export SM_SERVICE_ACCOUNT="service-...."

Misconfigured topics

In the event that Pub/Sub topics are added to a secret during a Create or Update activity, but Secret Manager is unable to publish messages to the topic because of a misconfiguration, the operation will fail with an error message describing the cause of the publish failure. This might take place, for instance, if the topic doesn't exist or the Secret Manager service account isn't authorized to post.

Secret Manager will write logs to the Secret Manager Secret resource with a message explaining why the publish failed if Pub/Sub topics are added to a secret and then the topic is changed such that Secret Manager can no longer publish messages (for example, the topic is deleted, or the Secret Manager service account permissions are removed).

Rotating secrets 

Rotation schedules for secrets are supported by Secret Manager. On the basis of the specified rotation frequency and rotation time, Secret Manager distributes messages to Pub/Sub topics set on the secret. This post explains how to create one-time or ongoing calendars for your secrets so that you may get alerts when it's time to rotate them.

Secrets should be rotated periodically to:

  • Reduce the amount of time a spilled secret is valid and exposed.
  • Rotation flow should be continuously practiced to ensure process reliability.

Working

The Pub/Sub topics set up on the secret receive a SECRET ROTATE message from Secret Manager at the secret's next rotation time. There are two ways to set this timestamp:

  • Given by the user when he or she creates or updates the secret.
  • When a rotation period has passed if one has been specified, Secret Manager will issue a SECRET ROTATE message. The modified next rotation time will be shown in the next rotation time.

To receive and respond to SECRET ROTATE messages, you must set up a Pub/Sub subscriber. Add more workflows as needed, such as launching application deploys and creating a new secret version.

Updating a secret's rotation settings

True update The following mask pathways are available for rotation: rotation, rotation. next rotation time, and rotation.rotation period.

If you want to modify a secret's next rotation time:

$ gcloud secrets update secret-id \
  --next-rotation-time "2022-06-01T09:00:00Z"

To remove a secret's next_rotation_time:

$ gcloud secrets update secret-id \
  --remove-next-rotation-time

To remove a secret rotation schedule. This removes both the next_rotation_time and rotation_period:

$ gcloud secrets update secret-id \
  --remove-rotation-schedule

Secret Manager Service Level Agreement (SLA)

The Covered Service must provide to the Customer a Monthly Uptime Percentage of 99.95% for the Term of the Agreement (where applicable, the "Agreement") under which Google has agreed to provide Google Cloud Platform to the Customer (the "Service Level Objective" or "SLO"). If the Customer complies with its duties under this SLA and Google does not reach the SLO, the Customer will be qualified to earn the Financial Credits listed below. According to each project, the Monthly Uptime Percentage and Financial Credit are calculated monthly. This SLA outlines the Customer's one and only recourse in the event that Google does not fulfill the SLO. The definitions given to capitalized terms used in this SLA but not elsewhere defined in this SLA are found in the Agreement.

All references to "Customer" in this SLA shall refer to "Partner" or "Reseller" (as applicable), if the Agreement permits the resale or supply of Google Cloud Platform through a Google Cloud partner or reseller program. Any applicable Financial Credit(s) shall only apply to impacted Partner or Reseller order(s) under the Agreement.

Definitions

The SLA is defined according to the following terms:

  • Secret Manager access operations are referred to as "Covered Service."
  • Moreover, a 10% error rate is considered to be "downtime."
  • "Downtime Period" refers to a stretch of downtime lasting five or more minutes in a row during which at least ten valid requests are sent. Intermittent downtime that lasts less than five minutes is not included in any downtime calculations.
  • A time period's "error rate" is calculated by dividing the total number of valid requests during that time by the number of valid requests that receive an HTTP Status Code in the 500 range or do not receive a response within ten seconds of Google receiving the request. The server-side health monitoring is used by Google to calculate the error rates.
  • "Monthly Uptime Percentage" is calculated by dividing the total number of minutes in a month by the total number of minutes in a month, minus the total number of minutes of Downtime experienced during all Downtime Periods in a month.
  • The term "Valid Requests" refers to Secret Manager access requests that comply with the Documentation and would typically receive a non-error answer.

Maximum Financial Credit

A single billing month's worth of Financial Credits from Google to the Customer for all Downtime Periods cannot total more than half of what the Customer owes for the Covered Services during that month. Financial Credits shall be given in the form of a cash credit that can be used to purchase future access to the Covered Services, and they will be given within 60 days of the request.

SLA Exclusions

The SLA does not apply to any (a) features or services marked as pre-general availability (unless otherwise specified in the associated Documentation); (b) features or services excluded from the SLA (in the associated Documentation); or (c) errors that were I brought on by circumstances beyond Google's reasonable control; (ii) caused by customer software or hardware or third-party software or hardware, or both.

Frequently Asked Questions

What is a Cloud Technology?

In order to provide computing as a service, a cloud is made up of a variety of services, networks, hardware, storage, and interfaces. There are often three users. These include cloud service providers, end users, and business management, users. The person who utilizes cloud services is known as the end-user. The business management user in the cloud is in charge of the data and services that are offered by the cloud.

What are the primary components of the cloud ecosystem?

The following components of the cloud ecosystem affect how you perceive cloud architecture: Internet users, Direct clients, providers of cloud services

What do cloud computing serverless components entail?

Cloud computing's serverless components make it possible to create apps without having to deal with the hassle of managing the infrastructure. It is possible to write code without having access to a server.

Virtual machines and container management are handled by serverless machines. The serverless components also take care of multithreading and hardware allocation.

Conclusion 

To sum it up, in this blog we discussed how to create, access, and add a secret version. Then we looked at secret manager best practices, encryption of secrets, and access control with IAM. we also discussed secret manager audit logging, choosing a replication policy, Enabling Customer-Managed Encryption Keys (CMEK) for Secret Manager, creating and managing expiry secrets, events notifications for the secret manager, rotating secrets, and last but not least we discussed Secret Manager Service Level Agreement (SLA).

For more content, Refer to our guided paths on Coding Ninjas Studio to upskill yourself.

Do upvote our blogs if you find them helpful and engaging!

Happy Learning!

thank you image
Live masterclass