kerberos原理及使用

一、kerberos认证原理
Kerberos中有三种角色:服务器, 客户端, KDC（认证服务器）
KDC就是受信任的第三方（trusted third party arbitrator），KDC上运行着2个重要的Kerberos daemons，即 kadmind 和 krb5kdc。
　　Kadmind: 这是管理Kerberos server的进程，一个名为kadmin 的程序使用 kadmind 来维护principal database和policy configuration。
　　Krb5kdc: 在Kerberos authentication的过程中担负trusted third party arbitrator的职责。
Client：需要使用kerbores服务的客户端
Service：提供具体服务的服务端

协议授权流程分三个部分
1、首先，Client向KDC发送自己的身份信息，KDC从授予票据服务(Ticket Granting Service)得到可用的票据(ticket-granting ticket)，并用协议开始前KDC与Client之间的密钥将票据加密回复给client，
client收到KDC回复的加密票据后利用与client先前协议的密钥将票据解密，从而获得票据，此步骤主要是允许client进行Kerberos的验证，是进行访问服务的先决条件

2、通过上面的过程，Client实际上获得了两组信息：一个通过自己Master Key加密的Session Key，另一个被Sever的Master Key加密的数据包，包含Session Key和关于自己的一些确认信息。

3、Client通过自己的Master Key对KDC加密的Session Key进行解密从而获得Session Key，随后创建Authenticator（Client Info + Timestamp）并用Session Key对其加密。最后连同从KDC获得的、被Server的Master Key加密过的数据包（Client Info + Session Key）一并发送到Server端。我们把通过Server的Master Key加密过的数据包称为Session Ticket。
　　当Server接收到这两组数据后，先使用他自己的Master Key对Session Ticket进行解密，从而获得Session Key。随后使用该Session Key解密Authenticator，通过比较Authenticator中的Client Info和Session Ticket中的Client Info从而实现对Client的认证。

二、Principal与keytab
Principal：在 Kerberos 中，Principal 是参加认证的基本实体。一般来说有两种，一种用来表示 Kerberos 数据库中的用户，另一种用来代表某一特定主机，也就是说 Principal是用来表示客户端和服务端身份的实体,
Principal 是由三个部分组成：名字（name），实例（instance），REALM（域）。比如一个标准的 Kerberos 的用户是：name/instance@REALM 。
1)Name：第一部分。在代表客户方的情况，它是一个用户名；在代表主机的情况，它是写成 host。
2)Instance：第二部分。对 name 的进一步描述，例如 name 所在的主机名或 name 的类型等,可省略。它与第一部分之间用‘ / ’分隔，但是作为主机的描述时写成 host/Instance。
3)Realm：第三部分。是 Kerberos 在管理上的划分，在 KDC 中所负责的一个域数据库称作为 Realm。这个数据库中存放有该网络范围内的所有 Principal 和它们的密钥，
数据库的内容被 Kerberos 的认证服务器 AS 和票据授权服务器 TGS 所使用。Realm 通常是永远是大写的字符,并且在大多数 Kerberos 系统的配置中，一般 Realm 和该网络环境的 DNS 域是一致的。与第二部分之间用‘@’分隔，缺省为本地的 Realm

用户principal的命名类似 elis/admin@EXAMPLE.COM，形式是用户名／角色／realm域。
服务principal的命名类似 ftp/station1.example.com@EXAMPLE.COM，形式是服务名／地址／realm域

keytab文件:包含允许使用 Kerberos 身份验证的客户端的成对唯一名称（主体）的文件，和从 Kerberos 密码获得的加密密钥。Keytab 文件用于远程系统，支持 Kerberos 无需输入密码即对用户进行身份验证

三、常用命令
客户端最常用的两个命令:
klist lists the Kerberos principal and Kerberos tickets held in a credentials cache, or the keys held in a keytab file
如:klist -k /etc/kafka/conf.cloudera.kafka/hadoop.keytab -t -e
kinit obtains and caches an initial ticket-granting ticket for principal。
如 kinit -kt hadoop.keytab hive/node1.trms.com@HADOOP.COM

kerberos数据库最常用到的两个命令:
kdb5_util初始化数据库，迁移数据库等整体操作。
(kadmin及kadmin.local[local是运行再kdc server本地])
kadmin provides for the maintenance of Kerberos principals, password policies, and service key tables (keytabs).

例子: kadmin.local或者kadmin -kt /usr/local/kafka/hadoop.keytab -p kafka@HADOOP.COM
进去之后可执行list_principals，add_principal，modify_principal，get_principal。ktadd。getprivs，list_policies

四、重要的配置文件
1、/etc/krb5.conf(主要是日志、密码类型时效、kdc/kadmin的位置，Kerberos的admin的realms)内容:
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
default_tgs_enctypes = aes256-cts
default_tkt_enctypes = aes256-cts
permitted_enctypes = aes256-cts
rdns = false
#pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
default_realm = HADOOP.COM
#default_ccache_name = KEYRING:persistent:%{uid}
udp_preference_limit = 1 ##禁止使用udp可以防止一个Hadoop中的错误
kdc_timeout = 3000

[realms]
HADOOP.COM = {
kdc = node1.trms.com ##代表要kdc的位置。格式是机器:端口
admin_server = node1.trms.com ##代表admin的位置。格式是机器:端口
}

[domain_realm]
.HADOOP.com = HADOOP.COM
HADOOP.com = HADOOP.COM

2、/var/kerberos/krb5kdc/kdc.conf: (可通过man kdc.conf 查看配置的含义)
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88

[realms]
HADOOP.COM = {
max_life = 24h
max_renewable_life = 7d
master_key_type = aes256-cts
acl_file = /var/kerberos/krb5kdc/kadm5.acl ## Location of the access control list file that kadmind(8) uses to determine which principals are allowed which permissions on the Kerberos database
database_name=/usr/local/var/krb5kdc/principal ##the location of the Kerberos database for this realm
dict_file = /usr/share/dict/words
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
}

HADOOP.COM:是设定的realms。名字随意。Kerberos可以支持多个realms，会增加复杂度。本文不探讨。大小写敏感，一般为了识别使用全部大写。这个realms跟机器的host没有大关系。
max_renewable_life = 7d 涉及到是否能进行ticket的renwe必须配置。
master_key_type:和supported_enctypes默认使用aes256-cts。由于，JAVA使用aes256-cts验证方式需要安装额外的jar包，更多参考2.2.9关于AES-256加密：。推荐不使用。
acl_file:标注了admin的用户权限。文件格式是: Kerberos_principal permissions [target_principal] [restrictions]支持通配符等。
supported_enctypes:支持的校验方式。注意把aes256-cts去掉。

3、kadm5.acl
在KDC上我们需要编辑acl文件来设置权限，该acl文件的默认路径是 /var/kerberos/krb5kdc/kadm5.acl（也可以在文件kdc.conf中修改）。
Kerberos的kadmind daemon会使用该文件来管理对Kerberos database的访问权限。
对于那些可能会对pincipal产生影响的操作，acl文件也能控制哪些principal能操作哪些其他pricipals
格式:principal permissions [target_principal [restrictions] ]
/admin@HADOOP.COM * ==> 代表名称匹配/admin@HADOOP.COM 都认为是admin，权限是 *。代表全部权限

kadmin.local命令不受kadm5.acl影响:
the kadmin.local utility on the master KDC. kadmin.local is designed to be run on the master KDC host without using Kerberos authentication to an admin server;
instead, it must have read and write access to the Kerberos database on the local filesystem.