HDFS的数据访问控制，其实是一整套环环相扣的安全机制。从你第一次敲下命令，到数据真正落盘，中间要经过身份验证、权限授权、操作审计、传输加密、存储加密等多个关卡。简单说，就是确保只有“对的人”用“对的方式”才能碰到数据。
1. 身份验证：先搞清楚你是谁
这一步是所有控制的基础。HDFS用的是Kerberos认证——一种基于“票据”的强身份校验协议。流程其实很直白：你先向KDC（密钥分发中心）申请一张TGT（票据授权票据），然后用这张TGT去换取访问HDFS的Service Ticket。NameNode拿到Service Ticket后会验证它的合法性，只有通过了，你才能真正发起操作。简单说，Kerberos堵死了“冒充合法用户”这条路。
2. 授权管理：你能碰哪些东西
确认身份之后，接下来就是权限分配。HDFS提供了两套方案，覆盖不同精细度的需求：
- 传统POSIX权限模型：每个文件或者目录都有三个核心属性——所有者（owner）、所属组（group）、其他用户（others），分别对应读（r）、写（w）、执行（x）权限。比如，对目录有“r”才能列出内容，“w”才能创建/删除子项，“x”才能进入子目录。日常管理靠
hdfs dfs -chmod（改权限）、chown（改所有者）、chgrp（改所属组）几个命令就够了。 - ACL（访问控制列表）：传统模型有个明显的短板——没法给某个特定用户或组单独授权。ACL就是来补这个缺的。它由多个条目组成：用户条目（
user:username:permissions，比如给alice读写执行权限）、组条目（group:groupname:permissions，比如给dev组读执行权限）、掩码条目（mask::permissions，限制组和其他用户的最大权限）、其他条目（other::permissions，兜底）。操作命令是hdfs dfs -setfacl和getfacl。举个例子，给用户bob在/data目录下添加读写权限：hdfs dfs -setfacl -m user:bob:rw- /data。
3. 权限检查：NameNode来当裁判
任何操作——读、写、删除——最终都要经过NameNode的权限检查。NameNode根据请求用户的身份（Kerberos认证结果）和文件/目录的权限设置（传统模型或ACL）来判定是否放行。规则很清晰：超级用户（默认是启动NameNode的那个用户，比如hdfs）直接绕过所有检查，拥有完全控制权；如果用户是文件的所有者，就查所有者权限；如果用户属于文件的所属组，就检查组权限；否则，查其他用户权限。这一关贯穿整个操作流程，谁也别想绕过去。
4. 审计日志：每一步都有据可查
权限查完了，还得留下痕迹。HDFS的审计日志会记录所有用户的操作行为，方便事后排查问题。日志里包含了用户身份、操作类型（read/write/delete）、操作时间、目标路径等关键信息。通过配置dfs.namenode.audit.log.dir（审计日志目录）和dfs.namenode.audit.log.maxsize（单个日志文件大小）就能开启和管理。比如，把日志存到/var/log/hdfs/audit，单个文件上限10MB。
5. 传输与存储加密：数据在哪儿都不能裸奔
- 传输层加密：客户端和HDFS之间的通信（包括NameNode与DataNode的数据传输、客户端与NameNode的指令交互）都通过SSL/TLS协议加密，防止数据在网络中被截获或篡改。开启方式很简单，配置
dfs.ssl.enabled和dfs.ssl.keystore.location（证书路径）等参数即可。 - 存储层加密：数据落盘时自动加密，读取时自动解密，整个过程对应用透明——你不需要改一行代码。Hadoop的透明加密（Transparent Encryption）就是干这个的。关键配置项包括
hadoop.crypto.key.provider.uri（密钥提供者路径）和dfs.encrypt.data.transfer（是否启用数据传输加密）。
6. 辅助安全措施：多几道锁总没坏处
- 网络隔离：通过防火墙（iptables、firewalld）或VLAN划分，限制对NameNode的8020端口、DataNode的50010端口等关键端口的访问，只允许受信任的IP连接过来。
- 安全模式：HDFS启动时会先进入安全模式，此时只允许读操作，禁止写、修改、删除。等到数据块副本数量达到设定阈值（默认3份）后才会退出，确保数据一致性。
- SELinux/AppArmor：利用Linux安全模块，比如把SELinux设为Enforcing模式，就能限制HDFS进程的权限，防止它越权访问系统文件或其他敏感资源。
