Google Secret Manager
Summary of Secret Manager
With the help of Google Secret Manager, you can store and manage private information like certificates, API keys, usernames, and passwords, among other things.
A global resource called a secret holds a set of secret versions and metadata. Replication sites, labels, annotations, and permissions are a few examples of the metadata. The actual secret payload, such as an API key or credential, is stored in secret versions.
GCP Google Secret Manager
With Secret Manager, the following tasks are possible:
- Utilise versions to control rollback, recovery, and auditing: Versions facilitate the management of emergency rollbacks and phased rollouts. You can go back to a known-good version of a secret if it is inadvertently altered or compromised. By doing this, possible downtime and security breaches are reduced. Versioning keeps track of all past modifications to a secret, including who changed it and when. It supports you in tracking any illegal access attempts and auditing confidential data. For simpler access to secret data, you can add aliases and pin secret versions to particular workloads. Additionally, you can remove or disable any hidden versions that you no longer need.
- Encrypt your secret data while it’s in transit and at rest. By default, all secrets are encrypted using TLS while they’re in transit and AES-256 bit encryption keys when they’re at rest. Customer-Managed Encryption Keys (CMEK) are an option for individuals who need more precise control while encrypting sensitive data. To satisfy your unique needs, you can import or generate new encryption keys using CMEK.
- Use fine-grained Identity and Access Management (IAM) roles and criteria to control access to secrets: You can grant precise access to particular Secret Manager Google Secret Manager resources by utilising IAM roles and permissions. Responsibilities for rotating, auditing, administering, and gaining access to secrets can be divided up.
- Use covert replication to provide high availability and catastrophe recovery: Regardless of where your applications are located, you can guarantee high availability and disaster recovery by replicating your secrets across several regions. The following replication policies are available for selection:
- Automatic: Google selects the areas based on latency and availability. You are only billed for the one place.
- User Managed: Depending on your needs, you can choose a unique collection of areas. There is a fee for each venue.
- Rotate secrets automatically to satisfy your compliance and security needs: By rotating your secrets, you may guard against data breaches and unwanted access. Regularly changing your credentials reduces the risk that your secrets will be compromised and ensures compliance with numerous regulatory frameworks that require the periodic rotation of sensitive credentials. stale or forgotten.
- Use local secrets to enforce data residency (preview): Certain kinds of data, frequently pertaining to particular people or organisations, must be kept in a certain geographic area according to the concept of data residency. To adhere to data sovereignty laws and regulations, you might establish regional secrets and store your sensitive data in a certain location.
For storing, managing, operating, auditing, and accessing secrets used across Google Cloud services, such as GKE and Compute Engine, Google Secret Manager is a fully-managed, scalable solution. Managing the erasure and destruction of secrets is a crucial component of any strategy for managing secrets. Google is glad to report that delayed destruction of secret versions for Google Secret Manager is now generally available, giving clients access to sophisticated capabilities in this domain. This new feature contributes to making sure that confidential information cannot be mistakenly erased, either intentionally or as a result of a hostile attack.
How It Operates
Google Secret Manager consists of two primary resources: secrets and secret versions. A project-global object with a set of secret versions and information is called a secret. The real secret data, including credentials, API keys, and certificates, is kept in the secret version.
Customers have encountered the following difficulties when using Google Secret Manager to manage the lifespan of secret materials:
- An irreversible step is the destruction of a secret version. This implies that if your secret stuff is lost, there is no way to get it back.
- Absence of prompt notification in the event that any of your vital secrets are attempted to be destroyed, which lessens the likelihood that an administrator will act in a timely manner.
Two new features have been added to the delayed destruction of secrets in order to address these issues: a customizable delay length that prevents the instantaneous destruction of secret versions and a new Pub/Sub event notification that notifies you when a destroy action is attempted.
An unidentified version had the ability to switch between enabled, disabled, and destroyed states prior to the implementation of delayed destruction. Access to the hidden version is blocked when the status is disabled, which is reversible. The destroyed condition is instantaneous and irreversible by default.
A new flow called delayed destruction makes it impossible to destroy secret versions instantly. This gives added assurance that data is safe from attacks and a fallback plan in the event of an unforeseen incident.
Henceforth, upon executing a destroy action, the targeted version will undergo a soft-delete, wherein its status is changed to disabled. For N days, the secrets are kept in an archive. Administrators can set its duration by utilizing the TTL_DURATION field. An administrator has the option to restore the secret version during this archive period by turning it back on and putting it in an enabled state. The hidden version is deleted forever after the delay time ends.
Observability and Pub/Sub notification alerting
One essential component of a clearly defined security posture is observability. A new optional Pub/Sub notification called SECRET_VERSION_DESTROY_SCHEDULED has been added to alert SecOps specialists and organizational admins to any efforts to delete a secret version. When destruction is scheduled, it will alert the relevant Pub/Sub topic. This way, the on-call staff can examine the change and, if required, restore the secret version rather than letting destruction continue.
Use least privilege access in conjunction with delayed destruction
You won’t be completely protected from the destruction of secret content if you only use the delayed destruction feature. It is crucial that you let the right people access to your secrets. An administrator of the secret still has the option to remove the entire secret even with the feature activated. As a result, it is crucial that only a strictly vetted, small group of individuals be given admin access to secrets. Users should only be given restricted roles for routine lifecycle management activities on secrets, which provide them the minimal amount of access necessary to finish the task:
- Admins with complete authority over secrets, versions, and their lifecycle are granted access to the Google Secret Manager Admin role. This position would normally not be open to the public and be limited to a security administrator group.
- Allowed to devops engineers or service accounts handling lifecycle management on secret versions (add, enable, deactivate, destroy) or rotation workflows is the Secret Version Manager / Secret Version Adder. Secret property modifications are not permitted in these jobs.
Meeting the needs of the client
Responses from clients who have worked with us to develop delayed destruction have improved backup efficiency and strengthened resistance to cyberattacks.
“With Google Secret Manager, the ‘delay destruction of secret versions’ option allows us to combat disruptive attacks like ransomware or accidentally deleting important secrets with ease and effectiveness. The security and resiliency of our IT infrastructure are fundamental to our business as a financial services organization, according to Dominik Raub, chief information security officer of Crypto Finance AG, a Deutsche Börse Group firm.
Begin using Secret Manager right now
Google Secret Manager‘s delayed destruction of secret versions is now widely accessible with support for the Google Cloud console, API, gcloud, and client libraries.
