设计初衷
对于企业级的应用而言，认证与鉴权可以说是一个基础需求：
- 尽管Hadoop集群大多部署在企业内部私有网络环境中，有防火墙隔离，但并不能完全避免网络攻击。
- 内部运维人员在操作集群的时候，因为一些手误导致集群数据被删除的案例时有耳闻。
- 不同业务类型的数据存放在同一个集群中，这导致每一个集群用户都能看到其它业务相关的数据。
需求描述
- 用户只允许访问有权限的文件。
- 用户只能访问或者修改该用户所拥有的MapReduce任务。
- 服务与服务之间可以相互认证。
- 用户认证成功之后能够获得Credentials，在服务请求时会用到Credentials，但应用无感知。
设计思路
认证
Hadoop的身份认证服务基于Kerberos实现。为一个用户提交认证请求时，Client端需要提供如下信息：
- Principal名称 用户名。
- Keytab文件 可简单理解为用户密钥。
认证成功之后，可以获得对应的TGT(Ticket-Granting-Ticket)。
Service Principal
Kerberos的Principal分为两类：
- User Principal
- Service Principal
User Principal就是普通应用的用户。
Service Principal代表一个服务，如HDFS服务，HBase服务。
一个User Principal去请求一个Service Ticket时，本质上是请求这个服务所关联的Service Principal的Service Ticket。
Client访问HDFS文件
- Client访问NameNode时，需要进行Kerberos认证(基于前面的TGT，去Kerberos获取对应的Service Ticket)。
- NameNode为Client响应的消息中，包含访问DataNode Block时的Block Access Token。
- Client访问的DataNode时，基于Block Access Token即可访问，无需再次进行Kerberos认证。
关于Block Access Token：
- Block Access Token相比于Kerberos TGT/Service Ticket更加轻量级，从而可减轻对Kerberos KDC节点的访问压力。
- Block Access Token只在HDFS范围内有效，不可用于访问其它服务。
- Block Access Token是有时效性的，过期后可续约。
- 未来可以更好的与其它身份认证服务兼容。
RPC
如前一篇文章<分布式系统中引入Kerberos认证所涉及到的框架与技术>中提到的，Client与NameNode/DataNode之间的RPC传输，基于SASL机制进行认证与数据加密，这里不再赘述。
Delegation Token
Client凭借Kerberos Ticket去NameNode成功认证之后，可以获取到一个Delegation Token。该Token可以理解为Client与NameNode之间的一个共享密钥。后续该用户所发起的Jobs可以凭借获取的Delegation Token，直接去NameNode进行认证，从而可绕过Kerberos认证流程。
本文源自：NoSQL漫谈(nosqlnotes.com)
除非特别注明，本站文章均为原创，转载请注明出处和链接。
2 comments