magnum下kubernetes安全模型

背景知识

HTTPS是在基于TLS/SSL的安全套接字上的的应用层协议，除了传输层进行了加密外，其它与常规HTTP协议基本保持一致
TLS是传输层安全协议（Transport Layer Security）的缩写，是一种对基于网络的传输的加密协议，可以在受信任的第三方公证基础上做双方的身份认证。
证书是TLS协议中用来对身份进行验证的机制，是一种数字签名形式的文件，包含证书拥有者的公钥及第三方的证书信息。

HTTPS协议

　简单一点理解，HTTPS 就是 “HTTP内容向下传输的时候加了一层TLS/SSL加密”，参考ISO七层网络模型，这个就很好理解，HTTPS属于应用层协议，在传输的时候，HTTPS的报文就被传输层协议包起来，在HTTPS的报文将作为TCP报文的内容，TCP报文除了内容之后，还附件TCP报文头。HTTPS跟HTTP的协议区别就是对HTTPS报文进行加密，加密是为了安全，但是这个地方不单单是简单的用加密算法对其加密，而是为了实现传输的安全，加密这一块引入了SSL/TLS协议的部分。所以理解HTTPS协议除了对HTTP协议了解之后，更加重要的是对SSL/TLS协议的理解。

SSL/TLS 协议

SSL/TLS涉及几个重要的组成部分
1. 握手协议－－－非对称加密
2. 传输协议－－－对称加密
3. 数字签名以及数字证书
4. 数字认证机构CA
5. 以及openssl的学习主要是这几个方面的内容。

先说一下SSL/TLS的区别，SSL利用加密技术，可确保数据在网络上之传输过程中不会被截取。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1。
可以看成TLS是基于SSL的，并且是对SSL的延伸，所以说一开始理解的时候可以讲他们等价。

SSL/TLS提供的能力
认证用户和服务器，确保数据发送到正确的客户机和服务器；
加密数据以防止数据中途被窃取；
维护数据的完整性，确保数据在传输过程中不被改变。

SSL/TLS协议分成两部分
握手协议－－－使用的是非对称加密技术(RSA)
传输协议－－－使用对称加密技术(DES)
（至于对称加密技术和非对称加密技术区别很容易理解，对称加密是加密解密使用一个秘钥，速度较快，容易别破解；非对称加密技术包含公钥和私钥，可以利用公钥加密，之后私钥解密得到明文；也可以用私钥加密，公钥解密得到明文）
握手协议完成之后得到传输协议过程中需要使用的私钥，之后利用该私钥进行加密对数据进行传输。

那为什么SSL/TLS在握手协议的过程中能够保证安全，这个里面涉及到一个重要的知识就是数字证书。
握手协议的交互图，一般分两种认证，一种是单方服务器认证

过程流程：client发起请求，server回复请求，之后server发送自己的证书给client端进行认证，认证成功表示是可信的（待会再说明为什么通过证书能说明是可信的server）。之后利用证书中的公钥进行加密，发送给server端，server端收到之后利用自己的私钥进行解密，返回给client端，client端看到跟之前是一致的一致的，说明是ok的。之后client再次发送对称加密的是使用的私钥给server端，server端收到之后利用私钥进行解密，解密出来之后，以后传输的时候，将使用这个私钥进行加解密。
另外一个是双向认证

这个流程跟上面是差不多的，只是多了一个对client端的认证。

那么为什么能够保证server端发送过来的证书是可信的。

数字证书和CA的简介

数字证书是一种权威性的电子文档。它提供了一种在Internet上验证您身份的方式，其作用类似于司机的驾驶执照或日常生活中的身份证。它是由一个由权威机构—-CA证书授权(Certificate Authority)中心发行的，人们可以在互联网交往中用它来识别对方的身份。当然在数字证书认证的过程中，证书认证中心（CA）作为权威的、公正的、可信赖的第三方，其作用是至关重要的。
CA认证中心是负责签发，管理，认证数字证书的机构，是基于国际互联网平台建立的一个公正，权威，可信赖的第三方组织机构。
全球有很多个CA认证中心, 根CA认证中心代表权威, 它可以分派数字证书(包括下级CA数字证书 , 用户数字证书).
CA认证中心的关系图:

