05 — Credential & Storage Boundary

Câu hỏi

Làm sao Databricks cấp được token/credential để user đọc storage đúng phạm vi, nhưng không để user bypass policy bằng token chung hoặc raw path?

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

Catalog policy chỉ có ý nghĩa nếu storage access cũng bị kiểm soát. Nếu user có thể lấy cluster IAM role hoặc Hadoop credential chung rồi đọc thẳng S3/ADLS/GCS, thì row/table permission ở catalog layer không còn đủ.

Với UC, câu hỏi không chỉ là “ai được SELECT table”, mà là:

SELECT table
  -> resolve table/path
  -> derive quyền path
  -> vend temporary credential
  -> bind credential vào filesystem operation
  -> chặn raw path/bypass path

Breakdown

1. UC derive quyền path từ quyền logical bằng gì?

Cần trả lời:

• UnityCatalogSAMDerivation hoạt động ở tầng nào?
• PathSAMAction đại diện cho quyền gì?
• PathPermissionProviderImpl trả lời path permission ra sao?
• Table/volume/external location/storage credential được nối thế nào?

2. Temporary credential được vend và cache thế nào?

Cần trả lời:

• UC credential vending call nằm ở client nào?
• Credential có scope theo path/securable/principal/session không?
• Cache credential tránh gọi UC liên tục như thế nào?
• Expiration/refresh diễn ra trước mỗi command hay mỗi filesystem access?

3. Filesystem wrapper enforce boundary ra sao?

Cần trả lời:

• CredentialScopeFileSystem khác CredentialPassthroughFileSystem và FixedCredentialsFileSystem thế nào?
• LokiFileSystem wrap những scheme nào?
• WorkspaceLocalFileSystem khiến file:// không còn là local thuần ra sao?
• UCVolumesFileSystem/PersonalStagingFileSystem nằm ở đâu?

4. Bypass bị chặn ở những tầng nào?

Cần trả lời:

• Hadoop fs.*.impl mapping chặn raw object-store access thế nào?
• hadoop-safety-jars shadow class Hadoop nào?
• FileSystemCallSiteAllowlist chặn local FS/raw FS ra sao?
• FUSE /dbfs, /Volumes, /Workspace có policy/credential forwarding thế nào?
• Python/Py4J/Spark Connect có chặn bypass JVM không?

Evidence trong snapshot

• Reverse docs:
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/18-storage-filesystem.md
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/19-credentials-passthrough.md
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/17-authz-acl.md
• Artifact/class/config:
  • UnityCatalogSAMDerivation
  • UnityCatalogSAMDerivationRule
  • PathSAMAction
  • PathPermissionProviderImpl
  • CredentialScopeFileSystem
  • CredentialScopeSQLHelper
  • SAMRegistry, UnitySAMRegistry
  • DBRUCSHandleWrapper
  • LokiFileSystem
  • WorkspaceLocalFileSystem
  • CredentialPassthroughFileSystem, FixedCredentialsFileSystem
  • UCVolumesFileSystem, UCVolumesFileSystemFactory
  • PersonalStagingFileSystem
  • spark/dbconf/hadoop/core-site.xml
  • hadoop-safety-jars/*
  • FileSystemCallSiteAllowlist

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

Databricks không để storage là một raw object-store path. Quyền logical từ UC/SAM được derive thành path permission, credential tạm được vend theo scope, rồi filesystem wrapper dùng credential đó khi access storage. Đồng thời DBR thay fs.*.impl, wrap local/cloud filesystem, dùng FUSE có credential forwarding, và prepend hadoop-safety-jars để chặn bypass qua class Hadoop gốc.

Còn thiếu / cần verify

• Cần đọc sâu credential vending client để biết scope/TTL/cache chính xác.
• Snapshot thiếu control plane UC service nên không thấy policy decision source đầy đủ.
• Cần phân biệt rõ path qua Spark SQL, Hadoop FS API, Python open(), shell/FUSE.