Assured Workloads is GCP’s way of letting you run sensitive workloads, but the most surprising thing is how it doesn’t actually enforce anything itself; instead, it orchestrates and monitors other GCP services to ensure compliance.
Let’s see it in action. Imagine you need to run workloads that must adhere to US government data sovereignty and access control requirements. You’d create an Assured Workloads folder in your GCP organization.
# Example Assured Workloads Configuration (Conceptual)
apiVersion: assuredworkloads.googleapis.com/v1
kind: Workload
metadata:
name: us-compliance-workload
folder: folders/123456789012
spec:
displayName: "US Compliance Workload"
complianceRegime: "us-government-compliance"
complianceStatus:
# This is updated by GCP based on detected violations
activeAlerts: []
resources:
# Projects within this workload are automatically configured
projects:
- projects/my-secure-project-1
- projects/my-secure-project-2
complianceSettings:
dataLocation:
restriction: "REGIONAL_DATA_LOCATION"
location: "us-central1"
accessControl:
restrictedBetaFeatures:
- "all" # Example: disallows all beta features
# Other settings like IAM, logging, monitoring can be configured here
When you create this Workload resource, Assured Workloads doesn’t magically make your projects compliant. Instead, it uses a suite of other GCP services:
- Organization Policy Service: It automatically applies specific Organization Policies to the projects within your Assured Workload. For data sovereignty, this might mean enforcing a
constraints/gcp.resourceLocationspolicy to restrict resources tous-central1. - IAM Conditions: It can enforce IAM policies with conditions to restrict who can access the data or resources, ensuring only authorized personnel can operate within the defined compliance boundaries.
- Security Command Center (SCC): Assured Workloads integrates with SCC to continuously scan your projects for compliance violations. If a resource is deployed outside the allowed region, or if a restricted feature is enabled, SCC will flag it.
- Logging and Monitoring: It ensures that audit logs are enabled and retained for the required duration, and that monitoring is in place to detect and alert on suspicious activity.
The core problem Assured Workloads solves is the complexity of manually configuring and continuously monitoring all these disparate GCP services to meet stringent regulatory demands. It provides a declarative way to define your compliance requirements, and then it automates the underlying configuration and enforcement.
The levers you control are primarily within the complianceSettings block of the Workload resource. You define the complianceRegime (e.g., us-government-compliance, iso-27001, fedramp-moderate). Based on this regime, Assured Workloads suggests and often automatically applies default policies. You can then customize dataLocation to restrict where data resides, accessControl to manage feature access, and more granular settings for logging, encryption, and network controls.
What most people miss is that Assured Workloads acts as a controller for these underlying services. It’s not a new enforcement engine. When you set a dataLocation restriction, Assured Workloads isn’t blocking resource creation itself; it’s instructing the Organization Policy Service to apply a constraint that does block it. The compliance status shown in the Assured Workloads console is a reflection of the aggregated findings from SCC and the state of the applied Organization Policies.
The next step after setting up your compliance regime is understanding how to integrate your CI/CD pipelines to deploy resources that will pass Assured Workloads checks from the outset.