RFC-WORKLOAD-IDENTITY-0001                                      Section 1
Category: Standards Track                                    Introduction

1. Introduction

← Previous: Index | Index | Next: Requirements →

1.1 Background

1.1.1 The Identity Challenge

Modern cloud-native infrastructure runs thousands of non-human principals: containers, services, pipelines, operators, scheduled jobs, and increasingly, AI agents. Each of these workloads needs to:

• Authenticate: Prove its identity to other systems
• Authorize: Access only permitted resources
• Communicate securely: Encrypt traffic with verified peers
• Audit: Leave traceable evidence of its actions

Unlike human users who can interactively authenticate with passwords and MFA, workloads must authenticate programmatically, often at high frequency, without human intervention.

1.1.2 The Evolution of Workload Authentication

The industry has progressed through several generations of workload authentication:

This RFC establishes a Gen 5 workload identity architecture based on attestation rather than pre-shared secrets.

1.1.3 Relationship to Human Identity

RFC-IAM-0001 establishes the human identity architecture:

Azure AD → Keycloak → Platform Applications

This RFC establishes a parallel workload identity architecture:

Cloud/Kubernetes Attestation → SPIRE → Service-to-Service

Both architectures share:

• Azure AD as authorization ceiling: Ultimate source of truth for permissions
• Vault as credential authority: Issues dynamic credentials
• ESO for secret distribution: Kubernetes-native secret delivery
• Audit requirements: Traceability across all identity actions

But implement different patterns:

• Human: Interactive authentication, session-based access
• Workload: Programmatic authentication, certificate-based identity

1.2 Current State Analysis

1.2.1 Existing Workload Identity Patterns

Current workload authentication is fragmented across multiple approaches:

1.2.2 Identified Gaps

1.2.3 Compliance Requirements

Various compliance frameworks require workload identity controls:

1.3 Problem Statement

1.3.1 Core Problems

This RFC addresses five core problems:

Problem 1: Credential Management Complexity Organizations struggle to manage credentials for hundreds or thousands of workloads. Static credentials require manual rotation, lead to secret sprawl, and create operational burden.

Problem 2: Lack of Workload Attestation Traditional authentication relies on "something you know" (a secret). If that secret is stolen, the thief can authenticate from anywhere. Workload attestation proves "what you are" based on verifiable workload properties.

Problem 3: No Unified Identity Model Different workload types use different identity mechanisms: Kubernetes ServiceAccounts, cloud IAM, SSH keys, API tokens. This fragmentation makes it difficult to implement consistent security policies.

Problem 4: AI Agent Identity Gap Emerging AI agents (LLMs performing automated tasks) need to act on behalf of humans or other systems, but traditional identity models don't support delegation chains with proper accountability.

Problem 5: Cross-Boundary Identity Multi-cluster, multi-cloud environments need federated identity that works across trust boundaries while maintaining security guarantees.

1.3.2 Solution Approach

This RFC addresses these problems through:

1.4 Document Structure

1.4.1 Section Overview

This RFC is organized into functional sections:

1.4.2 How to Use This Document

For understanding: Read sections 1-3 to grasp the overall architecture.

For implementation: Read section 4 for components, then the relevant workload category section (5-10) for your use case.

For security review: Focus on section 2 (invariants) and section 13 (rationale).

For operations: Sections 5-10 provide operational patterns for each workload type.

1.5 Terminology

Key terms used throughout this RFC:

See Appendix A for complete glossary.

Document Navigation

End of Section 1