Attestation Strategies

Overview

QHx uses a two-phase attestation process to establish workload identity: node attestation (proving the node’s identity) followed by workload attestation (proving the process identity). This guide explains how these phases relate, when to use pre-registration versus automated registration, and how to select the right attestation strategy for your environment.

Target audience: Platform operators, security architects, and deployment teams configuring QHx identity issuance.

Attestation Fundamentals

Two-Phase Attestation Model

┌─────────────────────┐
│  Node Attestation   │  Phase 1: "What machine is this?"
│                     │
│  Establishes:       │  ┌─────────────────────────┐
│  • Node identity    │  │ Trusted authorities:    │
│  • Agent SPIFFE ID  │  │ • Cloud provider APIs   │
│  • Node selectors   │  │ • TPM measurements      │
│                     │  │ • X.509 certificates    │
└─────────────────────┘  │ • Join tokens           │
           ↓              └─────────────────────────┘
┌─────────────────────┐
│ Workload Attestation│  Phase 2: "What process is this?"
│                     │
│  Establishes:       │  ┌─────────────────────────┐
│  • Process identity │  │ Local authorities:      │
│  • SPIFFE ID        │  │ • Kernel (PID, UID/GID) │
│  • Workload SVID    │  │ • Kubelet API           │
│                     │  │ • Container runtime     │
└─────────────────────┘  └─────────────────────────┘

Key principle: Node attestation establishes trust in the platform; workload attestation builds on that trust to identify specific processes.

The Parent-Child Relationship

Every workload identity has a parent identity (the node it runs on):

# Node registration entry
spiffeID: spiffe://qhx.dev/agent/k8s/node-1
selectors:
  - k8s_psat:cluster:production
  - k8s_psat:agent_node_name:node-1

---
# Workload registration entry (child of node)
spiffeID: spiffe://qhx.dev/ns/production/sa/api
parentID: spiffe://qhx.dev/agent/k8s/node-1  # ← Links to node
selectors:
  - k8s:ns:production
  - k8s:sa:api

Why parent-child? Ensures workload can only run on authorized nodes. If node is compromised, only workloads with that parent are affected.

Node Attestation Strategies

Strategy 1: TPM-Based Attestation

When to use:

Hardware root of trust required
Defense/classified workloads
Physical or bare-metal servers
Measured boot required

How it works:

Node boots with UEFI Secure Boot enabled
Boot measurements stored in TPM PCR registers
PKI Agent reads TPM measurements
PKI Server validates measurements against policy
Agent receives node identity

Configuration:

# PKI Agent (node)
apiVersion: v1
kind: ConfigMap
metadata:
  name: pki-agent-config
  namespace: qhx-system
data:
  agent.conf: |
    agent {
      data_dir = "/var/lib/qhx/agent"
      trust_domain = "qhx.dev"
    }

    plugins {
      NodeAttestor "tpm_devid" {
        plugin_data {
          devid_cert_path = "/opt/qhx/devid-cert.pem"
          devid_priv_path = "/opt/qhx/devid-key.pem"
        }
      }
    }

PKI Server configuration:

# PKI Server
data:
  server.conf: |
    server {
      trust_domain = "qhx.dev"
    }

    plugins {
      NodeAttestor "tpm_devid" {
        plugin_data {
          ca_path = "/opt/qhx/tpm-ca-bundle.pem"
          devid_policy {
            allowed_pcr_banks = ["SHA256"]
            pcr_values {
              # Boot integrity
              "0" = ["<expected-hash>"]   # BIOS/firmware
              "7" = ["<expected-hash>"]   # Secure Boot state
              "14" = ["<expected-hash>"]  # Boot order
            }
          }
        }
      }
    }

Node selectors generated:

tpm:pub_hash:<hash-of-public-key>
tpm:pcr:<bank>:<index>:<value>

Advantages:

Hardware-rooted identity
Detects boot-time tampering
Prevents agent impersonation
Measured boot integrity

Disadvantages:

Requires TPM 2.0 hardware
PCR values change on firmware updates
Complex initial provisioning
Not available in all cloud environments

Operational notes:

Maintain PCR value database
Update policy after BIOS updates
Test boot integrity monitoring
Document TPM provisioning process

Strategy 2: Kubernetes PSAT (Projected Service Account Token)

When to use:

