Designing for security

Identity and Access Management (IAM)

Identity and Access Management (IAM) controls who can do what with Google Cloud resources. It works by defining who (an identity like a user or service account), what (a role containing specific permissions), and on which resource (like a Compute Engine instance or a Cloud Storage bucket). A policy binds these three parts together. This system allows for the principle of least privilege, where an identity gets only the permissions it absolutely needs to perform its job, and nothing more.

Resource hierarchy (organizations, folders, and projects)

Google Cloud resources are organized in a hierarchy: Organization > Folders > Projects > Resources. This structure is important for security because IAM policies and other security controls can be inherited downward. For example, an IAM role granted at the folder level applies to all projects and resources inside that folder. This makes it efficient to manage access and policy for large groups of related resources. The hierarchy also establishes clear ownership and administrative boundaries.

Data security (key management, encryption, secret management)

Protecting data involves multiple layers. Data is encrypted by default when at rest and in transit. For more control, you can manage your own encryption keys using services like Cloud Key Management Service (Cloud KMS). Secrets, such as database passwords or API keys, should never be hard-coded in applications; they are securely stored and accessed using a service like Secret Manager. The relationship is that applications request secrets from Secret Manager, and those secrets might be encrypted with keys from Cloud KMS, creating a secure chain of custody for sensitive information.

Separation of duties

Separation of duties is a security principle that prevents any single person from having too much power. In GCP, this is enforced by assigning different IAM roles to different people or teams. For example, the person who develops an application might have permissions to deploy code but not to manage the encryption keys it uses. The person who manages the keys would not have permission to modify the application code. This separation reduces the risk of fraud or error by requiring collaboration for critical actions.

Security controls (e.g., auditing, VPC Service Controls, context aware access, organization policy, and hierarchical firewall policy)

This area involves tools that enforce security boundaries and monitor activity. Auditing logs who did what and when, which is essential for detecting issues and proving compliance. VPC Service Controls create a security perimeter around specific GCP services and resources to prevent data exfiltration. Organization Policies are rules that restrict how resources can be configured across the entire hierarchy. The Hierarchical Firewall Policy allows you to define firewall rules at the organization or folder level, which then apply to all VPC networks beneath it, providing centralized network security management.

Managing customer-managed encryption keys with Cloud Key Management Service (Cloud KMS)

Cloud Key Management Service (Cloud KMS) lets you create, manage, and use your own encryption keys, called customer-managed keys, for Google Cloud services. When you enable a customer-managed key for a resource like a Cloud Storage bucket, all data in that bucket is encrypted with your key instead of Google's default keys. You control the key lifecycle, including rotation and destruction. This is crucial for meeting compliance requirements where you must demonstrate control over your encryption keys.

Secure remote access (e.g., Identity-Aware Proxy, service account impersonation, Chrome Enterprise Premium, and Workload Identity Federation)

These tools provide secure ways for users and workloads to access resources without relying on traditional VPNs or managing SSH keys. Identity-Aware Proxy (IAP) controls access to applications and VMs based on user identity and context, not just network location. Workload Identity Federation allows applications running outside of GCP (like on-premises or in another cloud) to securely access GCP resources using their own native identity system. This eliminates the need to store and manage GCP service account keys outside of Google's control.

Securing software supply chain

Securing the software supply chain means protecting the entire process of developing, building, and deploying software. This includes scanning source code for vulnerabilities, verifying that software artifacts (like container images) come from trusted sources and haven't been tampered with, and ensuring only approved components are used. In GCP, services like Artifact Registry and Binary Authorization help by providing a trusted repository for artifacts and enforcing policies that block deployment unless the artifacts meet specific security standards.

Securing AI (e.g., Model Armor, Sensitive Data Protection, and secure model deployment)

Securing AI workloads involves protecting the data used to train models, the models themselves, and the deployed endpoints. Sensitive Data Protection can find and classify sensitive information in training datasets. Model Armor helps protect AI models from extraction or inference attacks after they are deployed. Secure model deployment involves controlling access to the model's serving endpoint using IAP or VPC Service Controls and ensuring the underlying infrastructure (like the VMs or containers running the model) is hardened and monitored.