Vai al contenuto principale

Secured Hadoop Migration: Kerberos, TLS, Ranger, Encryption

Classic migrates secured clusters in place. Kerberos identities, TLS certificates, Ranger policies, and HDFS encryption-zone keys are carried from the source to the target and placed under the management plane. Nothing is regenerated: principals keep their key versions, certificates keep their fingerprints, and every key version stays readable. Bifrost verifies each of these planes before and after the cutover, and it refuses a migration rather than silently dropping a security setting the target cannot express.

Kerberos​

  • Key distribution centers. MIT Kerberos and Active Directory are supported. The KDC type is read from the Cloudera Manager configuration during discovery.
  • Identities are preserved. The estate's own keytabs are copied to their places on the target. Ambari is configured not to manage identities, so no principal is created, no key is regenerated, and no KDC administrator credential is needed.
  • Key versions are recorded. Discovery records the key version number of every keytab, and the takeover places the keytabs that match it.
  • Client configuration. krb5.conf is kept byte for byte.

For discovery on a Kerberized source, a technical account with a keytab is used. See Getting started.

TLS and Corporate PKI​

  • Certificates are reused. The estate's own keystores and truststores, including certificates issued by a corporate PKI, are carried. Bifrost never reissues or re-encodes a certificate.
  • The truststore in use is measured. Bifrost selects the truststore that the source configuration actually references, not a file chosen by name.
  • Managed locations. TLS material is staged at locations that Bifrost manages on each host. No adopted configuration value points into the former Cloudera installation directory, and validate-post checks this for every PKI path.
  • Management plane. Ambari serves HTTPS with the estate's own certificate when the source cluster used TLS.
  • Renewal. Certificates are renewed after the migration with bifrost classic renew-certificates. See Day-2 operations: certificate renewal.

Ranger and Ranger KMS​

  • Databases in place. The Ranger and Ranger KMS databases are reused in place, not migrated.
  • Policy content parity. Ranger policies are compared before and after the cutover by content, not only by count: grants, denies, masking, row filters, tags, conditions, and security zones. A difference fails the comparison.
  • Plugins. The Ranger plugin of every service is installed and connected to Ranger Admin. bifrost classic ranger-plugin-trust gives a plugin trust in an HTTPS Ranger Admin and restarts it one host at a time.

HDFS Encryption Zones​

Discovery records every encryption zone and the versions and fingerprints of its keys. During the cutover, the kms-key-migrate step of bifrost classic migrate --execute proves every key version usable on the target before any data is touched:

  • Verification in place (default). The Ranger KMS is adopted on the same hosts, with the same database and the same keys. Every encryption zone is checked with a decryption probe on the target.
  • Key transfer. Con kms_migrate_mode: full, every key version is exported through the KMS REST API, re-created in order on the target, and then checked with the same decryption probe.
  • Finalize gate. bifrost classic finalize refuses until every encryption-zone key is proven decryptable on the target and the source key store has been captured.

A database-backed Ranger KMS is adopted directly. A Key Trustee KMS is moved to Ranger KMS before the migration window. A Ranger KMS backed by a hardware security module (HSM) is fully supported: the HSM client is installed on the target hosts, and custody of the keys is attested before finalize. Other external key stores are handled per engagement.

Sentry to Ranger​

On CDH 6 sources with Sentry, the sentry-migrate step of bifrost classic migrate --execute translates Sentry authorization into Ranger policies before the cutover:

  • Sentry roles and their groups become Ranger Hive policies.
  • URI grants become HDFS path policies.
  • A role without a group is reported, never granted to everyone.

The translated policies are written as a reviewable bundle. Importing them into Ranger is enabled with sentry_migrate_import: true.

Directory Authentication​

  • Bind credentials. LDAP and Active Directory bind passwords are delivered through the inventory vault and never appear in the adoption blueprint.
  • Verification. The directory connection of each service is verified after the takeover.
  • LDAPS trust. When a service needs the issuing CA of the directory server in its truststore, the import is performed only on request (ambari-takeover --directory-trust-import-ack) and can be reverted with --directory-trust-import-revert.
  • Management plane login. When Cloudera Manager authenticated its console users through LDAP, the Ambari console login uses the same directory settings.

Secrets Handling​

  • Operator secrets. Secrets supplied by the operator are stored as vault_* values in inventories/<cluster>/group_vars/all/vault.yml, encrypted with Ansible Vault.
  • Captured secrets. Credentials that discovery and the backup phase read from the source are stored in an encrypted vault file in the inventory (mode 0600, excluded from version control). Old copies are moved aside, and only finalize deletes them.
  • Vault password. The vault password file is inventories/<cluster>/.vault_pass (mode 0600) or the file named by BIFROST_VAULT_PASS_FILE.
  • No secrets on the command line. Passwords are read from environment variables or standard input, never from command arguments.
  • Clean reports. Plan validation masks secret values, and its PLAN-X checks report secrets that appear in plain text in the configuration. Support exports replace host names, realms, principals, and addresses with aliases.

Security Capability Gate​

Every security capability of the source (Kerberos, TLS, HDFS encryption zones, Ranger authorization, directory authentication) is checked against what the target can express. When the source uses a capability in a form the target cannot carry, validate-plan and the takeover refuse the migration instead of stripping the setting. Proceeding without that capability requires a dated acknowledgement in the inventory that names the capability, the reason, and who accepted it:

bifrost_secured_adopt_ack:
  - capability: directory_auth
    reason: "Console authentication of this service is handled outside the migration scope"
    acked_by: "[email protected]"
    expires: "2027-03-31"

An expired acknowledgement does not bypass the gate.

Passaggi successivi​

Last updated on