Kubernetes-native deployments
Cloud environments (EKS, AKS, GKE)
No TPM hardware available
Rapid deployment required

How it works:

PKI Agent pod has service account token mounted
Token is cryptographically signed by Kubernetes
PKI Server validates token via Kubernetes API
Token contains node name, namespace, service account
Agent receives node identity

Configuration:

# PKI Agent DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: qhx-pki-agent
  namespace: qhx-system
spec:
  template:
    spec:
      serviceAccountName: qhx-pki-agent
      containers:
      - name: agent
        image: qhx/pki-agent:v0.6.1
        volumeMounts:
        - name: agent-config
          mountPath: /etc/qhx
        - name: agent-socket
          mountPath: /run/pki/sockets
      volumes:
      - name: agent-config
        configMap:
          name: pki-agent-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: pki-agent-config
data:
  agent.conf: |
    plugins {
      NodeAttestor "k8s_psat" {
        plugin_data {
          cluster = "production"
          token_path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
        }
      }
    }

PKI Server configuration:

data:
  server.conf: |
    plugins {
      NodeAttestor "k8s_psat" {
        plugin_data {
          clusters = {
            "production" = {
              service_account_allow_list = ["qhx-system:qhx-pki-agent"]
              audience = ["qhx-server"]
              kube_config_file = "/etc/kubernetes/kubeconfig"
            }
          }
        }
      }
    }

Node selectors generated:

k8s_psat:cluster:production
k8s_psat:agent_ns:qhx-system
k8s_psat:agent_sa:qhx-pki-agent
k8s_psat:agent_node_name:node-1
k8s_psat:agent_node_uid:abc-def-123

Advantages:

Native Kubernetes integration
No hardware requirements
Automatic node discovery
Works in all K8s environments

Disadvantages:

Depends on Kubernetes API availability
Token theft possible (mitigated by short expiry)
No hardware root of trust
Cluster admin can forge tokens

Operational notes:

Rotate service account keys regularly
Monitor Kubernetes API availability
Restrict service account RBAC
Enable Kubernetes audit logging

Strategy 3: Cloud Provider IID (AWS, Azure, GCP)

When to use:

Cloud-native deployments
Need cloud metadata integration
Auto-scaling environments
Trust cloud provider platform

AWS Example:

# PKI Agent
plugins {
  NodeAttestor "aws_iid" {
    plugin_data {}
  }
}

PKI Server:

plugins {
  NodeAttestor "aws_iid" {
    plugin_data {
      access_key_id = "<AWS-ACCESS-KEY>"
      secret_access_key = "<AWS-SECRET-KEY>"
      skip_block_device = false
    }
  }

  NodeResolver "aws_iid" {
    plugin_data {
      access_key_id = "<AWS-ACCESS-KEY>"
      secret_access_key = "<AWS-SECRET-KEY>"
    }
  }
}

Node selectors generated:

aws:account:123456789012
aws:region:us-east-1
aws:instance:i-abc123def456
aws:ami:ami-xyz789
aws:sg:sg-abc123  (security group)
aws:tag:environment:production
aws:iam:role:my-instance-role

Advantages:

Rich metadata (tags, IAM role, VPC)
Automatic in cloud environments
No additional infrastructure
Well-tested and documented

Disadvantages:

Cloud provider lock-in
Requires IAM credentials
API rate limits
IID can be exfiltrated

Strategy 4: Join Tokens (Bootstrapping)

When to use:

Initial agent deployment
No platform attestation available
Manual node provisioning
Testing/development

How it works:

Administrator generates join token on PKI Server
Token provided to agent at startup
Agent presents token to server
Server validates and immediately expires token
Agent receives long-term SVID

Generate token:

kubectl exec -n qhx-system qhx-pki-server-0 -- \
  /opt/qhx/bin/qhx-server token generate \
  -spiffeID spiffe://qhx.dev/agent/manual/node-1 \
  -ttl 300

Agent configuration:

plugins {
  NodeAttestor "join_token" {
    plugin_data {
      token_path = "/opt/qhx/join-token"
    }
  }
}

Advantages:

Works in any environment
No platform dependencies
Simple to understand
Useful for bootstrapping

Disadvantages:

Manual process (doesn’t scale)
Token theft risk
One-time use only
No ongoing attestation

Best practices:

