04 — AuthZ & FGAC

Câu hỏi

Khi user query một table, Databricks biết cho phép/từ chối/rewrite query ở đâu?

Đây là câu hỏi tương đương “HMS + Ranger” trong open-source stack, nhưng không nên ép Databricks vào đúng mô hình đó.

Vì sao câu này quan trọng

Nếu authZ chỉ nằm ở UI/API, user có thể bypass bằng Spark API khác. Nếu authZ chỉ nằm ở catalog, user có thể bypass bằng raw storage path. Nếu authZ chỉ nằm ở storage IAM, platform mất ngữ nghĩa table/schema/row/column policy.

Với managed runtime, enforcement point phải nằm trên execution path mà mọi query bắt buộc đi qua.

Breakdown

1. Table/catalog metadata được resolve qua path nào?

Cần trả lời:

• Spark SessionCatalog bị thay/bọc như thế nào?
• ManagedCatalogSessionCatalog route giữa UC/Internal HMS/Glue/Federation ra sao?
• UnityCatalogV2Proxy nằm ở V2 catalog path nào?
• UC-only cluster có disable ExternalCatalog cũ không?

2. Permission check nằm ở analyzer, catalog, hay storage?

Cần trả lời:

• CheckPermissions được inject vào Spark analyzer bằng cách nào?
• PermissionChecker resolve securable/action/principal ra sao?
• HiveCheckPermissions khác CheckPermissions thế nào?
• PermissionEnforcingManagedCatalog enforce quyền ở catalog operation nào?
• CheckFileSystemSafety/CheckFilePermissions nối sang filesystem thế nào?

3. FGAC row filter / column mask được rewrite như thế nào?

Cần trả lời:

• Row filter/column mask được lưu dưới metadata object nào?
• Analyzer rule nào resolve và validate policy?
• AlterTableSetRowFilterCommand / AlterColumnSetColumnMaskCommand update metadata ở đâu?
• ABAC policy parameter được bind vào expression ra sao?
• current_user()/user info được inline vào expression bằng gì?

4. User/group/principal/permission model nằm ở đâu?

Cần trả lời:

• GrantPermission, DenyPermission, RevokePermission có semantics gì?
• Principal/group lấy từ SCIM hay UC?
• Securable gồm những loại nào: table, function, any file, volume, external location, storage credential, connection?
• Deny có ưu tiên hơn grant không?

Evidence trong snapshot

• Reverse docs:
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/17-authz-acl.md
• Artifact/class/config:
  • ManagedCatalogSessionCatalog
  • ManagedCatalogSessionCatalog$UnityCatalog
  • ManagedCatalogSessionCatalog$InternalHMS
  • ManagedCatalogSessionCatalog$Glue
  • UnityCatalogV2Proxy
  • UnityCatalogDSV2Interface
  • SecuredExternalCatalog
  • DisabledExternalCatalog
  • CheckPermissions
  • HiveCheckPermissions
  • PermissionChecker
  • PermissionEnforcingManagedCatalog
  • ResolveRowColumnAccessControls
  • ResolveAndValidateRowColumnAccessControlsChanges
  • RowFilter, ColumnMask, RowColumnAccess
  • AlterTableSetRowFilterCommand
  • AlterColumnSetColumnMaskCommand
  • InlineUserInfoExpressions
  • SecurableIdentifier, ActionIdentifier, Permission, Principal
  • spark.databricks.sql.rowColumnAccess.*

Câu trả lời tạm thời

DBR không giống mô hình “Spark gọi HMS lấy metadata rồi Ranger plugin hỏi policy” một cách trực tiếp. Snapshot gợi ý Databricks thay bằng catalog/security layer native: ManagedCatalogSessionCatalog resolve metadata/securable, PermissionEnforcingManagedCatalog và Spark analyzer rules check quyền, còn row filter/column mask được resolve/rewrite trong logical plan path. UC vì vậy không chỉ là metastore; nó là metadata + policy/FGAC model gắn vào Spark execution path.

Còn thiếu / cần verify

• Cần decompile/javap sâu hơn để biết exact rule ordering.
• Chưa thấy body expression rewrite của row filter/column mask.
• Snapshot không có control plane UC service, nên policy storage/source of truth chỉ infer qua client/proto/cache.