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 Ranger KMS / 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.
dmcrypt
for 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.
"ALLOW @mydata * /usr/bin/myapp"
This rule
allows the /usr/bin/myapp
process to access any
encrypted path (*
) that was encrypted under the
category @mydata
.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 navencryptfs.ko
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
(ext3
, ext4
, xfs
, and so on).
The following diagram shows /usr/bin/myapp
sending an
open()
call that is intercepted by
navencrypt-kernel-module
as an open
hook:
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 navencrypt-kernel-module
cache
after restarting the kernel module.
The /mydata
directory is encrypted under the @mydata
category and
/mylogs
is encrypted under the
@mylogs
category using dmcrypt
(block device encryption).
When myapp
tries to
issue I/O to an encrypted directory, the kernel module calculates the
fingerprint of the process (/usr/bin/myapp
) and
compares it with the list of authorized fingerprints in the
cache.
Encryption Key Storage and Management with Ranger KMS
The master key and mount encryption keys are securely deposited in Ranger KMS. 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 Ranger KMS can be secured with TLS/SSL certificates, it is recommended that TLS/SSL is used.
The master key is encrypted by Navigator Encrypt using a local GPG key and stored in the Ranger KMS database. When the master key is needed to perform a Navigator Encrypt operation, Navigator Encrypt fetches the key from Ranger KMS and decrypts the key using the local GPG key.
For details about how to generate Kerberos keytab file, see Generating Kerberos keytab file for Navigator Encrypt.
Encryption Key Storage and Management with Key Trustee Server
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.