GKE Adds Confidential Nodes With Intel TDX Support

Kubernetes security usually focuses on protecting workloads from each other, controlling network traffic, restricting identities, and securing the cluster control plane.

But there is another security problem that becomes important when workloads process highly sensitive information:

What happens to data while it is being processed in memory?

Encryption at rest protects data stored on disks.

Encryption in transit protects data moving across networks.

Neither directly protects data while a workload is actively using it in memory.

Confidential Computing addresses that gap.

Google Kubernetes Engine now supports Confidential GKE Nodes with Intel Trust Domain Extensions (TDX) as a generally available capability on supported machine types, including the c4-standard-* family. This allows Kubernetes workloads to run on nodes designed to protect data in use through hardware-assisted memory encryption.

The resulting security model looks like:

Data at Rest
     |
     v
Encrypted Storage

Data in Transit
     |
     v
Encrypted Network

Data in Use
     |
     v
Confidential Computing
     |
     v
Intel TDX

This is especially relevant for regulated applications, sensitive analytics, multi-tenant platforms, and AI workloads that process confidential information.

What Is Confidential Computing?

Confidential Computing protects data while it is being processed.

Traditional cloud security can be simplified into three states:

At Rest
   |
   +--> Disk / Object Storage
   |
   v
In Transit
   |
   +--> Network
   |
   v
In Use
   |
   +--> RAM

The first two states have mature encryption mechanisms.

The difficult part is the third.

When an application processes a customer record, the data must eventually exist in memory.

Confidential Computing uses hardware-supported isolation and memory encryption to reduce exposure of that workload data while it is being processed.

Intel TDX creates an isolated Trust Domain for a virtual machine and uses hardware mechanisms to protect memory from unauthorized access by software outside that protected environment.

What Intel TDX Adds

A conventional virtual machine can be represented as:

Physical Host
     |
     v
Hypervisor
     |
     +--> VM
            |
            +--> Guest OS
                  |
                  +--> Application

With Intel TDX, the VM runs inside a protected trust domain:

Physical Host
     |
     v
Hypervisor
     |
     v
TDX Trust Domain
     |
     +--> Guest OS
            |
            +--> Application
                  |
                  +--> Sensitive Data

The purpose is to strengthen protection against unauthorized access to the workload's memory from outside the trust domain.

For Kubernetes, this protection is exposed through Confidential GKE Nodes.

Confidential GKE Nodes

GKE provides Confidential GKE Nodes as a way to run Kubernetes workloads on confidential-computing-enabled infrastructure.

The feature can be configured at different levels:

Cluster level
     |
     +--> Entire cluster

Node-pool level
     |
     +--> Selected node pools

Workload level
     |
     +--> Selected workloads

GKE supports AMD SEV, AMD SEV-SNP, and Intel TDX as Confidential Computing technologies, with supported configuration depending on the cluster mode, node configuration, and GKE version.

This flexibility matters because not every application needs confidential computing.

Why Workload-Level Selection Is Useful

Imagine a cluster running:

Public API
Internal Dashboard
Payment Service
Healthcare Processing
AI Inference
Background Jobs

Only two workloads may handle highly sensitive information.

It may therefore be unnecessary to make every node confidential.

A more targeted architecture can look like:

GKE Cluster
 |
 +--> Standard Node Pool
 |      |
 |      +--> Public API
 |      +--> Internal Dashboard
 |
 +--> Confidential Node Pool
        |
        +--> Payment Service
        +--> Sensitive AI Workload

GKE also supports workload-level configuration using ComputeClasses, allowing a workload to request confidential nodes without requiring every workload in the cluster to use them.

This can make adoption more practical.

Why Data in Use Matters

Consider a healthcare application.

A patient's information may be:

Database
   |
   v
Encrypted at Rest
   |
   v
Application
   |
   v
Memory

When the application reads the record, the plaintext or decrypted representation exists in memory.

The application needs that data to perform its work.

The goal of Confidential Computing is not to magically eliminate the plaintext representation.

Instead, it protects the execution environment and memory from certain classes of access outside the protected workload boundary.

This can be valuable when the threat model includes infrastructure-level access.