数字证书的组成

数字证书由CA派发, 包含F证书内容(明文写明证书的一些信息,包括派发单位,证书所有人等), A加密算法 , F’数字签名(派发该证书的CA的数字签名) , 所有者的公钥
这里要说一下数字签名的产生过程:
例如这里由派发证书的CA生成的数字签名, 首先, 对证书内容(F)进行hash算法生成摘要, 使用CA自己的私钥进行RSA加密(或者其他一种非对称加密算法A) , 就生成出了数字签名(F’).
数字证书的验证原理
数字证书通过F , A , F’ 三项来验证证书的真实性和有效性.
首先我们要知道下面几个特点:
1.数字证书机制默认, 所有者的私钥是安全的
2.根CA的公钥默认认为是合法的, 且是为大多数浏览器所知的, 甚至内嵌的. 例如firefox的证书管理器中就内嵌了已知的根CA的公钥.
验证数字证书(包含验证’证书’和’持有人’的真实有效性)的过程: (*)
1. 使用派发证书的CA的公钥(可以向CA请求)来对F’解密得到h1 (hash值)
2. 对证书内容F进行hash算法得到h2
3. 如果h1 == h2 , 那么证书是真实有效的.
4. 当证书被证明是真实有效的, 那么我们就可以认为数字证书中包含的公钥, 是证书所有人(申请该证书的用户或者机构)的真实公钥.
(从这一点我们可以知道, 其实数字证书, 就是为了保证公钥的正确性而产生的)
5. 用此公钥加密一段信息发送给证书的持有者，如果持有者能发送回（可以是被私钥加密，也可以是明文，没有关系）被加密的这段信息的话就证明该持有者拥有该证书对应的私钥，也就是说，该持有者就是该证书的所有者。

  以上过程(前3步)可以用下图说明:

由于一个数字证书基于上层的数字证书作验证，那上层的数字证书又是否合法呢？？这就会出现一直递归上去的现象，事实也是这样的，验证一个证书是否合法，需要验证到他的最顶层的根证书是否合法！从其他的文章弄来的这幅图很好地表达了这个思想：　

openssl里面是如何生成证书的。

证书的生成可以用linux的OpenSSL工具链。对于一个网站，首先必须有自己的私钥，私钥的生成方式为：
openssl genrsa -out ssl.key 2048
私钥必须妥善保管，既不能丢失，也不能泄露。如果发生丢失和泄露，必须马上重新生成，以使旧的证书失效。
1. 如果要对私钥进行传输/备份，建议先对私钥进行密码加密：
openssl rsa -in ssl.key -des3 -out encrypted.key
利用私钥就可以生成证书了。OpenSSL使用x509命令生成证书。这里需要区分两个概念：证书(certificate)和证书请求(certificate sign request)
证书是自签名或CA签名过的凭据，用来进行身份认证
证书请求是对签名的请求，需要使用私钥进行签名
x509命令可以将证书和证书请求相互转换，不过我们这里只用到从证书请求到证书的过程

