Kerberos

安全性高的产品Kerberos是必须的
Kerberos是网络授权协议的， 基于第三方认证的KDC，大家都比较信任的第三方的，不考虑被攻破的安全性
CDH上的启用Kerberos的向导，
KDC就是第三方的认证的，KDC泄露玩完了
KDC中的kadmin.local
keytab密钥
Client端 Server端 KDC端：Kerberos Distribute center单点的，要做成高可用的方案
主体principal
kerberos的票据会话默认是7天的时间进行刷新的，Kerberos的认证时间是有效期5分钟的timestamp的，本地开发大数据应用的，集群用的Kerberos的，本地的时间与服务器的时间不能差5分钟的额，差5分钟了，它配置了时间的了，请求会拒绝的，认为会话是不安全的，诞生了一个平台的，平台和集群在一个域里面的，不存在时间的问题的，请求平台的通过token加密等等的，把时间进行规避掉的，
Kerberos的应用地方，内部的细节
Kerberos是一种网络协议的额，安全防监听的，防止窃听，防止重放的以及保护数据完整性的场合的，类似于SSH的签名，是一种应用对称密钥体制进行密钥管理的系统的，保护集群安全的
Mysql的群组复制规避掉Mysql的单点
JDBC的连接串不支持Mysql的群组复制的连接串的

Kerberos认证的，票据刷新的，票据会话
Delegation token

Kerberos的三个部分：
Kerberos Principal主体的
在Kerberos中用户或者服务被称为主体，一般由俩部分或者三部分组成的额，primary主要标识，instance实例名称，realm领域，在Kerberos的认证系统中通过主体标识唯一身份，在CDH中主体一般是操作系统用户名或者服务名的，
[e-mail]
name/[e-mail]
Kerberos通过将票据Tickets分配给Kerberos主体使其可以访问启用Kerberos集群的Hadoop服务

HDFS中的configuration高级参数的，基于平台类的服务的加上一些HDFS的proxy代理的，

Kerberos对集群的性能是没有影响的，但是会起到很大的安全作用的，

Kerberos Keytab密钥文件的
相当于是一个用户的密码，Kerberos文件包含了Kerberos主体和该主体密钥的加密脚本，对于Hadoop守护进程来说每隔Keytab文件是唯一的，因为实例包含了主机名，hbase/[e-mail]，该文件用来认证Kerberos主体上的主体，因此Keytab一定要安全保存的，

主体的密钥是在KDC中的额，KDC中有一个数据库DataBase的，DataBase会存所有用户的Count和密钥的额，三方认证的时候，通过密钥加密的，会话密钥给client和server端返回回去的，才可以完成三方认证的，

Delegation Tokens票据同步的，
用户通过Kerberos认证后，提交作业，如果用户此时登出系统后，则后续的认证通过委托令牌的方式完成的额，委托令牌和Nn共享密钥，用于模拟用户来获得执行任务的，委托令牌有效期为一天的，可以通过更新程序更新令牌不超过7天的，任务完成以后委托令牌取消的

Kerberos的ugi中的checktgtandreloginfromkeytab
Should I call ugi.checkTGTAndReloginFromKeyTab() before every action on hadoop?
在Hadoop里面做的认证的额
https://stackoverflow.com 搜索hadoop kerberos

Kerberos依靠Ticket的概念来工作的额，每个部分概念如下：
KDC(Key Distribution Center)=密钥分发中心，由AS和TGS组成的额，是所有通信的主要枢纽，保存有每个客户端或者服务的密钥副本的，辅助完成通信认证
AS(Authentication Server)=认证服务器
TGS(Ticket Granting Server)=票据授权服务器
TGT(Ticket Granting Ticket)=票据授权票据，票据的票据
SS(Service Server)=特定服务提供端

Kerberos涉及的参与者：
1.请求访问某个资源的主体，可以是用户或者服务的(Client)
2.被请求的资源，一般是具体某个服务的，比如hive的(Server)
3.KDC