Use only for initial bootstrap
Immediately delete used tokens
Rotate to stronger attestation method
Never reuse tokens

Workload Attestation Strategies

Workload attestation happens after node attestation establishes the agent’s identity.

Kubernetes Workload Attestation

How it works:

Workload calls Workload API (Unix socket)
PKI Agent identifies caller’s process ID
Agent queries cgroup to find container ID
Agent queries kubelet for pod/container metadata
Agent matches metadata to registration entries
Agent returns cached SVID to workload

Selectors available:

Selector	Example	Description
`k8s:ns`	`k8s:ns:production`	Pod namespace
`k8s:sa`	`k8s:sa:api-server`	Service account
`k8s:pod-name`	`k8s:pod-name:api-7f8c9`	Pod name (unstable for Deployments)
`k8s:pod-uid`	`k8s:pod-uid:abc-123`	Unique pod identifier
`k8s:pod-label`	`k8s:pod-label:app:api`	Pod label (key:value)
`k8s:container-name`	`k8s:container-name:app`	Container name within pod
`k8s:container-image`	`k8s:container-image:api:v1.0`	Container image reference
`k8s:node-name`	`k8s:node-name:node-1`	Node pod is running on

PKI Agent configuration:

plugins {
  WorkloadAttestor "k8s" {
    plugin_data {
      skip_kubelet_verification = false
      kubelet_ca_path = "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
      token_path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
      node_name_env = "MY_NODE_NAME"
    }
  }
}

Agent DaemonSet must have:

spec:
  template:
    spec:
      hostPID: true  # Required to see workload PIDs
      env:
      - name: MY_NODE_NAME
        valueFrom:
          fieldRef:
            fieldPath: spec.nodeName

Unix Workload Attestation

When to use:

Non-containerized workloads
Bare metal servers
Traditional VMs
Process-level identity required

Selectors available:

Selector	Example	Description
`unix:uid`	`unix:uid:1000`	User ID
`unix:gid`	`unix:gid:1000`	Group ID
`unix:path`	`unix:path:/usr/bin/api`	Executable path
`unix:sha256`	`unix:sha256:<hash>`	Executable hash

Configuration:

plugins {
  WorkloadAttestor "unix" {
    plugin_data {}
  }
}

Example registration:

qhx-server entry create \
  -parentID spiffe://qhx.dev/agent/node-1 \
  -spiffeID spiffe://qhx.dev/webapp \
  -selector unix:uid:1000 \
  -selector unix:path:/opt/webapp/bin/server

Docker Workload Attestation

Selectors available:

Selector	Example	Description
`docker:label`	`docker:label:app:api`	Container label
`docker:image_id`	`docker:image_id:sha256:abc`	Image digest
`docker:env`	`docker:env:ENVIRONMENT:prod`	Environment variable

Registration Modalities

Pre-Registration (Static Entries)

Definition: Administrator explicitly creates registration entries before workloads start.

Method 1: CLI registration

# Node registration
kubectl exec -n qhx-system qhx-pki-server-0 -- \
  /opt/qhx/bin/qhx-server entry create \
  -node \
  -spiffeID spiffe://qhx.dev/k8s-node-pool-prod \
  -selector k8s_psat:cluster:production \
  -selector k8s_psat:agent_ns:qhx-system

# Workload registration
kubectl exec -n qhx-system qhx-pki-server-0 -- \
  /opt/qhx/bin/qhx-server entry create \
  -parentID spiffe://qhx.dev/k8s-node-pool-prod \
  -spiffeID spiffe://qhx.dev/ns/production/sa/api \
  -selector k8s:ns:production \
  -selector k8s:sa:api \
  -selector k8s:pod-label:app:api

**Method 2: CRD-based registration **

apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterStaticEntry
metadata:
  name: production-api-identity
spec:
  spiffeID: spiffe://qhx.dev/ns/production/sa/api
  parentID: spiffe://qhx.dev/k8s-node-pool-prod
  selectors:
    - k8s:ns:production
    - k8s:sa:api
  x509SVIDTTL: 1h
  federatesWith:
    - partner-domain.com
  admin: false
  downstream: false

Advantages:

Explicit control over identities
Audit trail via GitOps
Policy-as-code
Works without cluster access

Disadvantages:

