kerberos使用

理论上，通过kerberos认证后又没开启sentry，可以随意访问服务，但有的服务还有额外的acl权限限制，比如hdfs和hbase，需要额外进行授权，sentry只能管hive，hdfs和hbase用的是acl，当然，sentry可以通过acl来管理hdfs。

缩写

add_principal，addprinc，ank
delete_principal，delprinc
ktadd，xst
change_password，cpw

登录kadmin

kadmin.local
非kadmin节点使用admin权限的prin认证后，输入kadmin后输入密码

生成随机key的principal，这种principal只能用来生成keytab使用

addprinc -randkey root/master1@EXAMPLE.COM

ktadd -k keytab位置 prin名

这种方式生成keytab时，缺省会生成长串随机密码来覆盖原来的密码。覆盖后，就不能用原来密码登录了，只能用keytab，如果想要继续使用密码登录，需要使用-norandkey参数来避免生成长串随机密码。
-norandkey表示不用很长的随机密码，使用自己设置的密码，意味着可以同时用密码和keytab认证
ktadd -norandkey -k /keytab/root.keytab root/master1@EXAMPLE.COM host/master1@EXAMPLE.COM

生成指定密码的principal，执行后会提示输入密码

addprinc admin/admin

为principal生成keytab，可同时添加多个

ktadd -norandkey -k /keytab/root.keytab root/master1@EXAMPLE.COM host/master1@EXAMPLE.COM

klist -ket xxx.keytab　　查看参数keytab里面包含的的认证信息

在一个节点上，有可能多个脚本并行执行，kinit的认证有可能被覆盖，所以在kinit之前，需要把产生的pubkey暂存起来

场景：有个脚本，连续2天，每天调度跑的时候就报错，然后手动调一次就能跑过
被覆盖之后脚本报错

export KRB5CCNAME=/tmp/krb5_udp_dev
kinit -kt xxx xxx

klist -e = klist

查看当前用户认证信息

# klist -ket xxx.keytab

Keytab name: FILE:xxx.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   7 2018-07-30T10:19:16 hbase-flink@demo.com (des-cbc-md5) 
   7 2018-07-30T10:19:16 hbase-flink@demo.com (aes128-cts-hmac-sha1-96) 
   7 2018-07-30T10:19:16 hbase-flink@demo.com (aes256-cts-hmac-sha1-96) 
   7 2018-07-30T10:19:16 hbase-flink@demo.com (des3-cbc-sha1) 
   7 2018-07-30T10:19:16 hbase-flink@demo.com (arcfour-hmac)

查看principal

listprincs

修改admin/admin的密码

change_password -pw xxxx admin/admin　　
cpw

删除principal

delete_principal admin/admin

lab

1. 使用密码创建一个principal后，如果用ktadd生成随机密码的keytab(默认)，会用一个很长的随机密码覆盖原来手动设置的密码，那么原来的密码就不能用了。如果使用 -norandkey，可以密码和keytab同时使用

addprinc test1
ktadd -norandkey -k /opt/keytabs/test1.keytab test1

此时用密码和keytabs都可以认证

2. 2个生命周期

Kerberos ticket 有两种生命周期，ticket timelife (票据生命周期) 和 renewable lifetime (可再生周期)。

当 ticket lifetime 结束时，该 ticket 将不再可用。
如果 renewable lifetime > ticket lifetime ，那么在票据生命周期内可以续期，直到达到可再生周期。
当时间达到 renewable lifetime 后，ticket lifetime结束后将不能继续续期，续期时将会报错 KDC can’t fulfill requested option while renewing credentials，之后需要重新kinit申请新的ticket

与使用较长的生命周期的票据相比，可再生票据的优点是KDC可以拒绝续期请求(例如，如果发现帐户被破坏，并且可再生票据可能在攻击者手中)。？？？

例如:
ticket_lifetime = 1d
renew_lifetime = 7d
在登陆后的24h内可以对ticket进行续期，直到第一次登陆的7天后将不再允许续期。
在24h内如果没有续期，将无法续期。
对 ticket 进行一次续期后，ticket_lifetime 将恢复到24h。==》
第一次kinit后，从kinit时间到tl期间内可以renew，renew后，start time刷新。直接第一次的st到rl后，不能再刷新

实际场景中，开发告诉运维3天开发完，但3天大概率开发不完，这时候就可以续期，而不用重新输密码或用keytab。

kerberos可以用kinit得到一个ticket(又叫tgt), 在这个ticket生效期间不用输入密码, ticket可以不停续期, 有一个expire日期,下面的例子是12月07到12月08的一天时间, 但是生效期内可以通过 kinit -R 来续期这个ticket, 但是还有个renew until, 表示最长可以续期多久, 下面例子表示15年12/12号以后, kinit -R 就不能续期了.

kinit -R会把当前认证的prin的Valid starting时间刷新为当前，Expires时间自然也就顺延。但renew until时间仍然是第一次认证时确定的时间。

这个ticket和keytab无关, keytab是一个密码文件, 加密了你的密码而已.

Execute a klist command to verify the values that the system actually granted you.

Ticket cache: FILE:/tmp/krb5cc_1234
Default principal:someuser@UCAR.EDU
Valid starting Expires Service principal
12/07/15 13:00:05 12/08/15 13:00:01 krbtgt/UCAR.EDU@UCAR.EDU
renew until 12/12/15 15:48:44

The ticket will expire like an ordinary ticket in 24 hours, but you
can renew multiple times before its expiration, until the final
expiration date (Dec 12 in the example above). You must do the kinit
command interactively because you will have to provide your Kerberos
passphrase; this cannot be put into a cron job or other unattended
situation.