要开启一个认证会话，客户端首先将用户名发送到KDC的AS进行认证，一般是通过kinit完成的，KDC服务器生成相应的票据授权票据TGT并打上时间戳的，TGT是一个用于请求和其他服务通信的票据，并在数据库中查找该请求用户的密码，并用查找到的密码对TGT进行加密的，将加密结果返回给请求用户的。
客户端收到返回结果，使用自己的密码解密得到TGT票据授权票据，该TGT会在一段时间后自动失效的，有些程序可以用户登陆期间进行自动更新的，比如hadoop的hdfs用户，当客户端需要请求服务的时候，客户端将该TGT发送到KDC的TGS服务，当用户的TGT通过验证并且有权限访问所申请的服务时候，TGS生成一个被请求服务对应的Ticket和SessionKey的，并发给请求客户端的
客户端将该Ticket和要请求的服务一同发送给目的服务端的，完成验证并获得相应服务的，
简单地说，用户先用共享密钥从KDC的AS认证服务器得到一个身份证明的，随后，用户使用这个身份证明与SS通信，而不使用共享密钥的

kinit -kt
rpm -qa | grep krb
kinit
cat /etc/krb5.conf
dns_lookup_realm=false
ticket_lifetime=24h
renew_lifetime=7d
forwardable=true
rdns=false
default_realm=baidu.com
default_ccahe_name=KEYRING:persistent:%{uid}
[realms]
baidu.com ={
kdc=kerberos.example.com 机器名称的，node1
admin_server=kerberos.example.com 机器名称，node1
}
[domain_realm]
.baidu.com=baidu.com
baidu.com=baidu.com
krb5.conf的文件中的域是一模一样的
Kerberos的debug的模式打开的
kinit -kt aaa.keytab aaa
klist
三方认证的主要流程就是Client端与KDC交互的，Client端与服务端进行交互的，而KDC不会与服务端进行交互的
客户端认证过程：客户端Client从认证服务器AS获取票据的票据TGT的
客户端向AS发送明文信息，申请基于该用户的请求服务， 比如用户APP1想请求的服务，注意的是用户不会向AS发送用户
密钥user’s secret key,也不发送密码。因为KDC中数据库中存着用户密钥和密码的额，KDC会基于用户去查询的，该AS能够从本地数据库中查询到该申请用户的密码，并通过相同路径转换成相同的用户密钥user’s secret key
Hash做的密码的，密码是固定的，密码是不可逆的

AS检查请求用户ID是否存在于Kerberos数据库中的，如果存在则通过验证的额，返回如下的俩个信息：
消息A：会话密钥，Client/TGS会话密钥(Client/TGS Session Key) 该Session Key用在将来Client与TGS的通信上的，通过用户密钥进行加密的user’s secret key
消息B：票据授权票据TGT。TGT包括Client/TGS会话密钥(Client/TGS Session Key)，KDC名字的，用户ID，IP地址，TGT有效期，通过KDC中TGS密钥TGS’s Secret key进行加密的
KDC将响应结果返回的额，包括加密后的新会话，TGT
Client收到返回消息后，Client用自己的密钥解密返回的加密会话密钥，从而得到解密后的会话密钥
Client/TGS会话密钥(Client/TGS Session Key)注意的是Client不能解密TGT的，因为TGT是用TGS密钥TGS’s Secret Key加密的，拥有了Client/TGS会话密钥 Client/TGS Session Key，Client就足以通过TGS进行认证了

服务授权–Client从TGS获取票据(client-to-server ticket)
当客户端需要请求某个服务时候，发送如下的信息到KDC
消息C：获取的返回TGT，消息B，即通过TGS密钥(TGS’s Session Key)进行加密的TGT，想要获取服务的服务ID
消息D：认证元组(用户ID,IP地址,时间戳),通过Client/TGS会话密钥(Client/TGS Session Key)加密的
KDC收到请求后，TGS检查KDC数据库中是否存在该服务ID，如果存在，则TGS用自己的TGS密钥(TGS’s Session Key)解密请求消息获得TGT，得到之前生成Client/TGS会话密钥(Client/TGS Session Key)。TGS在用该会话密钥Client/TGS Session Key解密认证元组，得到用户ID，IP地址，时间戳，并验证TGT和认证元组，如果验证通过则返回如下的消息：
消息E：Client-Server票据(Client-To-Server Ticket)该Ticket包括，Client/SS会话密钥(Client/ServerSessionKey)用户ID，用户网址，有效期，通过提供该服务的服务密钥Service’s Secret Key进行加密的
消息F：Client/SS会话密钥(Client/Server Session Key),该Session Key用在将来Client与Server Service的通信上的，通过Client/TGS会话密钥(Client/TGS Session Key)进行加密的
客户端收到响应后通过Client/TGS会话密钥，(Client/TGS Session Key)解密消息得到Client/SS会话密钥(Client/Server Session Key)。注意的是Client不能解密Client-Server票据的，Client-To-Server Ticket，因为是服务密钥加密的Server’s Secret Key