Manual process (doesn’t scale for many workloads)
Must anticipate all workloads
Stale entries for deleted workloads
Requires server access or CRD permissions

When to use:

Small number of well-known services
High-security environments requiring approval
Regulatory compliance needs
GitOps-managed infrastructure

Best practices:

Store entries in version control
Use namespace/service account patterns
Include MLS labels in comments
Document selector rationale

Automated Registration

Definition: System automatically creates registration entries based on observed workloads.

QHx Admission Controller Integration:

When QHx admission controller applies MLS labels, it can automatically create registration entries:

# User creates Deployment (no registration entry exists yet)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  template:
    spec:
      serviceAccountName: api
      containers:
      - name: api
        image: api:v1.0

Admission controller mutates:

metadata:
  labels:
    mls.qhx.dev/level: "us:s"        # Applied automatically
    mls.qhx.dev/releasability: "us"
    app: api

Admission controller creates registration entry:

apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterStaticEntry
metadata:
  name: production-api-abc123
  ownerReferences:
  - apiVersion: apps/v1
    kind: Deployment
    name: api
    uid: abc-123-def-456
spec:
  spiffeID: spiffe://qhx.dev/ns/production/sa/api
  parentID: spiffe://qhx.dev/k8s-node-pool-prod
  selectors:
    - k8s:ns:production
    - k8s:sa:api
    - k8s:pod-label:app:api

Lifecycle management:

Entry created when Deployment created
Entry updated when Deployment updated
Entry deleted when Deployment deleted (via ownerReference)

Advantages:

Zero operator intervention
Scales to thousands of workloads
No stale entries (garbage collected)
Immediate identity issuance

Disadvantages:

Less explicit control
Harder to audit (many entries)
Requires cluster permissions
May create unnecessary entries

When to use:

Large number of dynamic workloads
Kubernetes-native applications
Development/staging environments
Microservices architectures

Hybrid Approach (Recommended)

Combine pre-registration and automation:

Pre-register:

Node identities (stable, few nodes)
Critical services (database, API gateway)
Cross-namespace services
Federated identities

Auto-register:

Application workloads (many, ephemeral)
Development services
Batch jobs
Sidecar proxies

Example:

# Pre-registered: Node pool identity
---
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterStaticEntry
metadata:
  name: production-node-pool
spec:
  spiffeID: spiffe://qhx.dev/k8s-node-pool-prod
  selectors:
    - k8s_psat:cluster:production
  x509SVIDTTL: 24h

---
# Pre-registered: Database identity
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterStaticEntry
metadata:
  name: production-postgres
spec:
  spiffeID: spiffe://qhx.dev/ns/production/sa/postgres
  parentID: spiffe://qhx.dev/k8s-node-pool-prod
  selectors:
    - k8s:ns:production
    - k8s:sa:postgres
  x509SVIDTTL: 12h

---
# Auto-registered: Application workloads
# (created by QHx admission controller as Deployments are created)

Selection Criteria

Choosing Node Attestation Strategy

Criterion	TPM	K8s PSAT	Cloud IID	Join Token
Hardware root of trust	✅	❌	❌	❌
Works in cloud	⚠️ Limited	✅	✅	✅
Works bare metal	✅	⚠️ K8s required	❌	✅
Auto-scaling friendly	❌	✅	✅	❌
Setup complexity	High	Low	Low	Very low
Operational burden	High	Low	Low	High

Decision tree:

Is hardware root of trust required?
├─ Yes → TPM attestation
└─ No
   └─ Running on Kubernetes?
      ├─ Yes → K8s PSAT attestation
      └─ No
         └─ Running in cloud (AWS/Azure/GCP)?
            ├─ Yes → Cloud IID attestation
            └─ No → Join token (then upgrade)

Choosing Workload Attestation Strategy

Environment	Strategy	Selectors
Kubernetes	K8s workload attestor	`k8s:ns`, `k8s:sa`, `k8s:pod-label`
Docker (non-K8s)	Docker workload attestor	`docker:label`, `docker:image_id`
Bare metal / VM	Unix workload attestor	`unix:uid`, `unix:path`, `unix:sha256`
Windows	Windows workload attestor	`windows:*`

Selector selection criteria:

Most stable (recommended):

k8s:ns + k8s:sa (doesn’t change across restarts)
unix:sha256 (pinned to binary)

