首页 > kubernetes(k8s) > kubernetes的认证授权
2019
10-28

kubernetes的认证授权

kubernetes的认证

kubernetes提供了多种认证方式,比如客户端证书、静态token、静态密码文件、ServiceAccountTokens等等。你可以同时使用一种或多种认证方式。只要通过任何一个都被认作是认证通过。下面我们就认识几个常见的认证方式。

  • 客户端证书认证 客户端证书认证叫作TLS双向认证,也就是服务器客户端互相验证证书的正确性,在都正确的情况下协调通信加密方案。 为了使用这个方案,api-server需要用–client-ca-file选项来开启。
  • 引导Token 当我们有非常多的node节点时,手动为每个node节点配置TLS认证比较麻烦,这时就可以用到引导token的认证方式,前提是需要在api-server开启 experimental-bootstrap-token-auth 特性,客户端的token信息与预先定义的token匹配认证通过后,自动为node颁发证书。当然引导token是一种机制,可以用到各种场景中。
  • Service Account Tokens 认证 有些情况下,我们希望在pod内部访问api-server,获取集群的信息,甚至对集群进行改动。针对这种情况,kubernetes提供了一种特殊的认证方式:Service Account。 Service Account 和 pod、service、deployment 一样是 kubernetes 集群中的一种资源,用户也可以创建自己的 Service Account。 ServiceAccount 主要包含了三个内容:namespace、Token 和 CA。namespace 指定了 pod 所在的 namespace,CA 用于验证 apiserver 的证书,token 用作身份验证。它们都通过 mount 的方式保存在 pod 的文件系统中。

 kubernetes的授权

kubernetes的AdmissionControl

  • AlwaysAdmit:允许所有请求
  • AlwaysDeny:禁止所有请求,多用于测试环境
  • ServiceAccount:它将serviceAccounts实现了自动化,它会辅助serviceAccount做一些事情,比如如果pod没有serviceAccount属性,它会自动添加一个default,并确保pod的serviceAccount始终存在
  • LimitRanger:他会观察所有的请求,确保没有违反已经定义好的约束条件,这些条件定义在namespace中LimitRange对象中。如果在kubernetes中使用LimitRange对象,则必须使用这个插件。
  • NamespaceExists:它会观察所有的请求,如果请求尝试创建一个不存在的namespace,则这个请求被拒绝。

1.环境准备

3.1停止原有kubernetes相关服务

开始之前我们要先把基础版本的集群停掉,包括service,deployments,pods以及运行的所有kubernetes组件。

3.2 重新生成配置(所有节点)

3.3安装cfssl(所有节点)

cfssl是非常好用的CA工具,我们用它来生成证书和秘钥文件
安装过程比较简单,如下:

3.4生成根证书(主节点)

根证书是证书信任链的根,各个组件通讯的前提是有一份大家都信任的证书(根证书),每个人使用的证书都是由这个根证书签发的。

4. 改造etcd

4.1 准备证书

4.2. 改造etcd服务

建议大家先比较一下增加认证的etcd配置与原有配置的区别,做到心中有数。 可以使用命令比较:

更新etcd服务:

5. 改造api-server

5.1 准备证书

5.2改造api-server服务

查看diff

生成token认证文件

更新api-server服务

6. 改造controller-manager

controller-manager一般与api-server在同一台机器上,所以可以使用非安全端口与api-server通讯,不需要生成证书和私钥。

6.1 改造controller-manager服务

查看diff

更新controller-manager服务

7. 改造scheduler

scheduler一般与apiserver在同一台机器上,所以可以使用非安全端口与apiserver通讯。不需要生成证书和私钥。

7.1 改造scheduler服务

查看diff 比较会发现两个文件并没有区别,不需要改造

启动服务

8. 改造kubectl(所有节点,因为之前所有节点都有装kubelet)

8.1 准备证书

8.2配置kubectl

验证master节点

9. 改造calico-node

9.1 准备证书—– 在主节点上

后续可以看到calico证书用在四个地方:

  • calico/node 这个docker 容器运行时访问 etcd 使用证书
  • cni 配置文件中,cni 插件需要访问 etcd 使用证书
  • calicoctl 操作集群网络时访问 etcd 使用证书
  • calico/kube-controllers 同步集群网络策略时访问 etcd 使用证书

9.2 改造calico服务

查看diff

更新calico服务

10. 改造kubelet

我们这里让kubelet使用引导token的方式认证,所以认证方式跟之前的组件不同,它的证书不是手动生成,而是由工作节点TLS BootStrap 向api-server请求,由主节点的controller-manager 自动签发。

10.1 创建角色绑定(主节点)

在主节点执行下面命令 (记住是主节点,在主节点创建角色绑定,然后工作节点使用主节点的token加入)

10.2 创建bootstrap.kubeconfig(工作节点 我个人包括master都是工作节点)

这个配置是用来完成bootstrap token认证的,保存了像用户,token等重要的认证信息,这个文件可以借助kubectl命令生成:(也可以自己写配置)

由于我三个节点(包括主节点)都是工作节点,所以我三台机器都需要执行如下代码

10.3 准备cni配置

查看diff

copy配置

10.4 改造kubelet服务

查看diff

更新服务

188
189

11. 改造kube-proxy(所有节点)

11.1 准备证书

11.2 生成kube-proxy.kubeconfig配置

11.3 改造kube-proxy服务

查看diff ( 经过diff你应该发现kube-proxy.service没有变化 )

启动服务

1.9版本kube-proxy启动iptables无法写入 bug 传送门

12. 改造kube-dns(app 属于应用yaml部署)

service account认证:

RBAC授权:

12.1 准备配置文件

我们在官方的基础上添加的变量,生成适合我们集群的配置。直接copy就可以啦

大家可以看到diff只有一处,新的配置没有设定api-server。不访问api-server,它是怎么知道每个服务的cluster ip和pod的endpoints的呢?这就是因为kubernetes在启动每个服务service的时候会以环境变量的方式把所有服务的ip,端口等信息注入进来。

12.2 创建kube-dns

到此安全版的kubernetes集群我们部署完成了。

接下来部署监控等等一系列生产用到的监控项

最后编辑:
作者:shooter
这个作者貌似有点懒,什么都没有留下。

留下一个回复

你的email不会被公开。