Confidential Computing and Kubernetes

Kubernetes introduces another abstraction layer.

A simplified model is:

Kubernetes
   |
   v
Node
   |
   v
Container Runtime
   |
   v
Container
   |
   v
Application

With Confidential GKE Nodes:

Kubernetes
   |
   v
Confidential Node
   |
   v
Protected VM Environment
   |
   v
Guest OS
   |
   v
Container
   |
   v
Application

The application can continue using familiar container and Kubernetes concepts while the underlying node provides stronger protection for data in use.

This Does Not Replace Kubernetes Security

Confidential nodes are not a replacement for normal Kubernetes security.

You still need:

RBAC
Network Policies
Service Accounts
Pod Security
Secrets Management
Image Security
Admission Controls
Resource Limits
Audit Logging

Confidential Computing addresses a different layer.

A useful security model is:

Identity
   |
   v
Authorization
   |
   v
Network Isolation
   |
   v
Container Isolation
   |
   v
Confidential Computing
   |
   v
Protected Memory

Each control solves a different problem.

Confidential Computing Is About the Threat Model

The technology becomes useful when you need protection against threats involving the infrastructure or execution environment.

For example:

Sensitive Workload
      |
      v
Cloud Infrastructure
      |
      v
Protected Execution Environment

The question is not whether cloud infrastructure is inherently untrusted.

The question is:

Which components should be allowed to inspect workload memory?

Confidential Computing reduces the set of entities that can directly access protected workload memory.

That can be valuable for organizations with strict security requirements.

Remote Attestation

Encryption is only part of the Confidential Computing story.

Another important capability is attestation.

Attestation allows a workload or an external service to verify information about the protected execution environment.

Conceptually:

Workload
   |
   v
Attestation Request
   |
   v
Hardware-backed Evidence
   |
   v
Verification
   |
   v
Trust Decision

The application can use the result to determine whether it is running in an expected confidential environment.

GKE supports access to attestation information, and Intel TDX workloads can use the hardware-based TDX module for remote attestation.

This creates an important security pattern:

Verify Environment
       |
       v
Release Sensitive Secret
       |
       v
Run Sensitive Workload

Instead of distributing a secret to any ordinary VM, a system can require evidence that the workload is running in an approved confidential environment before releasing sensitive material.

Attestation and Secret Management

Consider a service that needs access to a highly sensitive encryption key.

A weak architecture might be:

VM Starts
   |
   v
Get Secret
   |
   v
Application

A stronger architecture can be:

Workload Starts
      |
      v
Attestation
      |
      v
Environment Verified
      |
      v
Secret Released
      |
      v
Application

The exact implementation depends on the secret-management system and security requirements.

The important principle is that environment identity can become part of the authorization decision.

Confidential Nodes and AI Workloads

AI workloads are an interesting use case because models frequently process sensitive information.

Consider an enterprise AI application:

User
 |
 v
AI Application
 |
 +--> Customer Data
 +--> Financial Data
 +--> Internal Documents
 +--> Proprietary Model
 |
 v
GPU / CPU Processing

The model may process confidential information in memory during inference.

A confidential-computing architecture can add protection around the infrastructure processing that data.

This can be useful for:

Private AI inference
Sensitive analytics
Regulated workloads
Confidential RAG
Enterprise model serving
Multi-party data processing

However, Confidential Computing does not automatically make an AI application private.

Application-level controls remain essential.

AI Does Not Remove the Need for Application Security

Suppose an AI service has access to customer records.

Confidential nodes can help protect workload memory from certain infrastructure-level threats.

They do not prevent the application from accidentally returning:

Customer A's data

to:

Customer B

That is an authorization problem.

Similarly, if a prompt injection causes an agent to expose information, Confidential Computing does not prevent it.

The architecture still needs:

Identity
Authorization
Data filtering
Tool restrictions
Network controls
Prompt-injection defenses
Audit logging

Confidential Computing should therefore be viewed as one layer in the security architecture.

Multi-Tenant Applications

Confidential nodes can also be useful when multiple customers share infrastructure.

Consider:

Tenant A
Tenant B
Tenant C
   |
   v