Moderately stable:

k8s:pod-label (changes if labels change)
unix:path (changes if binary moves)

Unstable (avoid):

k8s:pod-name (changes on every restart for Deployments)
k8s:container-name (changes if container renamed)

Choosing Registration Modality

Factor	Pre-Registration	Automated	Hybrid
Workload count	< 50	> 500	50-500
Change frequency	Weekly or less	Hourly or more	Daily
Compliance needs	High (audit trail)	Low (dynamic)	Medium
Expertise required	Low (manual)	High (automation)	Medium
GitOps-friendly	✅ Very	⚠️ Generated	✅ Partial

QHx-Specific Considerations

Integration with MLS Labels

QHx admission controller applies MLS labels that can be used as selectors:

apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterStaticEntry
spec:
  spiffeID: spiffe://qhx.dev/ns/classified/sa/mission-app
  selectors:
    - k8s:ns:classified
    - k8s:sa:mission-app
    - k8s:pod-label:mls.qhx.dev/level:us:ts
    - k8s:pod-label:mls.qhx.dev/compartment:us:quantum

Why this matters:

Flowspecs can match on SPIFFE ID
Identity encodes classification level
Network policy generated from labels
Defense in depth (labels + identity)

Multiple PKI Servers (Algorithm Diversity)

QHx runs multiple PKI Servers for different algorithms:

# Node registration for ML-DSA-65 server
---
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterStaticEntry
metadata:
  name: production-nodes-mldsa65
  annotations:
    qhx.dev/pki-server: mldsa65
spec:
  spiffeID: spiffe://qhx.dev/k8s-node-pool-prod
  className: mldsa65  # Routes to ML-DSA-65 PKI Server
  selectors:
    - k8s_psat:cluster:production

---
# Node registration for EC-P384 server (legacy)
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterStaticEntry
metadata:
  name: production-nodes-ecp384
  annotations:
    qhx.dev/pki-server: ec-p384
spec:
  spiffeID: spiffe://qhx.dev/k8s-node-pool-legacy
  className: ec-p384  # Routes to EC-P384 PKI Server
  selectors:
    - k8s_psat:cluster:production
    - k8s_psat:agent_node_label:crypto:traditional

Namespace routing:

apiVersion: qhx.dev/v1
kind: QHxPolicy
metadata:
  namespace: production-critical
spec:
  signatureAlgorithm: mldsa87
  # Workloads in this namespace get identities from mldsa87 PKI Server

Attestation and Policy Evaluation Order

1. User creates Deployment
   ↓
2. QHx Admission Controller intercepts
   ↓
3. Extract user groups from authentication
   ↓
4. Evaluate QHxClusterPolicy
   ↓
5. Apply MLS labels
   ↓
6. Create/update ClusterStaticEntry (if automated)
   ↓
7. Deployment created
   ↓
8. Pod scheduled to node
   ↓
9. PKI Agent attests node (if first pod on node)
   ↓
10. Container starts, calls Workload API
   ↓
11. PKI Agent attests workload
   ↓
12. Agent matches selectors to registration entries
   ↓
13. Agent requests SVID from PKI Server
   ↓
14. PKI Server signs SVID
   ↓
15. Agent returns SVID to workload

Operational Procedures

Verifying Attestation

Check node attestation:

# List attested nodes
kubectl exec -n qhx-system qhx-pki-server-0 -- \
  /opt/qhx/bin/qhx-server agent list

# Output:
# SPIFFE ID: spiffe://qhx.dev/agent/k8s/node-1
# Attestation type: k8s_psat
# Expiration: 2026-02-03 10:00:00 +0000 UTC
# Selectors:
#   k8s_psat:cluster:production
#   k8s_psat:agent_node_name:node-1

Check workload registration:

# List registration entries
kubectl exec -n qhx-system qhx-pki-server-0 -- \
  /opt/qhx/bin/qhx-server entry show \
  -parentID spiffe://qhx.dev/agent/k8s/node-1

# Output:
# Entry ID: abc-123-def-456
# SPIFFE ID: spiffe://qhx.dev/ns/production/sa/api
# Parent ID: spiffe://qhx.dev/agent/k8s/node-1
# Selectors:
#   k8s:ns:production
#   k8s:sa:api

Check workload received SVID:

