How to encrypt Apache NiFi data at rest when repository encryption is deprecated
A production NiFi holds data at rest in three places: the content repository, the FlowFile repository and the provenance repository. Those can contain regulated records, and the built-in repository encryption is deprecated, so protection at rest now depends mainly on encrypted storage volumes in your own infrastructure. Teams usually need this work when regulated data is in scope, when an auditor asks where NiFi data is stored and how it is protected, or when a recent platform review flags unencrypted disks. The sensitive properties key is a separate control. It protects sensitive property values in the flow definition, not the data moving through the repositories, so it cannot stand in for volume encryption.
Start by listing every directory the repositories write to, including the nifi.content.repository.directory and nifi.provenance.repository.directory entries in nifi.properties, the FlowFile repository location, and any temporary or log paths that may hold record content. Then choose the encryption layer for each. Common options are Linux block encryption such as LUKS, encrypted disks provided by your cloud platform with keys you manage, hypervisor-level encryption, or an encrypted storage class for Kubernetes persistent volumes. Confirm with your vendor or platform team how each option handles key custody, unlocking after a reboot and performance under NiFi's write load. Also confirm whether backups and snapshots of these volumes inherit the same protection.
Auditors will look for evidence, not intent. Keep a record that maps each repository path to its encrypted volume, the key owner and the key rotation procedure, along with the unlock method used after a host restart. Test a restore from an encrypted backup and keep the result. Export the relevant parts of your NiFi configuration and store them under change control, so the encryption settings are traceable over time. Before you start, ask the auditor which evidence they expect, since their requirements decide how much detail the record needs. The NiFi System Administrator's Guide is the reference for the repository properties you will document.
Which volume encryption option fits your NiFi hosts
This table compares ways to encrypt the content, FlowFile and provenance repository directories, which the NiFi administration guide places under directory settings in nifi.properties. Check each option against the directories on your hosts, then read across to see who holds the keys and what your team must operate. The main takeaway is that volume encryption protects stored data but not a running, unlocked NiFi host.
| Option | Best fit | What it protects | Who holds keys and what operations runs |
|---|---|---|---|
| OS full-disk or volume encryption | Bare metal or self-run VMs where you control the Linux host | Repository volumes and backups at rest, including lost or stolen disks | Host operators hold the unlock secret. Run boot-time unlock, key escrow and recovery drills. |
| Encrypted cloud block storage | NiFi on cloud VMs in accounts you own | Volumes and their snapshots at the provider storage layer | Provider-managed keys by default, or customer-managed keys. Confirm key type, snapshot inheritance and who can use the key. |
| Hypervisor or array-level encryption | On-premises virtualization or SAN storage run by a separate storage team | Virtual disks or LUNs, including replicas if the array encrypts them | Storage or virtualization admins hold keys through a KMS. Confirm whether guests and backups are covered and who sees the keys. |
| Self-managed KMS or HSM-backed keys | Regulated environments that need key custody separate from host administrators | Key material separated from data, supporting key rotation and access logging | Security team runs the KMS or HSM. Plan for an unreachable KMS at boot, rotation runbooks and high availability. |
| Flow-level encryption with PGP or age processors | Files leaving NiFi for partners, archives or downstream stores | Individual content files as they are produced by the flow | Key services hold recipient keys. This does not encrypt repository directories, so pair it with one of the rows above. |
| nifi.sensitive.props.key | Every NiFi deployment that stores sensitive property values | Sensitive values in flow configuration, such as passwords and credentials | Set in the NiFi configuration and matched across nodes. It does not encrypt repository content or provenance data. |
What the sensitive properties key protects and what it does not
The nifi.sensitive.props.key value protects sensitive property values stored in NiFi configuration and flow definitions, such as passwords, tokens and keys entered into processors and controller services. NiFi encrypts those values before writing them to the flow definition, so a copied flow.json.gz does not expose them in plain text when the key is absent. The key does not encrypt the data moving through the content, FlowFile and provenance repositories. FlowFile content, attributes and provenance events sit on disk in the form the flow produced them, so a reader of the raw volume can see what the flow processed unless the storage underneath is encrypted. Treat the key as a control for configuration secrets, not for the data NiFi handles.
For auditors, this distinction changes what evidence you produce. The key does not replace storage encryption, and an auditor testing data at rest will ask about the volumes that hold the repositories, not only the key. Every node in a cluster must use the same key value, because each node has to decrypt the sensitive values in the shared flow definition. A mismatched key on one node leaves that node unable to load the flow correctly. Record where the key is stored, who can read it, and how changes to it are approved and tested before any rotation. Ask your NiFi team to confirm the exact behavior, including which properties are covered and how the key is handled in exported flows and parameter values, in the NiFi System Administrator's Guide and in a test export from your own environment.
Setting up encrypted repositories for a NiFi node
This sequence moves a NiFi node's flowfile, content, provenance and log storage onto encrypted volumes before NiFi runs against them, then confirms the node processes data and that its sensitive properties key matches the rest of the cluster. The output is a verified node and a configuration record an auditor can follow.
Inventory repository and log paths
The operations engineer on each node lists every storage path NiFi writes to. Open conf/nifi.properties and record the values of nifi.flowfile.repository.directory, every nifi.content.repository.directory.* entry, nifi.provenance.repository.directory.* and nifi.database.directory, then note where conf/logback.xml writes logs. For each path, run df on the directory to identify the backing filesystem and device. Done means you have a per-node table of path, device and filesystem, with no path left unassigned.
Choose the encryption layer
The architect and security lead select how the volumes will be encrypted. Because NiFi's built-in repository encryption is deprecated, the usual choice is block-level encryption beneath the filesystem, such as LUKS with dm-crypt on Linux or encrypted block storage from your cloud or SAN platform. Record who holds the keys, where key material is escrowed, how unlocking works after a reboot, and whether the log directory is covered too. Done means a signed decision record exists for each node class. Confirm the approach with your platform team and against the NiFi release you run.
Create encrypted volumes before startup
With NiFi stopped on the node, the platform engineer creates the encrypted volumes, formats them and adds mount entries so they mount at boot, including any unlock configuration such as crypttab. Confirm that no NiFi process holds files open in the old directories. Check the result with lsblk and mount, which should show the encrypted mapping, the target mount points and the expected filesystem type. Write a test file to each new mount and remove it. Done means every mount is present after a reboot test on a non-production node.
Move repositories onto the encrypted volumes
With NiFi still stopped, the engineer copies each repository and log directory to its new mount, preserving ownership, permissions and timestamps, then updates the matching keys in conf/nifi.properties and any logging paths in conf/logback.xml. Confirm the directories are owned by the account that runs NiFi. Compare file counts and checksums between the old and new locations, then keep the old copies until the node is verified. Done means the new paths in the configuration match the mounts, and the copy comparison shows no differences.
Confirm NiFi starts and processes data
The engineer starts the node and watches the application log for repository, permission or provenance errors during startup. Then they build a small test flow with GenerateFlowFile connected to LogAttribute, run it briefly, and confirm FlowFiles pass through. Run a provenance query for the test component to confirm events are written to the new provenance location. Done means the node starts cleanly, the test flow completes and the provenance query returns the events. Repeat the check against the release you run, since startup messages differ between versions.
Verify the sensitive properties key on every node
The security engineer confirms that nifi.sensitive.props.key is set in conf/nifi.properties on every node and that the value is identical across the cluster. Do not print the key in tickets or logs. Instead, compute a SHA-256 hash of the value on each node and compare the hashes. Note that this key protects sensitive component properties and parameter values, and it does not encrypt repository content, so volume encryption remains a separate control. Done means the hashes match on all nodes and the key is recorded in your secrets store. Confirm the key handling steps against the administration guide for your release.
Record the configuration for audit
The operations lead writes a configuration record for each node covering the encryption layer, device identifiers, mount points, unlock method, key escrow location, NiFi repository paths, the sensitive key fingerprint and the NiFi version. Attach the output of the earlier checks, including the mount listing, the test flow result and the hash comparison. Store the record under change management with the date and the name of the person who verified it. Done means an auditor could trace each repository from its mount to its key custody and verification evidence. Check the record against the running configuration before closing the change.
Security and operational risks to plan for
Encryption at rest protects repository files only as far as the keys, copies and side paths around them are controlled. The cards below cover the places where NiFi data tends to leave the encrypted layer, and name the control and the team that should own each one.
Volume key custody and rotation
The disk encryption keys for the content, FlowFile and provenance volumes sit in your key management system, not in NiFi. Decide who can create, rotate and revoke those keys, and how a rotation is run across every node without stopping the cluster. Owner: the platform or infrastructure team, with the security team approving the key policy. Check that rotation is tested on a non-production cluster before it is run in production.
Key access after a host rebuild
A rebuilt or replaced node may not be able to unlock its encrypted volumes if the key reference or unlock method was stored only on the old host. Record where each volume's key comes from, who can release it, and how a node is unlocked after a reboot without manual steps. Owner: the platform team, with a documented break-glass procedure signed off by the security owner. Rehearse a node rebuild at least once before go-live.
Unencrypted copies in backups and snapshots
Volume-level encryption protects the live disk, but backup jobs and storage snapshots can write content or provenance data to targets that do not inherit the same protection. Confirm that every backup target and snapshot store is encrypted with keys under your control, and that restores do not write decrypted data to unmanaged locations. Owner: the backup or storage team. Ask for a restore test that shows where decrypted data lands.
Sensitive values in provenance records
Provenance events record FlowFile attributes and content references, so a sensitive value copied into an attribute can persist in the provenance repository long after the flow has finished with it. Encrypting that volume does not limit who can read the attribute once a user has provenance access. Owner: the flow designers, with the data owner setting which attributes may be recorded. Review attribute usage in high-risk flows before enabling wide provenance access.
Swap and temporary files outside encrypted paths
The JVM, the operating system and some processors can write working data to swap space or temporary directories that sit on unencrypted disks. Those copies are outside the repository encryption boundary even when the NiFi volumes are protected. Owner: the operating system team. Confirm that swap is encrypted or disabled on NiFi hosts, and that temporary directories used by processors point to encrypted storage.
Disk-full events on encrypted volumes
When a repository volume fills, NiFi slows or stops ingesting data, and recovery work such as clearing queues or extending a volume must be done on encrypted storage without exposing the data. Plan how an encrypted volume is expanded, which alerts fire before it is full, and who approves emergency cleanup of provenance or content. Owner: the operations team, with the security owner approving any deletion that affects audit evidence. Test an expansion on the encrypted volume before an incident needs it.
What evidence auditors will ask you to produce
Auditors will not accept a statement that repository data is encrypted. They will ask for records that show which volumes hold the NiFi content, FlowFile and provenance repositories, how those volumes were encrypted, who can manage the keys, and that the configuration has stayed in that state. The core set is the volume configuration records (the encryption method, key custody model and the mount points that match the repository paths in nifi.properties), the host build standard that makes new nodes encrypted by default, and the key management policy with the access logs that show who opened or used the keys. Because NiFi repository encryption is deprecated, the NiFi configuration itself is evidence too: export the nifi.content.repository.directory.default, nifi.flowfile.repository.directory and nifi.provenance.repository.directory.default values from each node and keep them alongside the volume records, so an auditor can trace each path to an encrypted device.
Auditors will also test maintenance. Keep change records for every key rotation, volume re-encryption, host rebuild and restore, with the approver, the date, the affected nodes and the verification result. Backup encryption records belong in the same set, covering the backup target, its encryption setting and the key location, plus a restore test that proves backups are readable only with the authorized key. Do not confuse these records with the nifi.sensitive.props.key evidence. That key protects sensitive property values inside flow definitions, not the repository files on disk, so an auditor who sees only a sensitive properties key record will ask about the volumes. Confirm the scope of each control with your audit team before collection starts.
DeployOpen prepares these systems, configuration baselines, runbooks and evidence records, and can run a gap review against the records you will need. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors decide what is sufficient for your framework, sampling and retention period, so ask them to name the specific artifacts, the date range and the format they will accept before you build the evidence pack. The same evidence should be reviewed against the NiFi administration guide at Apache NiFi System Administrator's Guide for the current property names in your NiFi version.
Limits to confirm in your environment
Encryption at rest for NiFi depends on the release you run, the storage layer under it, and where data goes after it leaves a processor. Each card below is a check to close before you sign off on the design, with a pointer to where the answer lives.
NiFi version and repository settings
Confirm the exact NiFi release in each environment, including the 1.x and 2.x split, before relying on any repository encryption setting. Repository encryption is deprecated in NiFi, so the version determines which options you can use and how long your current line will receive fixes. Check the release notes and deprecation notices for your version, then confirm the repository properties in nifi.properties still behave as you expect on that release.
Encryption options on your platform
Ask your hypervisor, storage or cloud team which volume encryption features apply to the disks that hold the content, FlowFile and provenance repositories. Confirm whether keys are held by the platform, by your key management service or by you, who can rotate them, and whether snapshots, backups and replicas inherit the same protection. The answer belongs in the vendor documentation for that encrypted storage product, not in NiFi settings.
Java and operating system versions
Record the Java runtime and operating system build on every node, since both affect which disk encryption modules and cipher suites are available. The NiFi administration guide lists Java 21 as the minimum runtime, so confirm your build meets it. Keep the versions in your configuration inventory so an auditor can match the evidence to the nodes that ran during the test period.
Copies of data outside NiFi
Trace where FlowFile content and provenance details end up after processing. Provenance events can carry attributes and content references, and flows often send copies to object storage, databases, SIEM platforms or email. Each downstream system needs its own at-rest controls, so list every destination and confirm its encryption status with the team that owns it. Data that leaves NiFi unencrypted is outside what volume encryption protects.
Sensitive properties key coverage
Confirm what nifi.sensitive.props.key protects in your flows. It encrypts sensitive property values stored in the flow definition and parameter values marked sensitive, but it does not encrypt repository files or provenance records. Review each flow and parameter context to find where secrets are stored, then test that a restored or copied configuration decrypts only with the keys your nodes hold. The NiFi administration guide describes the property and its behavior.
Vendor documentation for storage products
For any encrypted storage product in the design, such as a self-encrypting drive, a managed disk service or a file-level encryption tool, obtain its own documentation and confirm the supported configurations, key recovery steps and performance limits. Ask the vendor whether the product is supported under your NiFi workload, since repository I/O patterns differ from typical file servers. Keep the vendor's support statement with your design evidence.
Questions teams ask before encrypting NiFi data at rest
What drives the cost of encrypting NiFi data at rest?
Cost follows the size and layout of your NiFi estate. The main drivers are the number of nodes, the volumes that hold the content, FlowFile and provenance repositories, whether your platform already offers volume encryption, the mix of on-premises, cloud and air-gapped hosts, and how many environments need the same change, including test and disaster recovery. Costs fall into one-time work (assessment, configuration, validation and runbooks) and recurring work (key custody, rotation and periodic re-verification). When you request a quote, ask for these lines to be shown separately, confirm which environments are covered, and state who holds the keys after handover.
How long does encrypting NiFi repositories take?
Duration depends on the number of nodes, the volume layout and how many change windows your team can offer. Work usually runs in stages: an inventory of repositories and volumes, a change in a non-production cluster, then production nodes one at a time with validation after each step. Nodes must be restarted in a controlled sequence, so tight windows lengthen the schedule. Migrating large content and provenance repositories to new encrypted volumes adds time as well. No duration is given here because it depends on your environment. Ask the proposal to list each stage, the downtime expected per node, the rollback plan and the dates your team must provide.
What does our team need to provide for this work?
Your team needs to provide access and decisions that only your organization can make. Typically that means:
- Access to the NiFi hosts and a non-production cluster that matches production as closely as possible
- Storage administrator access to create, attach and resize encrypted volumes, or the cloud or platform admin rights to do so
- A key custody decision covering who generates, stores, backs up and rotates the encryption keys
- Approved change windows for each node, plus a named owner who can approve rollback
- Current backups and a restore test, so the team can recover if a volume change fails
Ask the proposal to confirm which of these items it assumes you will supply.
Can our internal team encrypt NiFi data at rest alone?
Yes, if your team has NiFi administration skills, storage administration rights and the time to run staged changes with rollback. The technical steps are not unusual, but the risk sits in sequencing: a wrong volume mount, a missed node or an unrecorded key can stop a cluster from starting. Many teams keep the work in-house and bring in outside help only for planning, peer review or evidence preparation. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, so it can carry out the work or support your team alone. Decide which approach fits your skills before the change windows are booked.
Does encryption at rest alone satisfy an audit?
No. Encryption at rest is one control among several that auditors examine. They usually test the scope of encrypted data, how keys are created, stored, rotated and restricted, who can access the hosts and volumes, whether changes are logged and approved, and whether the configuration stays in place over time. Evidence must show the control operating, not only that it was once enabled. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early which framework and evidence format your auditor expects.
Does the sensitive properties key encrypt repository content?
No. The sensitive properties key, set through nifi.sensitive.props.key, protects sensitive values stored in NiFi configuration, such as passwords and secrets on components and controller services. It does not encrypt the content, FlowFile or provenance repositories on disk, so it cannot replace volume-level encryption. The two controls answer different questions, and both need their own key handling. The key must also match across cluster nodes, and losing it can make protected values unreadable. Review the NiFi administration guide for the exact behavior in your version before you plan key custody.
How DeployOpen scopes and delivers NiFi encryption at rest
DeployOpen approaches encryption at rest for Apache NiFi as a scoped engineering task, not a single setting. We map where content, FlowFile and provenance data sit on your infrastructure, then build and document the controls that protect each repository and the sensitive properties key.
How we scope
- We inventory the content, FlowFile and provenance repository locations on each NiFi node and the storage they sit on.
- We record which volume encryption option your infrastructure team will use, and who owns key custody and rotation.
- The written scope lists what is in and out, including the sensitive properties key and exported flow definitions.
How we build
- We configure encrypted volumes or storage-layer encryption for each repository path on your nodes, in your environment.
- We set and verify the sensitive properties key consistently across every cluster node before any flow runs.
- We test restarts, node replacement and a repository recovery to confirm data stays readable only through approved keys.
How we hand over
- You receive a configuration record covering each repository path, its encryption method, key owner and rotation procedure.
- You receive runbooks for key rotation, disk replacement and restore, written for your operations team to run.
- You receive an evidence pack of settings, test results and change records that your auditors can review independently.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and re-testing after NiFi or storage changes are available as a retainer.
- Quotes follow from the written scope, so ask for line items covering each repository, key handling and documentation.
