Use this checklist before putting Stronghold into production and during periodic configuration reviews. Items that rely on Stronghold EE features are marked.

Network and TLS

  • TLS is enabled on all listeners. The tls_disable parameter of the listener block is not used. In DP, all network listeners use TLS. Only the metrics listener 127.0.0.1:8400 inside the pod uses plain HTTP, and it is not reachable from outside the pod.
  • The minimum TLS version is tls12 or tls13 (the tls_min_version parameter).
  • Raft inter-node communication uses per-node certificates and a shared CA.
  • Certificate expiry monitoring and a certificate replacement procedure are in place.
  • Access to the API port (8200) is limited to client networks, and access to the cluster port (8201) to Stronghold nodes only.
  • In DP, the pod ports are: 8200 (API), 8201 (cluster port), 8300/8301 (internal API and cluster port between pods), 8500 (mTLS listener, only with the Ingress and GatewayAPI inlets) and 9889 (metrics via kube-rbac-proxy). Port 8201 is exposed outside the cluster only for replication (publishCluster).
  • Unauthenticated access to sys/metrics and sys/pprof is either disabled or limited to a trusted network.
  • When a load balancer or proxy is used, x_forwarded_for_authorized_addrs and a sys/health check are configured.

Access and authentication

  • Standalone installations and DP Manual mode: the root token obtained during initialization is revoked after the initial setup. For emergency operations, a root token is generated again with d8 stronghold operator generate-root.
  • DP Automatic mode: the risks of the stronghold-keys secret are reduced as described in the threat model. The secret contains the unseal key and the root token, which stronghold-automatic uses, so the root token is not revoked. RBAC access to the secret is minimal, and Kubernetes audit is enabled. If the keys are taken out of the secret and stored outside the cluster, or the values in the secret no longer match the current keys, automatic unsealing stops working, and the pods must be unsealed manually after each restart. Without the root token, stronghold-automatic cannot restore its access to Stronghold and stops configuring it. Details are in Keys in DP.
  • Administrators log in through an external provider (OIDC or LDAP) rather than userpass.
  • Multi-factor authentication is enabled for administrative roles.
  • Applications use machine auth methods (Kubernetes, AppRole, JWT) without long-lived static tokens.
  • Policies follow the least-privilege principle; the use of * and sudo is limited.
  • Policies are stored in version control and applied automatically.
  • User lockout on password guessing is configured (the user_lockout block).

Audit

  • At least two audit devices are enabled.
  • Audit logs are shipped to a centralized system with restricted access.
  • Alerts on audit device write failures are configured.
  • Log rotation and free space monitoring are configured for the file device.

TTLs and limits

  • Global default_lease_ttl and max_lease_ttl are reduced from the default (768h) to values matching your security policy.
  • TTLs are configured at the mount and auth role level.
  • Rate limit quotas are configured for auth methods and heavily used paths.

Seal and keys

  • Auto unseal via HSM or KMS is used, or a manual Shamir unseal procedure is defined.
  • Unseal or recovery key shares are distributed among different trusted people and encrypted with their PGP keys.
  • No single person holds the threshold number of shares.
  • A key custody procedure (safe, envelopes, issue log) and a holder replacement procedure are defined.
  • Automatic encryption key rotation is configured (sys/rotate/config).

Backups

  • Regular Raft snapshots are configured (manual or automated in Stronghold EE).
  • Snapshots are stored outside the cluster in storage with restricted access.
  • Test restores from a snapshot are performed regularly in an isolated environment.
  • The key shares required to unseal a restored cluster are available separately from the snapshots.

Operating system and nodes

  • A supported OS is used, and security updates are installed regularly.
  • Stronghold runs as a dedicated unprivileged user (stronghold); data directories have 0700 permissions. In DP, the pod runs as the non-root user with UID 64535 with a read-only root file system and all capabilities dropped (drop: ALL).
  • Swap is disabled or encrypted (standalone; in DP, the module sets disable_mlock = true). With integrated Raft storage, disable_mlock = true is set, because mlock with Raft can exhaust memory, and swap is disabled, so that memory is not written to disk. Details are in the disable_mlock parameter description.
  • Core dumps are disabled for the Stronghold process, for example with LimitCORE=0 in the systemd unit (standalone).
  • Nodes run no unrelated services; SSH access is restricted and logged.
  • Time is synchronized via NTP on all nodes.
  • Raft data is stored on a local SSD, as described in Sizing.

High availability

  • The Raft cluster has 3 or 5 nodes placed in different failure domains. In DP, the module sets the number of replicas, and destructive storage migrations require at least 3 replicas. Details are in Sizing.
  • retry_join is configured on all nodes.
  • The lost quorum recovery procedure has been tested.
  • DR replication is configured for disaster recovery (Stronghold EE).

Monitoring

  • Metrics are collected from all nodes, and the alerts from Monitoring are configured.
  • The load balancer and external monitoring use sys/health.
  • Server logs are shipped to a centralized system.
  • The upgrade procedure is documented and tested.
←
Operations / Troubleshooting
Operations / Key management
→