> ZERO-TRUST // zt-arch-14
Automated Internal PKI with Ephemeral X.509 Certificates
Dynamic certificate authority architecture utilizing HashiCorp Vault PKI Secrets Engine, automatically issuing sub-hour ephemeral X.509 and SSH certificates with automated zero-touch rotation.
Adversary Threat Model
Adversary exfiltrates internal TLS private key or SSH key, attempting to maintain persistent long-term access.
Architecture Specs
NIST SP 800-207 Tenets Enforced
- ✓Access to individual enterprise resources is granted on a per-session basis.
- ✓All communication is secured regardless of network location.
MITRE ATT&CK Techniques Blocked
3 Maturity Tier Configurations
Evolutionary engineering configurations from baseline Initial up to CISA Optimal zero-compromise fortress.
Vault PKI issuing 30-day internal TLS certificates for microservices.
Vault AppRole authentication from Kubernetes deployment secrets.
Vault accessible over private VPC network.
Vault audit device logging to encrypted disk file.
Sub-hour ephemeral certificates (TTL 60 min) managed via cert-manager Vault issuer.
Kubernetes Service Account JWT authentication with automatic identity binding.
Mutual TLS enforced between cert-manager and Vault cluster.
Vault audit events streamed in real-time to security monitoring pipeline.
Multi-datacenter Vault replication with automated CRL generation and short-lived SSH client certs.
Sub-15-minute certificates; zero persistent private keys stored on disks anywhere.
Hardware Security Module (HSM) rooted offline Root CA with automated intermediate generation.
Continuous cryptographic anomaly detection on certificate issuance volume.
Infrastructure as Code: Terraform & Kubernetes
Production-ready declarative manifests for immediate automated deployment.
resource "vault_mount" "pki" {
path = "pki_int"
type = "pki"
description = "TinyCTO Ephemeral Intermediate PKI"
default_lease_ttl_seconds = 3600
max_lease_ttl_seconds = 86400
}
resource "vault_pki_secret_backend_role" "role" {
backend = vault_mount.pki.path
name = "tinycto-microservices"
ttl = 3600
allow_ip_sans = true
key_type = "ed25519"
allowed_domains = ["internal.tinycto.tv"]
allow_subdomains = true
}apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: order-service-tls
namespace: production
spec:
secretName: order-service-tls
duration: 1h
renewBefore: 15m
issuerRef:
name: vault-issuer
kind: ClusterIssuer
commonName: order-service.internal.tinycto.tv
dnsNames:
- order-service.internal.tinycto.tvDynamic certificate authority architecture utilizing HashiCorp Vault PKI Secrets Engine, automatically issuing sub-hour ephemeral X.509 and SSH certificates with automated zero-touch rotation.
Architecture Blueprint FAQs
How does the Automated Internal PKI with Ephemeral X.509 Certificates blueprint mitigate adversary threats and MITRE ATT&CK techniques?
Automated Internal PKI with Ephemeral X.509 Certificates addresses the following adversary profile: Adversary exfiltrates internal TLS private key or SSH key, attempting to maintain persistent long-term access. It actively eliminates lateral movement and privilege escalation by mitigating: T1552.004, T1098.004, T1021.004 via hardware-rooted identity, kernel-level enforcement, or continuous attestation.
Which NIST SP 800-207 Zero-Trust tenets does this architecture enforce?
This blueprint strictly operationalizes the following NIST SP 800-207 tenets: Access to individual enterprise resources is granted on a per-session basis.; All communication is secured regardless of network location.. Implicit trust based on network location is replaced with per-session dynamic cryptographic verification.
What are the technical differences between the Initial and Optimal maturity tiers?
The Initial tier focuses on baseline policy and identity enforcement (Vault PKI issuing 30-day internal TLS certificates for microservices.), while the Optimal tier delivers CISA ZTMM 2.0 zero-compromise fortress defense (Multi-datacenter Vault replication with automated CRL generation and short-lived SSH client certs.) using: vault-enterprise, cert-manager-csi, cloudhsm, step-ca.
What is the primary failure mode risk and how is high availability guaranteed?
The primary failure risk is identified as: Raft consensus split-brain stalling new certificate issuance during WAN cuts.. Resilience is maintained through active-active control planes, local cached attestations, and graceful degradation playbooks.
How can engineering teams automate this architecture using Terraform and Kubernetes?
The provided declarative Terraform HCL (main.tf) and Kubernetes policy manifests (policy.yaml) can be immediately integrated into automated GitOps CI/CD pipelines (e.g., ArgoCD, Flux) for reproducible, drift-detected infrastructure provisioning.