Encryption & Key Management

Manifest Self-Hosted runs entirely within your own infrastructure. One Linux host that you provision, own, and operate runs the k3s control plane, the Manifest applications, and the supporting data stores. Because the platform is deployed in your environment, you retain full control over encryption: the key management system (KMS), the key rotation policy, and the access controls that govern who can use those keys.

This page describes how encryption responsibilities are divided between Manifest and you, what the platform encrypts on your behalf, and our recommendations for configuring encryption to meet enterprise and regulatory requirements.

---

Shared Responsibility Model

Manifest provides the software and the application-level secrets encryption that ships with it. Everything below the application — the host, the disks, the storage layer, the KMS, and the network — is owned and controlled by you, the customer.

Manifest never receives, stores, or has access to your encryption keys. All key material is generated in and remains within your infrastructure.

---

Recommended Encryption Standards

Manifest recommends the following minimums for all Self-Hosted deployments. Because the deployment runs in your infrastructure, you are able to enforce each of these directly.

• Data at rest: AES-256 (or stronger) full-disk / volume encryption for every volume that backs the platform, including the OS volume and the persistent-data volume.
• Data in transit: TLS 1.2 or higher (TLS 1.3 preferred) using AES-256 / AES-GCM cipher suites for all external and inter-service traffic.
• Disk encryption keys: held in a dedicated KMS (for example, a cloud provider KMS such as AWS KMS, an HSM, or a key-management appliance) rather than on the host itself.
• FIPS-validated cryptography: where required, use FIPS 140-3 validated cryptographic modules. Manifest Self-Hosted is compatible with FIPS-enabled and STIG-hardened hosts — see Configuration Reference → STIG Compliance.

These are recommended minimums. You may apply stronger controls to satisfy your internal or regulatory obligations.

---

Encryption in Transit

• External traffic to the platform terminates at the ingress (Traefik) over HTTPS on TCP 443. You supply the serving certificate, so you control the TLS version and cipher suites presented to clients. See Post-Install → Certificate configuration for certificate trust and custom-certificate setup.
• Internal traffic between services runs within the single host and the cluster network, inside the network boundary that you define and control. We recommend restricting host access using the firewall guidance and isolating the host within your own network segmentation.

We recommend TLS 1.3 with AES-256-GCM where your clients support it, and disabling deprecated protocol versions and weak ciphers at your ingress.

---

Encryption at Rest

The platform persists data on the host in two places:

• a relational database holding application data, and
• an S3-compatible object store holding uploaded artifacts (for example, SBOMs).

Both run as containers on the host and store their data on Kubernetes persistent volumes under /var/lib/rancher/k3s/storage/ (see Configuration Reference → Storage). Because these volumes live on disks that you provision, encryption at rest is applied and controlled at your infrastructure layer.

Recommendation: enable AES-256 full-disk or volume encryption on every volume backing the deployment, with the encryption keys managed by your KMS. For example:

• On cloud infrastructure, use provider volume encryption backed by your own KMS keys (for example, AWS EBS encryption backed by a customer-managed AWS KMS key).
• On bare metal or on-prem virtualization, use LUKS/dm-crypt (or an equivalent) with keys released by your KMS, HSM, or key-management appliance.

Because the host and its disks are entirely within your environment, this satisfies bring-your-own-key (BYOK) requirements directly: the platform's data is encrypted with keys that you generate, store, and control in your own KMS.

Application-Level Secrets Encryption

In addition to disk encryption, manifest-installer encrypts the sensitive values in the deployment's configuration file (~/.config/manifest/config.yaml) at the application layer using SOPS with an age or GPG key. The setup wizard asks you to make a deliberate encryption choice before it writes anything; encryption is the recommended path, and nothing is pre-selected for you.

When encryption is on, only the sensitive values are encrypted, in place — the rest of config.yaml stays human-readable, so the file remains reviewable and diffable. All key material is generated in and remains within your infrastructure — Manifest never receives it. This provides a second, independent layer of encryption for sensitive configuration values, in addition to the disk-level encryption you enforce underneath it.

The choice is made once: when config.yaml already exists, a setup re-run keeps your existing decision without asking again. To change it later, run manifest-installer setup --prompt-encryption, or use deploy-config encrypt / deploy-config rekey (see Configuration Reference → Maintaining config.yaml).

Back Up config.yaml — and Understand Key Loss