服务请求—Client从SS获取服务
通过获取的Client/SS会话密钥(Client/Server Session Key)后，Client就可以使用服务器提供的服务，Client向服务器发送如下的信息：
消息E：Client-Server票据(Client-To-Server Ticket)，该Ticket包括：Client/SS会话密钥(Client/Server Session Key)，用户ID，用户网址，有效期。通过提供该服务的服务密钥Service’s Secret Key进行加密的
消息G：新认证元组(用户ID，IP地址，时间戳)，通过Client/Server Session Key进行加密的
SS用自己的密钥Service’s secret Key解密消息Client-Server票据(Client-To-Server Ticket)从而得到TGS提供的Client/SS会话密钥(Client/Server Session Key) ，再用这个密钥解密加密的新认证元组得到新认证元组，同TGS一样的额，对Ticket和认证元组进行验证，验证通过则返回1条消息的额，确认函：确认身份真实，乐于提供服务的
消息H：新时间戳，新时间戳是Client发送的时间戳加1，v5已经取消这一做法的，通过Client/SS会话密钥(Client/Server Session Key)进行加密的
Client通过Client/SS会话密钥(Client/Server Session Key)解密消息H，得到新时间戳并验证其是否正确的额，验证通过的话则客户端可以信赖服务器的，并向服务器SS发送服务请求的额，服务SS向客户端提供相应的服务的

启动Kerberos之后，每个服务下面都有keytab文件的
Kerberos都是对称的加密的，

票据托管用户那块的额，admin/admin

rpm -qa |grep krb

Kerberos的安装：1.12.2
主节点：krb5-libs krb5-server krb5-workstation
从节点：krb5-libs krb5-workstation
https://pkgs.org/download/krb5-libs
应该是每个节点上都要有这些包的

卸载rpm包的命令：
rpm -e –nodeps krb5-libs-1.12.2-14.e17.x86_64
rpm -ivh krb5-libs-1.13.2-10.e17.x86_64.rpm

node0节点上做成KDC，所以要安装成krb5-server：
rpm -ivh krb5-server-1.13.2-10.e17.x86_64.rpm

Kerberos的架构是主从的
node0上是有krb5-server的服务的：
vim /var/kerberos/krb5kdc/kdc.conf
[realms]
MUMU.COM={
acl_file=/var/kerberos/krb5kdc/kadm5.acl
dict_file=/usr/share/dict/words
admin_keytab=/var/kerberos/krb5kdc/kadm5.keytab
supported_enctypes=去掉aes256_cts:normal

}

vim /var/kerberos/krb5kdc/kadm5.acl

vim /etc/krb5.conf
[libdefaults]
default_realm=MUMU.COM
[realms]
MUMU.COM={
kdc=node0 //本机的主机名的
admin_server=node0
}
[domain_realm]
.mumu.com=MUMU.COM
mumu.com=MUMU.COM
vim /var/kerberos/krb5kdc/kdc.conf是KDC的文件
但是/etc/krb5.conf是Client的文件的额，是每一个节点都要配置的额
scp /etc/krb5.conf root@node1:/etc/
scp /etc/krb5.conf root@node2:/etc/

创建Kerberos的数据库的：
find / -name “kdb5”
/usr/sbin/kdb5_util
kdb5_util create -s -r MUMU.COM
Enter KDC database master key:数据库的密钥123456
Re-enter KDC database master key to verify:
将会新创建一些新的文件的：
ls /var/kerberos/krb5kdc/
kadm5.acl kdc.conf principal principal.kadm5
principal.kadm5.lock principal.ok

以后CDH启用了Kerberos的时候，是需要Admin principal
添加Admin principal
/usr/sbin/kadmin.local -q “addprinc admin/admin”
Enter Password for principal “admin/[e-mail]”:

vim /var/kerberos/krb5kdc/kadm5.acl
*/[e-mail]代表着所有的权限的

后续就可以启动：
service krb5kdc start
service kadmin start

kadmin.local是不需要密钥的
？帮助命令
listprincs列出用户
addprinc mumu添加用户
exit退出

