k8s是分布式集群管理工具,k8s作用是容器编排
1、安全机制核心:API server。API server作为整个集群内部通信的中介,也是外部控制的入口,所有的安全机制都是围绕api sserver来进行设计的。请求api server资源要满足3个条件:认证、鉴权、准入机制。三个条件都通过才能在k8s中创建资源
2、认证anthentcation方式
(1)http token:通过token识别合法用户。token是一个很长、很复杂的字符串,字符串是用来表达客户的一种方式,每一个token对应一个用户名,用户名存储在api server能够访问的文件中,客户端发起请求时,http header中包含token,token对应到api server,api server对应到用户名存储文件,解码查看是否对应用户名,验证通过可访问集群
(2)http base:用户名+密码的验证方式。用户名和密码都是通过base64进行加密,加密完成的字符串存储在http request的header Atuthorization中,发送给服务端。服务端收到加密字符串,解码后获取用户名和密码,验证通过,登录成功
(3)https证书:这是最严格、最严谨的方式。基于CA根证书签名的客户端身份进行验证
3、认证的访问类型
(1)k8s组件对api server的访问(kubelet、kube-proxy)
(2)pod对api server的访问(pod、coredns、dashborad)
4、安全性说明
(1)controller namnger、scheduler与api server在一台服务器,可以直接使用api server的非安全端口进行访问
(2)kubectl、kubelet、kube-proxy都是通过api server的https证书进行双向验证,都是用6443端口进行验证
5、签发证书的方式
(1)手动签发(二进制部署是手动签发证书。CA签发:把证书匹配到每个对应组件,然后访问6443即可)
(2)自动签发(kubeadm是自动签发证书。kubelet第一次访问api server使用token,一旦token通过后,controller manager会为kubelet生成一个证书,以后都是通过证书访问)
6、kubeconfig
此文件包含集群的参数,比如CA证书、API server地址、客户端的参数(客户端的证书和私钥、集群的名称和用户名)等。k8s组件都是通过启动时指定访问不同的kubeconfig文件,可以访问不同的集群,再到api server,再到namespace,再到资源对象,再到pod,再到容器。简而言之,kubeconfig既是集群的描述文件,也是集群信息的保存文件,包含了集群的访问方式和认证信息
./kube/config保存的是kubectl的访问认证信息
7、Service Account
pod中的容器访问api server依靠serviceaccount。由于动态的pod动作(增删改查),为每个pod手动生成一个证书太麻烦,于是k8s使用service account来进行循环认证,service account里包含了统一的认证信息,通过service account直接进行api server访问
8、Secret与SA 的关系
Kubernetes 设计了一种资源对象叫做 Secret,分为两类:
①用于保存 ServiceAccount 的 service-account-token
②用于保存用户自定义保密信息的 Opaque
Service Account 中包含三个部分:
①Token:是使用 API Server 私钥签名的 Token 字符串序列号,用于访问 API Server 时,Server 端认证
②ca.crt:ca 根证书,用于 Client 端验证 API Server 发送来的证书
③namespace:标识这个 service-account-token 的作用域名空间
默认情况下,每个 namespace 都会有一个 Service Account,如果 pod 在创建时没有指定 Service Account,就会使用 pod 所属namespace 的 Service Account。每个 pod 在创建后都会自动设置spec.serviceAccount 为 default(除非指定了其他 Service Accout)
9、鉴权
之前的认证方式只确认双方都是可信的,可以相互通信,鉴权是为了确定请求方的访问权限
AlwaysDeny | 拒绝所有(用于测试) |
AlwaysAllow | 允许所有(用于测试) |
ABAC | attribute-based access control基于属性的访问控制 |
webhook | 外部访问集群内部的鉴权方式 |
RBAC | role-base access control基于角色的访问控制。k8s的默认规则机制(常用) |
①角色role——绑定角色到指定的命名空间rolebinding 指定命名空间的资源控制权限 | |
②集群clusterrole——绑定集群clusterrolebinding 可以授权所有命名空间的资源控制权限 kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user kubernetes-admin |
5、准入控制
准入控制是api server的一个准入控制器的插件列表,不同的插件可以实现不同的准入控制机制。一般情况下建议使用官方默认的准入控制器,比如limitranger命名空间的配额限制、serviceAccount、resourceQuota命名空间的配额限制
不同用户管理自己的命名空间实验
1、创建用户lucky,命名空间lucky-cloud
2、认证
①上传证书
②生成根证书
cd /etc/kubernetes/pki/
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /opt/lucky/lucky-csr.json | cfssljson -bare lucky
3、鉴权
kubeconfig保存token、鉴权信息等
使用上下文参数生成 lucky.kubeconfig 文件,查看证书
kubectl config use-context kubernetes --kubeconfig=lucky.kubeconfig4、准入机制
5、切换用户,测试操作权限
①第一次测试用户权限
lucky用户只能在lucky-cloud命名空间中查看pod的情况,其他的这个用户没有权限
若想lucky用户有这些权限,在rbac文件中加入这些权限
②第二次测试用户权限resources里一般给这两个权限,其他的权限可以加,但要和别的条件关联,较复杂