Cloudera Navigator Encrypt Overview
Cloudera Navigator Encrypt transparently encrypts and secures data at rest without requiring changes to your applications, and ensures minimal performance lag in the encryption or decryption process. Advanced key management with Cloudera Navigator Key Trustee Server and process-based access controls in Navigator Encrypt enable organizations to meet compliance regulations and prevent unauthorized parties or malicious actors from gaining access to encrypted data.
dmcryptfor its underlying cryptographic operations. Navigator Encrypt uses several different encryption keys:
Process-Based Access Control List
The access control list (ACL) controls access to specified data. The ACL uses a process fingerprint, which is the SHA256 hash of the process binary, for authentication. You can create rules to allow a process to access specific files or directories. The ACL file is encrypted with the client master key and stored locally for quick access and updates.
This rule allows the
"ALLOW @mydata * /usr/bin/myapp"
/usr/bin/myappprocess to access any encrypted path (
*) that was encrypted under the category
Navigator Encrypt uses a kernel module that intercepts any input/output (I/O) sent to an
encrypted and managed path. The Linux module file name is
and it resides in the kernel stack, injecting file system hooks. It also authenticates and
authorizes processes and caches authentication results for increased performance.
Because the kernel module intercepts and does not modify I/O, it supports any file system
xfs, and so on).
The following diagram shows
/usr/bin/myapp sending an
open() call that is intercepted by
navencrypt-kernel-module as an
The kernel module calculates the process fingerprint. If the authentication cache already has the fingerprint, the process is allowed to access the data. If the fingerprint is not in the cache, the fingerprint is checked against the ACL. If the ACL grants access, the fingerprint is added to the authentication cache, and the process is permitted to access the data.
When you add an ACL rule, you are prompted for the master key. If the rule is
accepted, the ACL rules file is updated as well as the
navencrypt-kernel-module ACL cache.
The next diagram illustrates different aspects of Navigator Encrypt:
The user adds a rule to allow
/usr/bin/myapp to access the
encrypted data in the category
@mylogs, and adds
another rule to allow
/usr/bin/myapp to access
encrypted data in the category
@mydata. These two rules
are loaded into the
after restarting the kernel module.
directory is encrypted under the
@mydata category and
/mylogs is encrypted under the
@mylogs category using
(block device encryption).
myapp tries to
issue I/O to an encrypted directory, the kernel module calculates the
fingerprint of the process (
compares it with the list of authorized fingerprints in the
Encryption Key Storage and Management
The master key and mount encryption keys are securely deposited in Key Trustee Server. One MEK per mount point is stored locally for offline recovery and rapid access. The locally-stored MEKs are encrypted with the master key.
The connection between Navigator Encrypt and Key Trustee Server is secured with TLS/SSL certificates.
The following diagram demonstrates the communication process between Navigator Encrypt and Key Trustee Server:
The master key is encrypted with a local GPG key. Before being stored in the Key Trustee Server database, it is encrypted again with the Key Trustee Server GPG key. When the master key is needed to perform a Navigator Encrypt operation, Key Trustee Server decrypts the stored key with its server GPG key and sends it back to the client (in this case, Navigator Encrypt), which decrypts the deposit with the local GPG key.
All communication occurs over TLS-encrypted connections.