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 deployment's configuration and secrets at the application layer using SOPS with an age key. This key (age.key) is generated locally during init and held solely by you — Manifest never receives it. See Installation → Initialize the Deployment.

⚠️

Back up ~/.manifest/deployment/<name>/age.key immediately. This key encrypts your configuration and secrets. If it is lost, encrypted values cannot be recovered.

This provides a second, independent layer of encryption for sensitive configuration values, in addition to the disk-level encryption you enforce underneath it.

---

(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 SOPS age.key) is generated locally during installation and exists only on your host and in your backups.

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:

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 (age.key): the file resides on the host at ~/.manifest/deployment/<name>/age.key. Restrict it to the operator account that runs manifest-installer (for example, chmod 0600 and ownership limited to that user), and store any backup copy in your secrets vault with access restricted 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 - Deployment initialization and the SOPS age.key
• Configuration Reference - Storage layout and STIG / FIPS compliance
• Post-Install - Certificate trust and custom TLS certificates
• Firewall Configuration - Network access controls