Professional Cloud Developer
Prepare and test your skills
Prepare and test your skills
A sequence diagram showing how an external application obtains an OIDC token from its identity provider, exchanges it via Google Security Token Service for a short-lived federated token, and impersonates a Google Cloud service account to access resources without long-lived keys.
Secret Management is the process of safely storing and handling sensitive data like passwords, API keys, and certificates. In the cloud, it is essential to protect these credentials from being exposed in application code or configuration files. Using a centralized system allows applications to retrieve the data they need securely without storing the secrets themselves.
Secret Manager is a secure storage system for sensitive configuration data. It uses Version Control, which lets you track different versions of a secret and roll back to a previous version if needed. You can also define Granular Access Policies using IAM to control exactly which users or services can view or modify a secret, ensuring only authorized access.
Automated Rotation is a key security practice where secrets are automatically updated on a schedule. Configuring Rotation Schedules in Secret Manager minimizes the risk if a credential is stolen, because its useful lifespan is shortened. This process happens without manual intervention, ensuring applications always use current keys and reducing operational overhead.
Other services work with Secret Manager to provide comprehensive security. Cloud Key Management Service (KMS) lets you create and manage your own encryption keys. Workload Identity Federation allows external applications to access Google Cloud resources without needing permanent secret keys. Customer-Managed CAs can be used to verify database server identities for secure connections.
Managing access requires the right permissions. IAM Roles, like Cloud SQL Admin or Security Auditor, grant specific permissions to users or services to perform their jobs without unnecessary access. Service Agents are automated identities that allow Google Cloud services to securely interact with each other on your behalf, following the principle of least privilege.
Workload Identity Federation eliminates the need for long-lived service account keys, which are hard to manage and pose a security risk if leaked. It establishes a trust relationship between Google Cloud and an external identity provider (like AWS, Azure, or GitHub). Applications outside Google Cloud can then use short-lived credentials from their provider to securely access Google Cloud resources.
The process works through a secure token exchange. An application first gets an identity token (like an OIDC token) from its external provider. It sends this token to Google's Security Token Service, which verifies it and issues a short-lived federated token. This token allows the application to impersonate a Google Cloud service account, providing keyless, temporary access. This removes the need to store secret key files externally.
You manage these external identities using workload identity pools and providers. A pool is a container for external identities, and a provider defines the connection to a specific external identity source (like a GitHub organization). It is a best practice to manage these pools in a dedicated project to keep security settings centralized and consistent.
To prevent identity spoofing, you configure attribute mappings and attribute conditions. Attribute mapping links a claim from the external token (like a username) to a Google identity. You should use immutable attributes that cannot be reused. Attribute conditions add strict rules, such as allowing access only from a specific AWS role or GitHub repository, to tightly control which external workloads can get tokens.
When setting this up, follow the principle of least privilege. Create a dedicated service account for each application and grant it only the permissions it needs. Limit which external identities can impersonate that service account. This containment ensures that if one external application is compromised, it cannot access all your cloud resources.
While Google encrypts data by default, Cloud Key Management Service (KMS) allows you to use Customer-Managed Encryption Keys (CMEK). This gives you control over the key's lifecycle, its geographic location, and its rotation schedule. Using CMEK is often required to meet specific compliance standards and provides a stronger cryptographic boundary for your sensitive data.
To use a CMEK, you must grant the Cloud KMS CryptoKey Encrypter/Decrypter IAM role to the service account used by your cloud service (like Cloud SQL or a storage bucket). Without this permission, the service cannot use your key to encrypt or decrypt data, which will cause the application or deployment to fail.
Managing CMEKs involves several critical actions for security. Key Rotation updates the key version regularly to limit how much data is protected by a single version. You can Disable Keys to temporarily block access to encrypted data. Key Destruction permanently destroys a key, making all data encrypted with it unrecoverable, which is a final security measure.
Envelope Encryption is a pattern used to efficiently protect large datasets. A powerful Key Encryption Key (KEK), which you manage in Cloud KMS, is used to encrypt a simpler "data encryption key." The data itself is then encrypted with that data key. This means even if the data key is exposed, it remains useless without the master KEK stored securely in KMS.
For many services, the Key Ring and CMEK must be located in the same Google Cloud region as the resource they protect (like a Firestore database). You must ensure this regional alignment for the service to function. It is also important to monitor Cloud KMS audit logs to track every time a key is used or modified, helping maintain security and compliance.
StudyCerts
StudyCerts