Encryption at rest

Red Hat Edge Manager encrypts sensitive control-plane data at rest so that a compromise of the underlying storage does not expose credentials, secrets, or other confidential information. Encryption is enabled by default and requires no additional configuration.

What data is encrypted
Copy link

The following fields are encrypted before being stored in PostgreSQL:

Table 1. Protected fields
Resource Field Description

Repository

spec.httpConfig.password

HTTP Basic authentication password

Repository

spec.httpConfig.token

HTTP bearer token

Repository

spec.httpConfig.tls.key

Client TLS private key

Repository

spec.httpConfig.tls.crt

Client TLS certificate

Repository

spec.sshConfig.sshPrivateKey

SSH private key

Repository

spec.sshConfig.privateKeyPassphrase

SSH key passphrase

Repository

spec.ociAuth.password

OCI registry password

AuthProvider

spec.clientSecret

Client secret for OIDC, OAuth2, Red Hat OpenShift Container Platform, and AAP authentication providers

Device

renderedConfig

Rendered device configuration

Device

renderedApplications

Rendered device applications

Fields that are not listed in this table are not encrypted. Examples include resource names, labels, annotations, metadata, repository URLs, authentication provider issuer URLs and client IDs, device status, system information, fleet selectors, templates, and rollout policies.

Warning

Do not store sensitive information such as passwords, tokens, private keys, or client secrets in fields that are not listed in the protected fields table. Only the listed fields are encrypted by Red Hat Edge Manager encryption at rest.

Data in transit between Red Hat Edge Manager components is protected separately by mutual TLS.

Backup and restore requirements
Copy link

Encryption keys are required to read encrypted data stored in PostgreSQL. Losing the encryption keys makes the affected encrypted fields permanently unreadable.

Red Hat Edge Manager includes encryption keys in backup archives when the encryption key directory is available at backup time. After each backup, verify that the archive contains the expected encryption key material before you rely on the archive for disaster recovery.

Do not restore a database backup without restoring the matching encryption keys. A replacement key cannot decrypt data that was encrypted with a previous key.

Warning

Backup archives can contain encryption keys, database contents, CA private keys, and TLS certificates. Store backup archives on encrypted storage with restricted access.

Upgrading from a pre-encryption version
Copy link

When you upgrade from a version that did not support encryption at rest, encryption is enabled automatically. During the upgrade, Red Hat Edge Manager generates the initial encryption key if one does not already exist. Existing plain text values remain readable, and new or updated protected values are written in encrypted form. A background migration process then encrypts existing protected data. No service downtime is required for this migration.

Key management overview
Copy link

During installation, Red Hat Edge Manager automatically generates a 256-bit encryption key and stores it on the host filesystem at /etc/flightctl/encryption/key. All control-plane containers mount the encryption key directory as a read-only volume.

The encryption subsystem supports multiple keys simultaneously. One key is designated as the active key and is used to encrypt new data. Previously used keys remain available for decrypting existing data, so that you can rotate keys without downtime or data migration.

If Red Hat Edge Manager encounters data that was encrypted with a non-active key, it transparently decrypts the value with the original key. The value is re-encrypted with the active key on the next write operation.

Providing your own key on fresh installs
Copy link

For new installations, you can supply a custom encryption key before starting Red Hat Edge Manager services. If a key already exists, Red Hat Edge Manager keeps it and does not generate a replacement key, so no rotation or migration is needed.

For existing deployments, use the key rotation procedure to switch to a custom key. For new installations, see Provide a custom encryption key for a fresh installation in the Additional resources section.

Security considerations
Copy link

Encryption at rest protects sensitive Red Hat Edge Manager data in scenarios where PostgreSQL contents, database backups, or storage media are exposed without the encryption keys.

Encryption at rest does not protect data while it is being used by a running Red Hat Edge Manager service, and does not defend against compromise of an authorized service that holds the key.

Backup archives contain both encryption keys and encrypted data. Protect backup archives with the same level of access control as production secrets.

Do not delete historical encryption keys until migration confirms that no persisted encrypted values depend on them. Historical keys can also be required to restore older backups.

How encryption works
Copy link

Red Hat Edge Manager uses AES-256-GCM authenticated encryption to protect sensitive fields in the PostgreSQL database. Each field value is encrypted individually at the application layer before it is written to the database. Decryption occurs at the API and service layer when a value needs to be consumed. This column-level approach ensures that sensitive data is protected even if an attacker gains direct access to the database storage. For the encrypted value format, see Encryption configuration reference in the Additional resources section.