New authorization zone silently locks out the analytics group

The mechanism. A Ranger Authorization Zone is not an extra filter layered on top of the global policy tree - it replaces it for the resources inside the zone. Once a database path is inside a zone, only policies defined within that zone (or its child zones) are evaluated for those resources. Global policies that would have granted access are not consulted. So the analyst denial is not a regression in the tag-based policy; that policy is simply out of scope now.

This is also why the steward "changed nothing": creating the zone was itself the access change.

Confirmation from evidence:

• Ranger audit for a failing query: the zone field names raz_claims, and the policy evaluation shows no policy matched within the zone. If you had a denial caused by masking or a deny policy, the audit would name a matched policy instead - different problem, different fix.
• Timestamp correlation: denials begin at zone creation, not at a policy edit.
• Negative test: temporarily query a table in a database outside the zone with the same user. If that succeeds, the identity, group mapping and Kerberos path are healthy and the zone is the only variable.
• Verify FreeIPA group membership is still resolving as claims_analysts; if the group name or case differs, you would see no policy match for a second, independent reason.

Do not "fix" this by disabling the zone or granting broad access at the global level - global grants will not work inside the zone anyway, which is itself diagnostic.

The zone is the right governance model; the mistake was creating it without migrating the entitlements it displaced. Remediation is a migration of policy into the zone, done as one reviewed change set:

1. Recreate the tag-based rule inside raz_claims: tag PII, group claims_analysts, select on the claims database/table, with the same column-masking rules for member_ssn and diagnosis_code. Tag-based policies must exist in the zone's namespace to apply within it; the Atlas tags themselves do not need to change.
2. Add an explicit write policy for svc_etl in the zone: create/alter/write on the ingestion paths and the table location. Service accounts are the most commonly forgotten principal in a zone cut-over because they never appear in user-facing access requests.
3. Delegation: confirm the steward's group has zone-admin rights so they can add policies themselves, but keep the delegation scoped to raz_claims - not to global policy administration.
4. Cross-zone reality check: analysts who join claims to tables in another database now need policies in each zone involved. Enumerate the top queries from audit and make sure both sides are covered before announcing completion.
5. Validation with real personas: run queries as a non-privileged analyst account, a steward account and svc_etl, checking both success and that masked columns return masked values. A policy that grants access but drops masking is a data-protection incident, not a success.

Keep the global policies in place for now as documentation of intent, but note in the change record that inside the zone they are inert.

The failure was a process failure - an access-control boundary was introduced without an entitlement inventory. Fix the process, not just the policy:

• Zone migration checklist: before a path joins a zone, export the effective policies that currently apply to it (direct, tag-based, role-based), and map each to a zone-scoped equivalent. This includes service accounts, batch principals, and BI tools that authenticate via Knox.
• Prefer tag or role-based policy in the zone from day one so that future datasets tagged PII are covered automatically rather than requiring a new policy per table.
• Shadow period: apply the zone policies, then validate in the lower environment with test accounts for each persona, plus two named real queries per persona taken from audit history.
• Change record and comms: the steward owns the request; platform owns the cut-over; the analytics lead must know that access decisions for those paths now go through the zone. Publish who to ask.
• Deny-spike alerting: monitor Ranger audit for a step change in denials per policy/zone after any authorization change, and route it to the platform on-call. A 10x jump in denials is a deployment bug, not user error.
• Version the policies in source control with the zone definition, so a rebuild of the Data Lake can reapply them and a reviewer can see the diff.

The judgement to state explicitly: delegation without migration is not a grant of autonomy, it is an outage with a governance justification.