Tag-Based Access Control After a Cross-Cluster Failover
A financial group runs two CDP Private Cloud Base clusters: production in Frankfurt and disaster recovery in Dublin. Replication Manager copies HDFS data and Hive metadata every six hours. Atlas in production tags 4,200 columns as PII, and Ranger uses tag-based policies so only the fraud analytics group can read them. After a failover test, analysts in Dublin could read the replicated tables, but the fraud group received access denied on the same PII columns, while a contractor group unexpectedly could read three of them. Ranger policies were exported and imported before the test, and the tag service name is identical. The next failover must be completed within a 30-minute RTO, and the regulator requires evidence that access controls are identical in both clusters.
1. Explain why the same imported Ranger policies produced different access outcomes in Dublin.
Read the worked answer
Ranger policy import moves policy definitions, not the metadata those policies depend on. A tag-based policy is evaluated by matching a resource's tags as known to Ranger's tag service. If the Dublin Atlas instance does not hold the same tag associations for the replicated columns, the PII policy simply does not match, and access falls through to whatever else applies.
That explains both observations. The fraud group is denied because the expected PII tag is absent or attached to a different column entity, so the allow condition never fires. The contractor group can read three columns because some other policy-perhaps a default, a resource-based policy, or a broader group policy-applies when the PII tag is missing. The identical tag service name is not sufficient; the tag definitions, tag-to-resource mappings, and the tag sync path must also match.
Hive metadata replication alone does not carry Atlas classifications. Unless Atlas metadata or tag synchronization is explicitly replicated, Dublin has tables and columns but no PII knowledge. The correct diagnosis is missing tag provenance, not a broken Ranger import.
2. Design the replication and control-plane changes needed to meet a 30-minute RTO with equivalent access control.
Read the worked answer
Access control must be replicated continuously, not reconstructed during failover. A 30-minute RTO leaves no time to discover missing tags or reconcile policies by hand.
Use Replication Manager to replicate Hive metadata and Atlas metadata, including classifications and tag associations, on a schedule that keeps Dublin within an acceptable lag. Configure Ranger tag synchronization in Dublin to consume the replicated Atlas tags, and verify that the tag service and tag names resolve identically. Treat Ranger policies as versioned code: export from production, store in version control, deploy to Dublin through the same pipeline, and diff the effective policy set after every change.
Order matters during failover: confirm Hive tables, then Atlas tag associations, then Ranger policy deployment, then run access tests. Pre-stage everything except the final routing switch.
Add an automated equivalence check that compares tag counts per table and effective permissions for representative users and groups across both clusters. The design goal is that Dublin is a running replica of the control plane, not a blank cluster that receives policies at the last minute.
3. What evidence would satisfy the regulator, and how would you handle emergency access without breaking equivalence?
Read the worked answer
Regulatory evidence should show that access decisions in Dublin are derived from the same classification and policy inputs as production, and that this was tested rather than asserted.
Provide: Atlas tag counts and a sample of tag-to-column mappings in both clusters; a diff report of Ranger policies and tag-based policy evaluations; Ranger audit records for the test users; and results of an automated access matrix covering the fraud group, analysts, contractors, and a negative-control user. Include timestamps showing replication lag stayed within the RTO assumption. A screenshot of imported policies is weak evidence; an executed access test with expected allow and deny outcomes is strong.
For emergency access, use a time-bound break-glass policy with named approval, a defined scope, automatic expiry, and full audit. Do not create a broad exception that survives failover, because that is how the contractor group likely obtained access in the test. Record each break-glass use and review it after the event.
The regulator's real question is whether the DR cluster can enforce the same controls under stress. Evidence should therefore include a failed-node or failed-policy scenario, not only a happy-path failover.