主机推荐网
主机推荐网
投稿

为什么同一个“套”内的证书必须签署？

主机推荐网 380 0

K8S各种各样的证书介绍

一共有多少证书：

先从Etcd算起：

1、Etcd对外提供服务，要有一套etcd 证书

2、Etcd各节点之间进行通信，要有一套etcd peer证书

3、Kube-API 访问Etcd，要有一套etcd 证书

再算：

4、Kube-API 对外提供服务，要有一套kube- 证书

5、kube-、kube--、kube-proxy、和其他可能用到的组件，需要访问kube-API ，要有一套kube- 证书

6、kube--要生成服务的 ，要有一对用来签署 的证书(CA证书)

7、对外提供服务，要有一套 证书

8、kube-API 需要访问，要有一套 证书

加起来共8套，但是这里的“套”的含义我们需要理解。

同一个套内的证书必须是用同一个CA签署的，签署不同套里的证书的CA可以相同，也可以不同。例如，所有etcd 证书需要是同一个CA签署的，所有的etcd peer证书也需要是同一个CA签署的，而一个etcd 证书和一个etcd peer证书，完全可以是两个CA机构签署的，彼此没有任何关系。这算两套证书。

为什么同一个“套”内的证书必须是同一个CA签署的

原因在验证这些证书的一端。因为在要验证这些证书的一端，通常只能指定一个Root CA。这样一来，被验证的证书自然都需要是被这同一个Root CA对应的私钥签署，不然不能通过认证。

其实实际上，使用一套证书（都使用一套CA来签署）一样可以搭建出K8S，一样可以上生产，但是理清这些证书的关系，在遇到因为证书错误，请求被拒绝的现象的时候，不至于无从下手，而且如果没有搞清证书之间的关系，在维护或者解决问题的时候，贸然更换了证书，弄不好会把整个系统搞瘫。

每个用到的证书都是独一无二的，因为它要绑定各自的IP地址，于是需要给每个单独制作证书，如果业务量很大的情况下，node节点会很多，这样一来的数量也随之增加，而且还会经常变动（增减Node）的证书制作就成为一件很麻烦的事情。使用TLS 就可以省事儿很多。

**工作原理：**第一次启动的时候，先用同一个 token作为凭证。这个token已经被提前设置为隶属于用户组：，并且这个用户组的权限也被限定为只能用来申请证书。 用这个 token通过认证后，申请到属于自己的两套证书（ 、kube- for ），申请成功后，再用属于自己的证书做认证，从而拥有了应有的权限。这样一来，就去掉了手动为每个准备证书的过程，并且的证书还可以自动轮替更新

证书为何不同

这样做是一个为了审计，另一个为了安全。 每个既是服务端（kube-需要访问），也是客户端（需要访问kube-），所以要有服务端和客户端两组证书。

服务端证书需要与服务器地址绑定，每个的地址都不相同，即使绑定域名也是绑定不同的域名，故服务端地址不同

客户端证书也不应相同，每个的认证证书与所在机器的IP绑定后，可以防止一个的认证证书泄露以后，使从另外的机器上伪造的请求通过验证。

安全方面，如果每个node上保留了用于签署证书的 token，那么 token泄漏以后，是不是可以随意签署证书了？安全隐患非常大。所以，启动成功以后，本地的 token需要被删除

正式制作证书

虽然可以用多套证书，但是维护多套CA实在过于繁杂，这里还是用一个CA签署所有证书。

需要准备的证书：

ca-key.pem

ca.pem

admin-key.pem

admin.pem

kube--key.pem

kube-.pem

kube---key.pem

kube--.pem

kube-proxy-key.pem

kube-proxy.pem

-key.pem （-key.pem）

.pem（.pem）

使用证书的组件如下：

etcd：使用 ca.pem -key.pem .pem

kube-：使用 ca.pem ca-key.pem -key.pem .pem

：使用 ca.pem

kube-proxy：使用 ca.pem kube-proxy-key.pem kube-proxy.pem

：使用 ca.pem admin-key.pem、admin.pem

kube--：使用 ca-key.pem ca.pem kube---key.pem kube--.pem

kube-: 使用 kube--key.pem kube-.pem

我们使用CFSSL来制作证书，它是开发的一个开源的PKI工具，是一个完备的CA服务系统，可以签署、撤销证书等，覆盖了一个证书的整个生命周期，后面只用到了它的命令行工具。

注：一般情况下，K8S中证书只需要创建一次，以后在向集群中添加新节点时只要将/etc//ssl目录下的证书拷贝到新节点上即可。

wget

wget

wget

chmod +x -amd64 -amd64 cfssl--amd64

mv -amd64 /usr/local/bin/cfssl

mv -amd64 /usr/local/bin/

mv cfssl--amd64 /usr/bin/cfssl-

一：创建CA证书

创建证书配置文件

/etc//ssl

ca-.json

{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "kubernetes": {
         "expiry": "87600h",
         "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ]
      }
    }
  }
}

字段说明：

ca-.json：可以定义多个 ，分别指定不同的过期时间、使用场景等参数；后续在签名证书时使用某个 ；

：表示该证书可以签名其他证书；生成的ca.pem证书中 CA=TRUE；

auth：表示可以用该 CA 对提供的证书进行验证；

auth：表示可以用该CA对提供的证书进行验证；

：过期时间

创建CA证书签名请求文件

ca-csr.json