• Back up config.yaml after setup and after any later configuration change. With encryption on, the encrypted file is safe to store in an ordinary backup system; keep the passphrase (or your age/GPG secret key) somewhere separate, such as a password manager or key escrow. If you chose the password-protected key option, back up the age-key.age key file too — it is safe to store alongside the config because it is useless without the passphrase.
• Before your first deploy, losing the key or the file is harmless: delete config.yaml if it still exists, re-run setup, and make a fresh choice.
• After deploy, the generated workload passwords in config.yaml are load-bearing — the running platform was initialized with them and they cannot be regenerated. If you lose the ability to decrypt the file and have no backup, the installation cannot be reconstructed.
• Hedge against a lost key by adding a second recipient (a teammate's key or an escrow key): manifest-installer deploy-config rekey --age <age1...> (or --gpg <fingerprint>). rekey is additive — every existing recipient keeps access.

---

(1) Per-Customer Key Separation & BYOK

Each Manifest Self-Hosted deployment is single-tenant and fully isolated within your own infrastructure. There is no shared, multi-tenant key material — keys are not managed by Manifest and are never shared across customers.

• Infrastructure keys (disk, volume, database, and object-storage encryption) are your own KMS keys, generated and stored in your environment. This is BYOK by design: you bring and control the keys used to encrypt all platform data.
• Application-level secrets key (the age or GPG key chosen at setup) is generated locally or supplied by you, and exists only in your environment: the password-protected key file and any GPG secret key live on the host; a self-supplied age secret key lives wherever you keep it.

Because the entire deployment runs in your environment, key separation per customer is inherent: every customer's deployment uses distinct keys that never leave that customer's infrastructure.

---

(2) Key Rotation Policy

Because all key material lives in your infrastructure, you define and enforce the rotation policy to match your internal standards and regulatory requirements. Manifest recommends:

• Rotating encryption keys at least annually, and
• Rotating immediately upon suspected compromise, or upon personnel or access changes affecting key custodians.

How to rotate each class of key:

Rotating or Removing the Application Secrets Key

deploy-config rekey is additive: it re-encrypts to the existing recipients plus the new one, so every prior key keeps access. Use it to add a teammate's or escrow key — not for rotation or compromise response.

To rotate the key, or to revoke a compromised or departed custodian's key:

1. Run manifest-installer setup --prompt-encryption and choose the new key. The installer decrypts config.yaml with a current key and re-encrypts it to the new choice only — all previous recipients lose access.
2. Re-add any recipients that should keep access: manifest-installer deploy-config rekey --age <age1...> (or --gpg <fingerprint>).

Existing backups of config.yaml remain decryptable by the keys they were encrypted to; after a compromise, purge or re-protect affected backups.

Aligning your cadence with a recognized standard (for example, NIST SP 800-57) is recommended.

---

(3) Access Control to Encryption Keys

Access to encryption keys is governed entirely by controls in your environment:

• KMS / infrastructure keys: restrict use of each key with least-privilege key policies and IAM (for example, AWS KMS key policies and grants). Limit decrypt / use permissions to only the host roles and operators that require them, and audit key usage through your KMS access logs.
• Application secrets key: with the password-protected option, the key file resides on the host at ~/.config/manifest/age-key.age and is useless without its passphrase — store the passphrase in your secrets vault with access restricted to authorized key custodians. With your own age key, the secret key is never stored on the host — you provide it only at decryption time; govern it under your existing key-custody controls. With your own GPG key, the secret key resides in the host's GPG keyring — restrict keyring and host access to authorized key custodians.
• Platform and cluster access: restrict host login, sudo, and Kubernetes (k3s) access to authorized administrators, since these grant the ability to reach running secrets. See Requirements and Firewall Configuration.

Because Manifest does not hold any keys, the complete access-control list for encryption keys is defined and maintained by you, and is auditable through your own KMS, host, and identity systems.

---

Compliance

Manifest Self-Hosted is compatible with FIPS 140-3 validated cryptography and STIG-hardened hosts. For questions about FIPS, STIG, or other compliance requirements, see Configuration Reference → STIG Compliance or contact Manifest Cyber at [email protected].

---

Related Documentation

• Installation - Setup wizard and the encryption choice
• Configuration Reference - config.yaml maintenance, storage layout, and STIG / FIPS compliance
• Post-Install - Certificate trust and custom TLS certificates
• Firewall Configuration - Network access controls