http://blog.itpub.net/28624388/viewspace-2152064/
一:前言
SSL:Secure Sockets Layer,标准化后叫"TLS",http协议默认情况下是不加密内容的,这样就很可能在内容传播的时候被别人监听到,对于安全性要求较高的场合,必须要加密,https就是带加密的http协议。
消息-->[公钥]-->加密后的信息-->[私钥]-->消息
CA:certificate authority 认证证书的第三方机构。
X.509:证书标准,主要定义了证书中应该包含哪些内容.其详情可以参考RFC5280,SSL使用的就是这种证书标准.
PEM: Privacy Enhanced Mail,同样的X.509证书,可能有不同的编码格式,pem是其中的一种编码格式。该种格式以“------BEGIN------”开头,以“------END------”结尾,中间内容是BASE64编码。
CSR:Certificate Signing Request,即证书签名请求,这个并不是证书,而是向权威证书颁发机构获得签名证书的申请
CRT/CER :certificate 证书。
PKI:public key infrastructure公钥基础设施。使用内部托管的认证中心(CA)PKI借助数字证书和公钥加密技术提供可信任的网络身份。通常,证书就是一个包含如下身份信息的文件:
- 证书所有组织的信息
- 公钥
- 证书颁发组织的信息
- 证书颁发组织授予的权限,如证书有效期、适用的主机名、用途等
- 使用证书颁发组织私钥创建的数字签名
每个公钥都有一个对应的私钥,后者在证书所有者的管控之下,可以用于对数据进行数字签名,验证器可以使用证书中的公钥对数据进行验证。如果证书本身包含第三方认证中心的数字签名,那么只要验证器信任该第三方,就可以确保证书是合法的。有时候,证书是由中介认证中心签名,而中介认证中心的证书又是由不同的认证中心签名。在这种情况下,证书验证器会沿着这条链一直找到它信任的证书。对于认证中心而言,信任链模型非常有用,它允许我们将根证书的私钥离线存储,只为中介证书签名。
二:CFSSL构建本地CA
1.创建自己的认证中心
CFSSL具有运行一个认证中心所需的全部功能。虽然CFSSL是为运行内部CA而创建,但它足够健壮,可以用于公开的受信任CA。
运行认证中心需要一个CA证书(ca.pem)和相应的私钥(ca-key.pem)。后者是极其敏感的数据。任何知道私钥的人都可以充当CA颁发证书。因此,私钥的保护至关重要。
2. 生成CA证书和私钥
创建ca-csr.json文件
点击(此处)折叠或打开
- {
- "CN": "kubernetes",
- "key": {
- "algo": "rsa",
- "size": 2048
- },
- "names": [
- {
- "C": "CN",
- "L": "BeiJing",
- "ST": "BeiJing",
- "O": "k8s",
- "OU": "System"
- }
- ]
- }
”CN“:Common Name,kube-apiserver 从证书中提取该字段作为请求的?户名 (User Name);浏览器使用该字段验证网站是否合法
"O":Organization ,kube-apiserver 从证书中提取该字段作为请求?户所属的组 (Group);
执行命令 cfssl gencert -initca ca-csr.json | cfssljson -bare ca
生成: ca.pem ca-key.pem ca.csr(证书签名请求,用于交叉签名或重新签名)
3.配置证书生成策略
配置证书生成策略,让CA软件知道颁发什么样的证书.创建ca-config.json
点击(此处)折叠或打开
- {
- "signing": {
- "default": {
- "expiry": "87600h"
- },
- "profiles": {
- "kubernetes": {
- "usages": [
- "signing",
- "key encipherment",
- "server auth",
- "client auth"
- ],
- "expiry": "87600h"
- }
- }
- }
- }
ca-config.jso: 可以定义多个profiles,分别指定不同的过期时间,使用场景等参数,这里我们只定义了kubernetes一个profile
signing : 表示该证书可用于签名其它证书,生成的ca.pem证书中 CA=TRUE
server auth : 表示client可以使用该CA对server提供的证书进行验证
client auth : 表示server 可以用该CA对client提供的证书进行验证
4.证书生成与签名
截止目前,基于CFSSL的CA已经配置完成,该CA如何颁发证书呢?CFSSL提供了两个命令:gencert和sign。gencert将自动处理整个证书生成过程。该过程需要两个文件,一个告诉CFSSL本地客户端CA的位置以及如何验证请求,即config文件,另一个为CSR配置信息,用于填充CSR 即csr文件。
举例:创建 kubernetes 证书签名请求?件 kubernetes-csr.json (config文件采用之前的ca-config.json)
点击(此处)折叠或打开
- {
- "CN": "kubernetes",
- "hosts": [
- "127.0.0.1",
- "10.116.137.196",
- "10.116.82.28",
- "10.116.36.57",
- "10.254.0.1",
- "kubernetes",
- "kubernetes.default",
- "kubernetes.default.svc",
- "kubernetes.default.svc.cluster",
- "kubernetes.default.svc.cluster.local"
- ],
- "key": {
- "algo":"rsa",
- "size":2048
- },
- "names": [
- {
- "C": "CN",
- "L": "BeiJing",
- "ST": "BeiJing",
- "O": "k8s",
- "OU": "System"
- }
- ]
- }
如果 hosts 字段不为空则需要指定授权使用该证书的 IP 或域名列表,由于该证书后续被 etcd 集群和 kubernetes master 集群使用,所以上面分别指定了 etcd 集群、 kubernetes master 集群的主机 IP 和 kubernetes 服务的服务 IP(一般是 kube-apiserver 指定的 service-cluster-ip-range 网段的第一个IP,如 10.254.0.1。
hosts 中的内容可以为空,即使按照上面的配置,向集群中增加新节点后也不需要重新生成证书。
执行命令:cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes
生成 kubernetes.csr kubernetes-key.pem kubernetes.pem 文件
来源:https://www.cnblogs.com/sandshell/p/12014960.html