Shared GKE Platform

Traditional isolation mechanisms protect workloads from each other.

Confidential computing adds another layer around the memory used by the workload.

This can be particularly relevant for SaaS providers that need to make stronger security assurances to customers.

But tenant isolation still requires proper:

Network isolation
Identity isolation
Storage isolation
Application authorization
Secret isolation
Logging isolation

Confidential memory protection does not replace those controls.

Performance Considerations

Confidential computing can introduce overhead.

Teams should benchmark:

CPU throughput
Memory bandwidth
Network latency
Application latency
Startup time
Workload density

The impact depends on the workload and the hardware configuration.

A CPU-heavy application may behave differently from:

Memory-intensive analytics
High-throughput database
AI inference
Large-scale batch processing

Do not assume that a confidential configuration has identical performance characteristics to an equivalent standard node.

Measure it.

Machine-Type Compatibility Matters

Confidential Computing is hardware-dependent.

The October 2026 GKE release made c4-standard-* machine types, up to 192 vCPUs, generally available for Confidential GKE Nodes using Intel TDX.

That does not mean every GKE machine type can run TDX workloads.

Before deployment, verify:

Machine type
CPU generation
GKE version
Region
Zone
Operating system
Autopilot / Standard mode

Availability and supported configurations can vary.

GKE Version Requirements

Confidential Computing features also depend on GKE versions.

For example, Intel TDX support has minimum GKE versions that vary according to the node operating system and configuration. Workload-level Confidential GKE Nodes also require a sufficiently recent GKE version.

This creates an important operational requirement:

Treat the GKE version as part of the security architecture.

Before enabling confidential workloads, verify the cluster version against the feature requirements rather than assuming the current cluster is compatible.

Scheduling Confidential Workloads

Kubernetes scheduling needs to ensure that a workload lands on the intended node type.

For example, a workload can use node affinity to target confidential nodes.

A simplified manifest can look like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: confidential-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: confidential-api
  template:
    metadata:
      labels:
        app: confidential-api
    spec:
      containers:
        - name: api
          image: example/confidential-api:1.0
          resources:
            requests:
              cpu: "1"
              memory: "2Gi"
      nodeSelector:
        cloud.google.com/gke-confidential-nodes-instance-type: TDX

The exact deployment strategy should follow the supported GKE configuration for the selected cluster mode and version.

The important concept is that scheduling becomes part of the security requirement.

A workload that requires confidential computing must not silently fall back to an ordinary node.

Fail-Closed Versus Fail-Open Behavior

This deserves explicit attention.

Suppose a confidential workload cannot obtain a confidential node.

What should happen?

A secure design generally should not silently move the workload to a standard node.

The desired behavior is:

Confidential node unavailable
          |
          v
Workload remains unscheduled

rather than:

Confidential node unavailable
          |
          v
Use ordinary node
          |
          v
Security requirement violated

Workload placement policies should therefore be designed so that the confidentiality requirement is enforced by the scheduler and deployment configuration.

Storage Is a Separate Concern

Protecting memory does not automatically protect every piece of data used by the workload.

For example:

Database
   |
   v
Network
   |
   v
Confidential Node
   |
   v
Memory

The database still needs encryption.

The network still needs appropriate protection.

Persistent disks still need appropriate controls.

GKE also provides a confidential mode for supported Hyperdisk Balanced boot-disk configurations, adding another hardware-backed protection layer for storage.

The overall security model should therefore protect data across all relevant states.

Logging Can Break the Security Model

Imagine an application processes:

Patient information

inside a confidential workload.

The application then writes:

Patient name
Medical details

into ordinary application logs.

The memory protection is still working.

But the data has now moved into a different security domain.

This is why teams need to classify:

Application logs
Metrics
Traces
Crash dumps
Debug output
Temporary files

Confidential Computing protects a specific execution boundary.

Data leaving that boundary still needs appropriate controls.

Common Mistakes

Treating Confidential Nodes as a complete security solution

They protect a specific part of the infrastructure threat model.

Forgetting authorization

Confidential memory does not prevent an application from returning data to the wrong user.

Ignoring attestation

