This article is based on reporting originally published by Dark Reading in May 2018, covering announcements made at InteropITX and subsequent Google Cloud blog posts.
The Security Challenge Driving These Announcements
Data visibility is a persistent concern for organizations migrating workloads to the cloud. As Sam Ramji, then Vice President of Google Cloud product development, argued in his keynote at InteropITX, the explosive growth of connected software has created both enormous opportunity and significant security risk. Businesses across every industry are under pressure to ship software faster, yet they must do so with fewer experienced developers and security engineers than the work demands.
Ramji framed the challenge plainly: any system that cannot connect and scale easily will become a liability. The corollary is that any system that cannot be secured at scale will become a liability even faster. Against that backdrop, Google announced two distinct but complementary security initiatives targeting container workloads and cloud-native DevOps pipelines.
Asylo: An Open-Source Framework for Trusted Execution Environments
The first announcement was Asylo, an open-source framework and SDK designed to make Trusted Execution Environments (TEEs) accessible to a broader range of developers.
What Are Trusted Execution Environments?
A TEE is an isolated, hardware-backed execution context — sometimes called an enclave — that protects code and data from threats targeting layers below the application itself: the operating system, hypervisor, firmware, device drivers, and other infrastructure components. Code running inside an enclave is shielded even from privileged software on the host. In practice, this means:
- Sensitive data is encrypted at runtime, not just at rest or in transit.
- The integrity of the running code can be verified, providing assurance that the enclave has not been tampered with.
- Malicious insiders or compromised infrastructure components are prevented from reading enclave contents.
Ramji summarized the goal: “The actual running code in the cloud — I want it to be completely opaque to the provider. I want it to be encrypted in runtime.”
What Problem Did Asylo Solve?
Before Asylo, using a TEE required specialized hardware knowledge, purpose-built toolchains, and significant code changes. TEE implementations were typically tied to specific hardware environments, limiting portability across on-premises and cloud deployments. This meant TEE adoption was largely confined to teams with dedicated security engineering resources.
Asylo lowered that barrier in two meaningful ways:
- No hardware lock-in. Asylo abstracts away the underlying TEE implementation, so applications are not tied to a specific processor or cloud provider’s enclave technology.
- No source code rewrite required. Developers can run existing containerized applications in secure mode without restructuring their codebase or acquiring deep expertise in enclave internals.
Google distributed Asylo as a Docker image through the Google Container Registry, giving teams the dependencies they need to run TEE-protected containers anywhere Docker is supported.
Why This Matters for DevOps Teams
Container-based workloads have a broad attack surface. Even if your application code is sound, a compromised host OS or hypervisor can expose secrets. TEEs push the trust boundary down to hardware, which is particularly valuable for workloads handling cryptographic keys, personally identifiable information, financial data, or regulated health records. Asylo aimed to make that protection available to teams without a dedicated security engineering function.
Cloud Security Command Center: Unified Visibility for Container Security
The second announcement — Cloud Security Command Center (Cloud SCC) — addressed a different but related problem: observability. As Ramji put it, “The medium is abundant. What’s scarce is observability.”
Cloud SCC is a centralized security management dashboard within Google Cloud Platform. It aggregates security data from across an organization’s GCP resources, giving administrators a single pane of glass for security posture assessment.
Container Security Integrations at Launch
At the time of the InteropITX keynote, Ramji noted that five container security vendors had integrated their tools with Cloud SCC to surface security data for workloads running on Google Kubernetes Engine (GKE). These integrations enabled administrators to:
- View consolidated security alerts for GKE clusters in a single interface.
- Inventory and organize cluster assets across projects and business units.
- Establish a baseline of normal cluster behavior and detect anomalous activity using defined rules.
Why Observability Is the Core Container Security Problem
Kubernetes environments are inherently dynamic. Pods are created and destroyed frequently, workloads scale horizontally, and network policies change rapidly. Without centralized visibility, detecting a compromised container, a misconfigured RBAC policy, or unexpected outbound network traffic requires correlating logs from multiple disconnected sources. Cloud SCC attempted to collapse that complexity into a structured, queryable view of an organization’s security state.
Effective container security generally requires two things that Cloud SCC was designed to support: a defined baseline of expected behavior, and real-time alerting when observed activity deviates from that baseline. Neither is achievable without comprehensive, centralized data collection.
The Broader Takeaway for DevOps and Platform Engineers
These two announcements reflected a consistent theme in Google Cloud’s 2018 security posture: security controls should be built into the platform and made accessible to developers who are not security specialists, rather than bolted on by dedicated teams after the fact.
- Shift left on trust boundaries. Asylo pushed security guarantees down to the hardware level without requiring developers to reason about enclave internals.
- Centralize observability. Cloud SCC aggregated signals from heterogeneous security tools into a single operational view, reducing the risk of alerts being missed across siloed dashboards.
- Reduce dependency on scarce expertise. Both tools were explicitly designed to be usable without deep security specialization — a practical response to the documented shortage of security-trained engineers in the industry.
For teams running containerized workloads on GCP, evaluating both Asylo and Cloud SCC in the context of your threat model and compliance requirements remains worthwhile. The tools have evolved significantly since 2018; consult current Google Cloud documentation for up-to-date capabilities, supported TEE backends, and pricing.
Original reporting: Dark Reading, May 2018. Keynote: Sam Ramji at InteropITX, 2018.