06 — Runtime Config & SAFER
Databricks kiểm soát Spark/Hadoop/runtime config để user không phá managed boundary như thế nào.
Câu hỏi
Databricks ngăn user sửa config để phá runtime/security boundary bằng cách nào?
Ví dụ: nếu user có thể override SparkConf/HadoopConf để đổi catalog, tắt ACL, đổi filesystem impl, tắt telemetry, hoặc trỏ endpoint sang nơi khác, thì managed runtime mất kiểm soát.
Breakdown
- Config nào thuộc process, allocation, session?
- Config đến từ source nào: settings, flag, platform, customer?
- Config nào user được override?
- Config nào bị pinned/ký số?
- Khi có pinned config bypass thì log/event gì ghi lại?
- Dynamic config được load trước hay sau
DRIVER_ASSIGNED?
Evidence trong snapshot
/Users/chimeyrock/ChimeyRock/databricks/reverse/docs/03-config-va-classpath.md/Users/chimeyrock/ChimeyRock/databricks/reverse/docs/14-driverdaemon.md§SAFERdriver/conf/dynamicSparkConfig.conf.jsonConfigCategoryConfigSourceSaferConfUtilSaferPinnedConfigBypassEventSAFER_PRE_ALLOCATION_INIT_*SAFER_POST_ALLOCATION_INIT_*
Câu trả lời tạm thời
SAFER nên được đọc như config governance, không phải security framework chung. Databricks phân loại config theo scope/source, load một phần trước allocation và một phần sau khi driver được assign, đồng thời có event cho pinned config bypass/invalid signature. Đây là cách runtime giữ những config quan trọng nằm trong quyền kiểm soát platform.
Còn thiếu / cần verify
- Cần list cụ thể config nào security-sensitive và pinned.
- Cần trace exact path từ dynamic config vào SparkConf/HadoopConf.