{
    "CN": "kubernetes",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Shenzhen",
            "ST": "Shenzhen",
            "O": "k8s",
            "OU": "System"
        }
    ],
    "ca": {
       "expiry": "87600h"
    }
}

字段说明：

“CN”： Name，kube- 从证书中提取该字段作为请求的用户名 (User Name)；浏览器使用该字段验证网站是否合法；

“O”：，kube- 从证书中提取该字段作为请求用户所属的组 (Group)

生成CA证书和私钥

-amd64 - ca-csr.json | -amd64 -bare ca -

其中ca-key.pem是ca的私钥，ca.csr是一个签署请求，ca.pem是CA证书，是后面组件会用到的

二：创建证书

创建证书签名请求文件

-csr.json

{
    "CN": "kubernetes",
    "hosts": [
      "127.0.0.1",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local",
      "192.168.10.10","192.168.10.11","192.168.10.12"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Shenzhen",
            "ST": "Shenzhen",
            "O": "k8s",
            "OU": "System"
        }
    ]
}

字段说明：

如果 hosts 字段不为空则需要指定授权使用该证书的 IP 或域名列表。

由于该证书后续被 etcd 集群和 集群使用，将etcd、节点的IP都填上，同时还有网络的首IP。(一般是 kube- 指定的 --ip-range 网段的第一个IP，如 10.0.0.1)

生成证书和私钥

-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= -csr.json | -amd64 -bare

三：创建admin证书

创建admin证书签名请求文件

admin-csr.json

{
    "CN": "admin",
    "hosts": [],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Shenzhen",
            "ST": "Shenzhen",
            "O": "system:masters",
            "OU": "System"
        }
    ]
}

说明：

后续 kube- 使用 RBAC 对客户端(如 、kube-proxy、Pod)请求进行授权；

kube- 预定义了一些 RBAC 使用的 ，如 -admin 将 Group : 与 Role -admin 绑定，该 Role 授予了调用kube- 的所有 API的权限；

O指定该证书的 Group 为 :， 使用该证书访问 kube- 时 ，由于证书被 CA 签名，所以认证通过，同时由于证书用户组为经过预授权的 :，所以被授予访问所有 API 的权限；

注：这个admin 证书，是将来生成管理员用的kube 配置文件用的，现在我们一般建议使用RBAC 来对 进行角色权限控制， 将证书中的CN 字段 作为User， O 字段作为 Group

注意"hosts": []表示所有主机

生成admin证书和私钥

-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= admin-csr.json | -amd64 -bare admin

四：创建kube-proxy证书

创建 kube-proxy 证书签名请求文件

kube-proxy-csr.json

{
  "CN": "system:kube-proxy",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "L": "Shenzhen",
      "ST": "Shenzhen",
      "O": "k8s",
      "OU": "System"
    }
  ]
}

说明：

CN 指定该证书的 User 为 :kube-proxy；

kube- 预定义的 :node- 将User :kube-proxy 与 Role :node- 绑定，该 Role 授予了调用 kube- Proxy 相关 API 的权限；

该证书只会被 当做 证书使用，所以 hosts 字段为空

生成kube-proxy证书和私钥

-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= kube-proxy-csr.json | -amd64 -bare kube-proxy

五：创建kube--证书

创建 kube-- 证书签名请求文件

kube---csr.json

{
    "CN": "system:kube-controller-manager",
    "hosts": [
      "127.0.0.1",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local",
      "192.168.10.10",
      "192.168.10.11",
      "192.168.10.12"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Shenzhen",
            "ST": "Shenzhen",
            "O": "system:kube-controller-manager",
            "OU": "System"
        }
    ]
}

说明：

hosts 列表包含所有 kube-- 节点 IP；

CN 为 :kube--、O 为 :kube--， 内置的 :kube-- 赋予 kube-- 工作所需的权限

生成kube--证书和私钥

-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= kube---csr.json | -amd64 -bare kube--

六：创建kube-证书

创建 kube- 证书签名请求文件

kube--csr.json

{
    "CN": "system:kube-scheduler",
    "hosts": [
      "127.0.0.1",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local",
      "192.168.10.10",
      "192.168.10.11",
      "192.168.10.12"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Shenzhen",
            "ST": "Shenzhen",
            "O": "system:kube-scheduler",
            "OU": "System"
        }
    ]
}

说明：

hosts 列表包含所有 kube- 节点 IP；

CN 为 :kube-、O 为 :kube-， 内置的 :kube- 将赋予 kube- 工作所需的权限

生成kube-证书和私钥

-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= kube--csr.json | -amd64 -bare kube-

七：查看证书信息：

cfssl- -cert .pem

在搭建k8s集群的时候，将这些文件分发到至此集群中其他节点机器中即可。至此，TLS证书创建完毕

分发 /etc/目录内容

rsync -av -- -- '*.json' -- '*.csr' /etc/ root@192.168.10.11:/etc

rsync -av -- -- '*.json' -- '*.csr' /etc/ root@192.168.10.12:/etc

服务器安全证书_证书安全有问题的网站无法打开_证书器安全服务怎么关闭

服务器安全证书_证书器安全服务怎么关闭_证书安全有问题的网站无法打开

所属专题： 证书 签署 字段 签名 绑定

版权声明：本站部分图片来源于互联网，除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处，如有侵权请联系删除。。

上一个三星-MGCJ内存模组的性能、稳定性和低功耗设计

下一个英伟达发布自主移动机器人平台NovaOrin，提高开发效率

相关文章

发布评论 （0条评论）

  • Refresh code

还木有评论哦，快来抢沙发吧~