Secret Manager release notes

Secret Manager is generally available in your Google Cloud Dedicated universe.

The Secret Manager add-on for Google Kubernetes Engine (GKE) now supports the automatic rotation of secrets. You can configure the Secret Manager add-on to automatically rotate secrets so that secrets updated in Secret Manager after initial pod deployment are automatically and periodically pushed to the pod. This feature is available in Preview.

For more information, see Configure automatic rotation of secrets.

Secret Manager is now available in the following region:

• europe-north2 (Stockholm)

For more information, see Secret Manager locations.

Parameter Manager, currently in Preview, now offers a console for storing, accessing, and managing the lifecycle of your workload parameters. For more information, see the Parameter Manager documentation.

Parameter Manager, an extension to the Secret Manager service, is available in Preview. You can use Parameter Manager to store, access, and manage the lifecycle of your workload parameters. For more information, see Parameter Manager overview.

Creating custom organization policies with Secret Manager resources is now in General Availability (GA). You can use custom organization policies to enhance secret security by enforcing rotation schedules, annotations, and expirations for secrets. You can also use custom organization policies to restrict secret types to manage costs. To learn more about using custom organization policies in Secret Manager, see Use custom organization policies.

Secret Manager is now available in the following region:

• northamerica-south1

For more information, see Secret Manager locations.

Creating regional secrets using Secret Manager is now in Generally Availability (GA). Regional secrets let you store your sensitive data within a specific geographic location, ensuring it remains in that region at all times – whether at rest, in use, or in transit. Regional secrets are crucial for meeting data residency requirements and complying with regulatory mandates.

For information about all tasks related to creating and managing regional secrets, see the Regional service documentation.

Secret Manager is now enabled for use with Cloud KMS Autokey.

Using keys generated by Autokey can help you consistently align with industry standards and recommended practices for data security, including the HSM protection level, separation of duties, key rotation, location, and key specificity. Keys requested using Autokey function identically to other Cloud HSM keys with the same settings.

For more information, see Enable customer-managed encryption keys for Secret Manager. To learn more about Cloud KMS Autokey, see Autokey overview.

You can now create regional secrets using Secret Manager. When you create a regional secret, you specify the location where you want it to be stored. Your secret data remains within the chosen location at all times, whether it's at rest, in use, or in transit. This capability allows you to meet data residency requirements, which mandate that data remains within specified geographic boundaries, often due to regulatory or compliance reasons. The feature is in Preview.

For more information, see Data residency and regional secrets.

You can attach tags to secrets to conditionally grant or deny access to Secret Manager resources. For example, you can conditionally grant Identity and Access Management (IAM) roles based on whether a secret has a specific tag. This feature is in Preview. For more information, see Create and manage tags.

Secret Manager add-on for Google Kubernetes Engine (GKE) is now generally available (GA). With the add-on, you can access the secrets stored in Secret Manager as volumes mounted in Kubernetes Pods. You can install the Secret Manager add-on on both Standard clusters and Autopilot clusters. The Secret Manager add-on is a Google managed and officially supported version of the open source Kubernetes Secrets Store CSI driver.

For more information, see Use Secret Manager add-on with Google Kubernetes Engine.

Delayed destruction of secret versions is now generally available (GA). You can set up a duration for delayed destruction at the time of creating or updating a secret. When a destruction delay duration is configured for a secret, destroying a version of that secret will disable the version and prevent its use. However, it won't be immediately destroyed. Instead, it will remain scheduled for destruction for the specified delay duration. After that duration expires, the version will be permanently destroyed. Secret Manager administrators can restore a secret version that is scheduled for destruction by either enabling or disabling it during the delay period.