Skip to content

Identity and Access Architecture

Overview

The Archon Platform treats identity as a foundational control layer, not an afterthought. Every credential, certificate, and machine identity flows through a single authoritative secrets manager, enforced by policy across all scopes: pipelines, Ansible automation, Kubernetes workloads, and developer tooling.

Secrets Root: Infisical

Infisical (self-hosted) is the platform-wide secrets manager. No secrets are hardcoded in configuration files, container images, or source repositories. All runtime secret delivery goes through Infisical, whether fetched by a pipeline step, an Ansible play, or a Kubernetes operator.

This is a hard architectural constraint -- introducing a second secrets tool requires a superseding ADR. The decision is documented in IAM-0001.

IT/OT Zone Separation as Policy Spine

The platform enforces strict separation between IT and OT zones at the identity layer. IT and OT Ansible automation run under distinct service accounts with no shared credentials and no cross-zone sudo permissions. This separation mirrors the network zone boundary and satisfies IEC 62443 zone-and-conduit requirements.

The IT/OT zone separation policy is the architectural spine from which service account decisions derive. See IAM-0002.

Service Account Model

Two dedicated Ansible service accounts handle automation:

  • IT automation account -- operates exclusively on IT-zone nodes. Created with a dedicated SSH keypair, stored in Infisical. Documented in IAM-0003.

  • OT automation account -- operates exclusively on OT-zone nodes. Separate keypair, separate Infisical path, zero cross-zone sudo. Documented in IAM-0004.

No shared credentials exist between zones. Each account's private key is managed solely in Infisical and rotated on a defined cadence.

Machine Identity in Kubernetes: External Secrets Operator

Kubernetes workloads that need secrets use the External Secrets Operator (ESO) to pull from Infisical at runtime. The ESO ClusterSecretStore is bootstrapped from a single machine identity credential. Once running, individual ExternalSecret resources fetch only the secrets they need -- workloads never receive more than minimum required access.

This approach eliminates Kubernetes Secret sprawl and keeps Infisical as the single source of truth even inside the cluster. See IAM-0005.

TLS Lifecycle: cert-manager

TLS certificates are managed by cert-manager, backed by Let's Encrypt DNS-01 challenge. Certificates are automatically provisioned and renewed -- no manual certificate management. The cert-manager decision is part of the PLAT-0005 ADR.

Key Properties

  • Single secrets root (Infisical) -- no credential sprawl
  • Zone-separated automation accounts -- IT and OT identities cannot cross zones
  • Kubernetes machine identity via ESO -- no hardcoded cluster secrets
  • Automated TLS -- no manual certificate lifecycle