klist
kinit mumu
klist
生成Keytab文件的，用kadmin.local的方式的：
xst -k /root/mumu.keytab mumu 用户

ls -ltr
kinit -kt mumu.keytab.com mumu 进行验证
klist
kdestroy
klist
kinit -kt mumu.keytab mumu
认证的过程，还没有授权的过程的

scp mumu.keytab root@node1:~/
kinit -kt mumu.keytab mumu
ls -ltr
mumu.keytab文件是一个密码相当于

KDC是由kadmin.local管理的

Kerberos
openLab的安装
KDC Server的主机:node0
Kerberos安全领域：MUMU.COM
Kerberos的加密类型：默认
Kerberos Principal 最大可更新生命周：默认
KRB5配置:打勾默认
KDC Account Manager凭据：
输入有权创建其他用户的账户的凭据，超级管理的账户
cat /etc/krb5.conf
用户名：admin/[e-mail]
密码：123456
kadmin.local
listprincs

有什么样的服务则会添加相应的Kerberos主体的
HDFS中可能会有一些代理用户访问的权限：

Kerberos受保护的集群的，
CM用的是node.js开发的
CDH中的安全里面会有一些票据的
kadmin.local
listprincs

报错的问题：Couldn’t renew kerberos ticket in order to work around Kerberos 1.8.1 issue ,Please check that the ticket for ‘HUE/[e-mail]’ is still renewable

配置的时间与HUE默认的时间是不统一的，一周之后自动刷新的
cat /etc/krb5.conf
renew_lifetime=604800秒的
修改一下：admin.local中的
modprinc -maxrenewlife 1week krbtgt/[e-mail]
修改之后，重启服务即可

HDFS上的一些参数的变化的：
hadoop安全身份验证：Kerberos的
HUE的Kerberos主体短名称：
hue.kerberos.principal.shortname=
启用HTTP Web控制台的Kerberos身份认证：则hdfs的页面是打不开的

kinit
klist查看有无票据的
kdestroy摧毁票据的
票据冻结的，票据是没有过期的，
Caused by:java.io.IOException:javax.security.sasl.SaslException:GSS initiate failed Caused by GSSException :No valid credentials provided
Mechanism level:Failed to find any Kerberos tgt

kinit的有效期是一天的，过期后会refresh
kinit -kt mumu.keytab mumu
klist

Zookeeper的Kerberos的启用：
keytab的文件没有与KDC进行验证的，
有了keytab文件就可以进行kinit的处理的
kinit -kt mumu.keytab mumu
klist
find / -name “*.keytab”

hdfs是supergroup的组，可以代理的任何的组用户的，做平台的开发时候，配置hdfs的超级代理

Active Directory后缀:ou=hadoop,DC=hadoop,DC=com

openLDAP
HiveServer2 Load Balancer负载均衡：HA Proxoy
角色权限的调整：
Load Balancer分成四层的：
DNS:负载均衡的额，一个IP多个域名的，基于Nginx的反向代理的
lvs做的负载均衡的：
HA Proxy做的负载均衡：
分布式服务：
支持商业级的并发的，不会有性能上的问题：

Load Balancer：HA Proxy
haproxy的介绍：
类似于一种反向代理的，支持高可用以及负载均衡的，支持TCP和HTTP的应用程序代理的
TCP网络互联协议，第四层的
HTTP是第七层的应用程序的

groupadd haproxy
useradd -g haproxy haproxy -s /bin/false
cat /etc/passwd
hue和impala的经过Kerberos认证都是基于local的模式的额，su 不过去的额，su hue /bin/false

yum install -y gcc
虚拟机的网络模式设置成桥接的模式的
vim /etc/sysconfig/network-scripts/ifcfg-eno16777736
配置一下DNS1的地址的额，
DNS1=114.114.114.114

haproxy是由C语言编写的额，

www.haproxy.org的官网的，
tar -zxvf haproxy-1.7.3.tar.gz
mv haproxy-1.7.3 haproxy
tar.gz包中由很多原生的东西，需要自己编译一下的额,需要自己make一下的
make TARGET=linux3100 CPU=x86_64 PREFIX=/usr/local/haproxy/

mkdir -p /usr/local/haproxy/conf/
mkdir -p /etc/haproxy/
touch /usr/local/haproxy/conf/haproxy.cfg
ln -s /usr/local/haproxy/conf/haproxy.cfg /etc/haproxy/haproxy.cfg