For high-assurance workloads, proving the environment is running as expected can be as important as encrypting memory.

Assuming every machine supports TDX

Confidential Computing requires compatible hardware and supported locations.

Allowing fallback to ordinary nodes

A workload with a confidentiality requirement should not silently run without the required protection.

Ignoring logs

Sensitive data can leave the confidential environment through application telemetry.

Skipping performance testing

Security features can affect workload performance and density.

Giving every workload confidential nodes

Use the capability where the threat model justifies it.

Advantages and Disadvantages

Advantages

Protection for data in use: Confidential Computing adds hardware-assisted protection around workload memory.

Hardware-backed isolation: Intel TDX establishes protected trust domains for supported workloads.

Kubernetes integration: Developers can use familiar GKE workload and scheduling models.

Workload-level flexibility: Confidential nodes can be targeted to specific workloads where appropriate.

Attestation support: Applications can obtain evidence about the confidential environment.

Useful for sensitive AI: Confidential execution can strengthen the security posture of workloads processing proprietary or regulated data.

Disadvantages

Hardware constraints: Only supported machine types, versions, and locations can be used.

Potential performance overhead: Applications should be benchmarked under confidential configurations.

More operational complexity: Cluster version, node type, scheduling, attestation, and availability all become important.

Not a replacement for application security: Identity, authorization, network, and data controls remain necessary.

Potential capacity constraints: Confidential hardware availability can differ from ordinary compute capacity.

When Confidential GKE Nodes Make Sense

The technology is particularly relevant for:

Financial workloads
Healthcare systems
Government applications
Confidential analytics
Sensitive AI inference
Multi-tenant SaaS
Proprietary model processing
Regulated data processing

It may be unnecessary for:

Public websites
Non-sensitive batch jobs
Development environments
Low-risk internal services

The decision should be based on the data and threat model.

A Practical Adoption Strategy

Teams considering Confidential GKE Nodes can approach adoption incrementally:

Identify workloads that process sensitive information.
Define the threat model and determine whether data-in-use protection is required.
Verify supported GKE versions, machine types, regions, and zones.
Create a dedicated confidential node pool or workload-level ComputeClass where appropriate.
Configure scheduling so sensitive workloads cannot fall back to ordinary nodes.
Review identity, network, storage, and secret-management controls.
Implement attestation where the workload requires proof of the execution environment.
Benchmark application performance against equivalent standard nodes.
Review logs, metrics, traces, and crash artifacts for accidental data exposure.
Monitor node availability and operational behavior in production.

This makes Confidential Computing part of an overall security architecture rather than simply switching on a feature.

What Developers Should Take Away

Confidential GKE Nodes with Intel TDX solve a specific but increasingly important problem:

Protecting sensitive workload data while it is being processed.

The traditional encryption model is:

At Rest
    +
In Transit

Confidential Computing extends it toward:

At Rest
    +
In Transit
    +
In Use

For Kubernetes workloads processing regulated information, proprietary data, or sensitive AI workloads, this additional protection can significantly strengthen the infrastructure security model.

But it should not be confused with application-level security.

A secure system still needs:

Strong identity
Least privilege
Network isolation
Encrypted storage
Secure secrets
Authorization
Auditability
Attestation

The best architecture combines these controls rather than expecting one technology to solve every security problem.

Summary

GKE's generally available Intel TDX support brings hardware-backed confidential computing into Kubernetes workloads on supported infrastructure.

The main benefit is protection for data in use through a hardware-isolated execution environment.

For organizations running sensitive workloads, the architecture can look like:

Sensitive Data
      |
      v
Encrypted Storage
      |
      v
Encrypted Network
      |
      v
Confidential GKE Node
      |
      v
Intel TDX
      |
      v
Protected Workload Memory

The feature is especially useful when infrastructure-level threats are part of the security model.

For developers, the important lesson is to treat Confidential Computing as another security layer. It strengthens the execution environment, while application authorization, network controls, secrets management, logging, and data governance continue to protect the workload at higher levels.

When those layers are designed together, confidential Kubernetes workloads can provide a substantially stronger foundation for sensitive enterprise and AI applications.