从私钥或已加密的私钥均可以生成证书请求。生成证书请求的方法为：
openssl req -new -key ssl.key -out ssl.csr
如果私钥已加密，需要输入密码。req命令会通过命令行要求用户输入国家、地区、组织等信息，这些信息会附加在证书中展示给连接方。
接下来用私钥对证书请求进行签名。根据不同的场景，签名的方式也略有不同
自签名，生成CA证书
CA证书是一种特殊的自签名证书，可以用来对其它证书进行签名。这样当验证方选择信任了CA证书，被签名的其它证书就被信任了。在验证方进行验证时，CA证书来自操作系统的信任证书库，或者指定的证书列表。
生成自签名证书的方法为：
openssl x509 -req -in sign.csr -extensions v3_ca -signkey sign.key -out sign.crt
利用CA证书进行签名
使用CA证书对其它证书进行签名的方法为：
openssl x509 -req -in ssl.csr -extensions v3_usr -CA sign.crt -CAkey sign.key -CAcreateserial -out ssl.crt
花钱购买证书机构的签名－－在网络上通过想CA管理结构申请证书的是什么道理
利用上述方法，受信任的机构就可以用自己的私钥(sign.key)对其他人的证书进行签名。我们看到，只需要把证书请求(ssl.csr)发给证书机构，证书机构就可以生成出签名过的证书(ssl.crt)。目前购买证书签名服务的价格大约为100-400元/年。

magnum下kubernetes的安全体系

上面的背景知识了解清楚了，那么magnum以及k8s中又是怎么使用这套原理实现tls　bay的机制了。
　bay_create的流程里面，为每一个bay生成一个自签名的CA证书，这个自签名的CA证书的目的是为了CA证书是一种特殊的自签名证书，可以用来对其它证书进行签名。这样当验证方选择信任了CA证书，被签名的其它证书就被信任了。

magnum.conductor.handlers.common.cert_manager._generate_ca_cert()

同时也会创建使用CA证书对magnum_client_cert进行签名，这样magnum将作为一个client来访问bay,也就是bay中的k8s集群中的kube-apiserver 开放的https的监听端口

magnum.conductor.handlers.common.cert_manager._generate_client_cert()

那么k8s集群提供了对外安全的https　api接口又是怎么工作的了
在创建k8s的时候，kube-apiserver 组件启动的时候，指定了运行参数为如下所示

/usr/bin/kube-apiserver --logtostderr=true --v=0 --etcd_servers=http://127.0.0.1:2379 --bind_address=0.0.0.0 --secure-port=6443 --insecure-port=8080 --allow_privileged=true --service-cluster-ip-range=10.254.0.0/16 --runtime_config=api/all=true --tls_cert_file=/srv/kubernetes/server.crt --tls_private_key_file=/srv/kubernetes/server.key –client_ca_file=/srv/kubernetes/ca.crt

其中ca.crt是bay对应的自签名证书
server.key是server自己生成的私钥
server.crt是server经过bay的自签名CA证书根据配置自签名得到的证书。

作为一个client端，这里可以认为是kublet/kube-ui或者是curl命令，如何集成并访问tls下的api-server。这个时候需要的证书文件是

/srv/kubernetes/client.crt　　被ca.crt签名过的证书
/srv/kubernetes/client.key　　client的私钥　
/srv/kubernetes/ca.crt　　　　bay的自签名证书

在k8s的集群的slave节点上是通过make-cert-client.sh脚本生成的

那么如何实现client与api-server之间的tls传输的了。再看看ca双向认证的图是不是理解了

如何集成其他的client到k8s中，

curl命令以及外部kubectl请参考看easysstack/mitaka分支中doc/soource/dev/tls.rst这个文档进行集成。
另外firefox浏览器下访问kube-ui，需要在tls.rst文档的基础之后执行
openssl pkcs12 -export -clcerts -inkey client.key -in client.crt -out kubecfg.p12 -name “kubecfg”　生成可以导入firefox以及charome的证书。之后导入到浏览器的证书管理中，注意这个时候如果访问/api/v1/proxy/namespaces/kube-system/services/kube-ui/仍然会提示非安全需要添加例外才能访问。

更深层次的理解

证书认证方式的访问为什么能等效于用户名和密码的访问，因为它们实现了同样的功能，身份认证；除了身份认证之后，ssl/tls另外提供了身份认证过程中的可信通道以及数据传输过程中的加密机制。所以它是安全的．

links:
http://www.cnblogs.com/hyddd/
http://wwww.2cto.com