---
title: "Appendix: Google Cloud Workload Services Daemon"
framework: Private Cloud Compute Security Guide
role: article
role_heading: Article
path: private-cloud-compute/appendix_googlecloudworkloadservicesdaemon
---

# Appendix: Google Cloud Workload Services Daemon

The key-management and attestation interfaces exposed to a node’s workload container.

## Overview

Overview A node exposes its key-management and attestation operations through the Workload Services Daemon. The daemon runs inside the confidential VM alongside the workload container and acts as its security proxy: private keys stay in the Key Protection Service VM, and the daemon gathers the attestation evidence, so the container obtains Titan TPM and TDX evidence only through the daemon. The container reaches the GPUs directly, through the device nodes it needs for model execution and GPU health polling. For everything else, the container interacts with the daemon over local Unix domain sockets, and the daemon bridges those requests to internal services: For the node’s key-protection architecture, attestation evidence binding, and verification procedures, see Google Cloud Node Attestation. Appendix: Google Cloud Attestation Bundle Contents gives the wire format of the attestation bundle. Interacting with the daemon The daemon listens on two Unix domain sockets mounted inside the workload container at /run/container_launcher/: Both interfaces speak HTTP over Unix domain sockets. In the Google Cloud Research Environment, curl reaches these endpoints directly: % curl --unix-socket /run/container_launcher/kmaserver.sock http://localhost/v1/capabilities The underlying API schemas are defined as protobufs in the open source key-protection-module repository, and the endpoints exchange those messages in their JSON encoding. Key-management interface The key-management interface on kmaserver.sock manages the life cycle of KEM keys and performs decapsulation: Attestation Service The Attestation Service on teeserver.sock gathers attestation evidence from across the node’s hardware and firmware roots: The POST /v1/keys:getEndorsement response returns two endorsements, each covering a serialized KeyClaims message that sets one of two claim types: note: confidential-space key-protection-module go-tpm-tools