# From inside workload container
ls -la /run/secrets/qhx.dev/

# Output:
# svid.pem        (X.509 certificate)
# svid-key.pem    (Private key)
# bundle.pem      (Trust bundle)

Troubleshooting Attestation Failures

Node attestation fails:

# Check agent logs
kubectl logs -n qhx-system -l app=qhx-pki-agent

# Common issues:
# - "failed to attest node: context deadline exceeded"
#   → PKI Server unreachable, check NetworkPolicy
# - "failed to attest node: invalid token"
#   → Service account token expired or invalid
# - "failed to attest node: PCR values do not match"
#   → TPM measurements changed (BIOS update?)

Workload attestation fails:

# Check agent logs for workload PID
kubectl logs -n qhx-system -l app=qhx-pki-agent | grep "pid=<PID>"

# Common issues:
# - "workload does not match any registration entry"
#   → No registration entry with matching selectors
# - "failed to query kubelet"
#   → Agent cannot reach kubelet, check hostPID setting
# - "container not found"
#   → cgroup detection failed, check containerd version

Monitoring Attestation Health

Prometheus metrics:

# Node attestation rate
rate(qhx_node_attestations_total[5m])

# Node attestation failures
rate(qhx_node_attestations_failed_total[5m])

# Workload attestation rate
rate(qhx_workload_attestations_total[5m])

# Workload attestation failures
rate(qhx_workload_attestations_failed_total[5m])

# Registration entries per node
qhx_registration_entries_per_node

Alert examples:

groups:
- name: qhx-attestation
  rules:
  - alert: NodeAttestationFailureHigh
    expr: rate(qhx_node_attestations_failed_total[5m]) > 0.1
    annotations:
      summary: "High node attestation failure rate"

  - alert: WorkloadAttestationFailureHigh
    expr: rate(qhx_workload_attestations_failed_total[5m]) > 1
    annotations:
      summary: "High workload attestation failure rate"

  - alert: NoRegistrationEntriesForNode
    expr: qhx_registration_entries_per_node == 0
    for: 5m
    annotations:
      summary: "Node has no registration entries"

Security Considerations

Node Attestation Security

Threat: Agent impersonation

Mitigation: Use TPM or Kubernetes PSAT (cryptographically verified)
Don’t: Rely solely on join tokens in production

Threat: Token theft (Kubernetes)

Mitigation: Short token TTL, rotate service account keys
Don’t: Use long-lived service account tokens

Threat: IID replay (cloud)

Mitigation: PKI Server validates IID freshness
Don’t: Disable IID validation checks

Workload Attestation Security

Threat: Selector spoofing

Mitigation: Use cryptographically verifiable selectors (image hash, not label)
Don’t: Rely on user-controlled selectors (pod labels can be set by user)

Threat: Container escape

Mitigation: Use AppArmor/SELinux, see Security Hardening Guide
Don’t: Run privileged containers with workload identities

Threat: SVID theft

Mitigation: Short SVID TTL (1 hour), memory-locked keys
Don’t: Write SVIDs to disk or logs

Security Hardening Guide - TPM configuration, container security
MLS Policy Authoring - Group-to-label mappings
Admission Controller - Automated label application
Architecture - PKI Server and Agent components

Attestation Strategies

Overview

Attestation Fundamentals

Two-Phase Attestation Model

The Parent-Child Relationship

Node Attestation Strategies

Strategy 1: TPM-Based Attestation

Strategy 2: Kubernetes PSAT (Projected Service Account Token)

Strategy 3: Cloud Provider IID (AWS, Azure, GCP)

Strategy 4: Join Tokens (Bootstrapping)

Workload Attestation Strategies

Kubernetes Workload Attestation

Unix Workload Attestation

Docker Workload Attestation

Registration Modalities

Pre-Registration (Static Entries)

Automated Registration

Hybrid Approach (Recommended)

Selection Criteria

Choosing Node Attestation Strategy

Choosing Workload Attestation Strategy

Choosing Registration Modality

QHx-Specific Considerations

Integration with MLS Labels

Multiple PKI Servers (Algorithm Diversity)

Attestation and Policy Evaluation Order

Operational Procedures

Verifying Attestation

Troubleshooting Attestation Failures

Monitoring Attestation Health

Security Considerations

Node Attestation Security

Workload Attestation Security

Related Documentation