RFC-RFCSTD-0002                                                   Section 6
Category: Standards Track                                         Examples

### Invariant 3 — Secret Authority
 
HashiCorp Vault MUST be the sole authoritative source for secrets
required by platform applications.
 
No application MAY store authoritative secrets outside of Vault.
Kubernetes Secrets exist only as derived artifacts synchronized
by External Secrets Operator.
 
This invariant ensures centralized secret lifecycle management
and auditability. Violation would create untracked secrets
outside the rotation and audit framework.

### 9.1.2 Direct Azure AD Integration
 
**Description**: Each application integrates directly with Azure AD
without a platform identity layer.
 
**Why It Was Attractive**:
- Simpler initial setup—no Keycloak to maintain
- Native Microsoft tooling support
- One fewer component in the stack
 
**Why It Was Rejected**:
- Each application requires separate Azure AD configuration
- No centralized platform-level authorization
- Cannot add platform-specific claims or roles
- Violates Invariant 2 (Authentication Chain)—identity must flow
  through Keycloak
 
**Conclusion**: Direct integration prevents unified platform identity
and would require each team to implement authentication separately.

### External Secrets Operator
 
| Aspect | Description |
|--------|-------------|
| Responsibility | Synchronize secrets from Vault to Kubernetes Secrets |
| Inputs | SecretStore CRD, ExternalSecret CRD |
| Outputs | Kubernetes Secret objects |
| Dependencies | Vault (source), Kubernetes API (target) |
| Failure Mode | Sync stops; secrets become stale |
| Recovery | Automatic retry on Vault availability |

## Design Goals
 
### Goal 1 — Unified Identity
 
All platform users and services MUST authenticate through a single
identity chain, enabling consistent authorization across all
platform applications.
 
### Goal 2 — Auditability
 
All authentication and authorization events MUST be logged with
sufficient detail for security investigation and compliance
reporting.

## Non-Goals
 
### Non-Goal 1 — User Provisioning
 
This architecture does NOT define how users are created or
deprovisioned. User lifecycle management is out of scope.
See RFC-IDENTITY-LIFECYCLE-0001 for user provisioning.
 
### Non-Goal 2 — Application-Level Authorization
 
This architecture defines platform-level roles (admin, developer,
viewer). Fine-grained application-level authorization is the
responsibility of individual applications.