find / -name “errorfiles”

cp -r /root/haproxy-1.7.3/examples/errorfiles /usr/local/haproxy/errorfiles
ln -s /usr/local/haproxy/errorfiles /etc/haproxy/errorfiles

mkdir -p /usr/local/haproxy/log
touch /usr/local/haproxy/log/haproxy.log
ln -s /usr/local/haproxy/log/haproxy.log /var/log/haproxy.log

cp /root/haproxy-1.7.3/examples/haproxy.init /etc/rc.d/init.d/haproxy
chmod +x /etc/rc.d/init.d/haproxy
chkconfig haproxy on
ln -s /usr/local/haproxy/sbin/haproxy /usr/sbin
vim /usr/local/haproxy/conf/haproxy.cfg
搜索关键词：
haproxy 代理策略
haproxy txt

service haproxy start
systemctl status haproxy.service

Netty的结构：
PostGrep的数据库主从结构，
Ladp的安装的：
CDH的参数配置，代理配置，调优的
SDK封装线程池，调度，安全，签名：
封装成Rest的API的操作的
对外暴露Restful的接口
所有的数据都是基于Rest和Json的传输的

Setry的授权，
UserGroupInformation.getLoginUser().checkTGTAndReloginFromKeytab();
return UserGroupInformation.getLoginUser().doAs(action);

CDH中的Kafka的配置文件： System.setProperty(“java.security.auth.login.config”,”/Users/zhumenjun/kafka_client_joos.conf”);
System.setProperty(“java.security.krb5.conf”,”/Users/zhumenjun/krb5.conf”);
System.setProperty(“sun.security.krb5.debug “,”true”);

props.put(“sosl.mechanism”,”G55API”);
props.put(“security.protocol”,”SASL_PLAINTEXT”);

参考别人的github的实现方案的：阻塞队列的
c3p0
dbcp
共同一个池的几百个连接对象并发时候是要进行抢锁的，
Partition的概念的数据库连接池
hive结合hbase测试时候,Thrift Port，Session不能无限创建的，要公用等等问题。

服务架构基于Netty构建

系统学习某个框架技术，一定要下载源代码进行跟踪编译

Github上的一个开源的监控项目Download下来研究：
dashbuilder

kafka-connector-hdfs
github上commit比较多的项目学习学习：
most stars
看看源代码 看看源代码 看看源代码
cloudera Autheorized
cloudera blog 中很多的技术目录的categories
cloudera blog 中hive的blog很多人分享的hive的东西的
https://blog.cloudera.com/blog/category/hive/
blog都是技术性的分享的
多看看大牛的资料
Rest接口的时候，HTTP权威指南

应用过程中逐渐积累的知识，用经验堆积起来的
基于Netty构建的，并发上好的，NIO服务器
jetty支持web的，网页渲染之类的

HAProxy
Kerberos认证的代码：如何与集群完成认证功能
分享一下学习方法论的东西，技术的分享是需要理解的，时间的沉淀的，多去Github上看看，下载一些框架的源码包分析，很多的代码可以去借鉴借鉴的

deeplearnig4j
看看数据库连接池的东西，在GitHub上搜索pool
选择most stars
知道如何去找问题的：
并发的问题，线程池问题还好是服务器问题，调优还是换一些组件的，带着疑问去学习的

StreamSets工作流的方式，pipeline的方式

java Concurrency/Multithreading Tutorial

设计一些架构的东西，项目外包出去的，转手的基础项目比较多的
架构核心的东西，
云平台对性能的损耗在20%左右的，底层都是read的，存储在磁盘柜里面的，不像是单机物理机进行存储的，磁盘柜底层都是read操作 ，保证数据的高可靠，如果在上面部署hadoop的平台，则会造成数据重复read和性能问题的，IO,带宽,CPU等开销的，CPU都是虚拟出来的额，vcore出来的，可能是四路的或者是8路的，4路分出来的虚拟CPU的话，做平行计算时候有可能是一个core出来的额，不是多个core出来的，所以有可能不是真正的平行计算的，都会有影响的，有条件最好是物理机的，物理机要做灾备，俩个机房。
AWS美国的，使用的时候可以跳墙的，

百度搜索AWS,免费用一年

亚马逊免费的服务器，免费一年的，自己装一个ssh的就可以翻墙了