Domain, namespace, and identity validation governance
Trust Architecture Playbook: Governance pillar
Public-domain control
Domain control is a governance boundary, not only a validation step. The organization should maintain a domain registry that maps every public domain and high-value subdomain to a business owner, technical owner, DNS owner, approved CA sources, approved profiles, and allowed validation methods. Public-domain validation authority should be delegated deliberately and reviewed regularly. A team that can create DNS records can often prove domain control; that does not mean it should be allowed to obtain any certificate for any hostname.
Approve domain and subdomain ownership before enabling public TLS profiles.
Limit wildcard issuance to approved use cases with documented blast radius.
Require CT logs monitoring for all primary public domains.
Route unexpected CT findings to domain owner, PKI, security operations, and incident response as appropriate.
Review DNS automation credentials used for DCV as production secrets with least privilege and rotation requirements.
Internal namespace control
Internal namespaces require the same discipline, even when no external CA/B Forum validation occurs. Internal DNS zones, service discovery names, Kubernetes namespaces, SPIFFE trust domains, device identifiers, and application identifiers all need an authority model. The wrong internal certificate can allow impersonation of a service, device, workload, or user inside the network boundary.
Define who owns each internal namespace and who may approve certificate issuance within it.
Require namespace allow-lists in profiles wherever supported.
Use metadata and business units to bind issuance to the correct service or platform team.
Do not issue certificates for unowned internal names, shared ambiguous aliases, or decommissioned services without remediation.
Treat service mesh and workload identity namespaces as security boundaries, not merely platform labels.
ACME and workload identity delegation
ACME-based automation can help manage certificate lifecycles, but governance must constrain account scope, credential handling, profile binding, and namespace authorization. DigiCert® Trust Lifecycle Manager supports third-party ACME clients and mTLS over ACME as enrollment methods, using External Account Binding (EAB) credentials for authentication. In practice, EAB credentials represent delegated issuance authority and should be scoped and rotated like any other sensitive credential.
Create separate ACME profiles per trust domain, environment, platform, and business unit where feasible.
Ensure ACME profiles are tightly scoped and use IP/domain allowlists where supported to constrain issuance.
Do not share ACME credentials across unrelated applications or environments.
Require service owner and platform owner mapping before enabling workload identity issuance.
Monitor for anomalous issuance volume, unexpected SANs, profile use, or environment drift.
Require a disable/rotate procedure for compromised ACME credentials.
Workload identity authority model
Kubernetes, service mesh, and workload identity programs need an authority model before they need another profile. A namespace, service account, SPIFFE identity, mesh identity, or cluster trust domain is an issuance boundary. Governance should define who owns that boundary, which issuer may sign for it, how the workload proves identity, how often credentials rotate, and what evidence proves the control operated.
Authority element | Governance decision | Minimum evidence |
|---|---|---|
Namespace owner | Who may approve certificate issuance for a Kubernetes namespace, mesh namespace, SPIFFE trust domain, or internal service namespace. | Namespace registry entry, named owner, approval path, and review cadence. |
Platform owner | Who operates the cluster, mesh, ingress, cert-manager, issuer configuration, connector, or service mesh integration. | Platform runbook, connector or issuer ownership, access review, and escalation path. |
Workload identity issuer | Which CA source, intermediate, issuer, or profile family may sign workload certificates for the trust domain. | CA source registry entry, profile catalog entry, chain/trust anchor record, and approved scope. |
Attestation method | How the workload proves it is entitled to the identity: Kubernetes service account, SPIFFE/SPIRE attestation, CI/CD identity, node attestation, or mTLS bootstrap. | Attestation configuration, policy mapping, and validation logs. |
Profile scope | Allowed EKUs, URI SAN value and source, DNS SANs, validity, key settings, and environment boundaries. | Approved profile, SAN source configuration, namespace allowlist, service account mapping, and change record. |
Service account mapping | Which service accounts, workloads, deployments, or mesh identities map to which service owners and profiles. | Service account register, owner metadata, workload labels, and assignment rules. |
Rotation model | Expected lifetime, renewal path, revocation posture, rollout sequencing, and rollback or failover model. | Automation runbook, validation output, renewal success metrics, and exception record where needed. |
Evidence | What proof must exist for issuance, deployment, live identity, monitoring, and exception status. | Trust Lifecycle Manager audit logs, issuer logs, mesh or cluster configuration snapshots, dashboard signal, and evidence pack. |
중요
Workload identity boundary
Do not treat workload identity as only a platform engineering setting. The issuer, namespace, service account, and attestation method together create delegated issuance authority and must be governed like any other PKI trust boundary.