设计初衷
对于企业级的应用而言,认证与鉴权可以说是一个基础需求:
- 尽管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