核心是分布式集群管理工具,容器编排,安全机制核心是:API SERVER作为整个集群内部通信的中介,也是外部控制的入口,所有的安全机制都是围绕api server开设计的。
请求api资源
1、认证 2、鉴权 3、准入机制
三个条件都通过,才可以在k8s集群当中创建资源。
HTTP TOKEN:识别合法用户。token是一个很长的特殊的编码,很复杂的一个字符串,字符串是表达客户的一种方式。
每一个token都对一个用户名,用户名存储在api'server能够访问的文字中
客户都安发起请求,http headr包含token。
客户都安发起请求-----token----apiserver(用户名存储文件)-----解码---用户名---开始访问集群。
http base:用户名加密码的验证的方式。用户名和密码都是通过加密方式base64,进行加密。加密完了之后加密完的字符串,在http requeset的heder Atuthorization 发送给服务端。服务端收到加密字符串,解码,获取用户名和密码,验证通过,登录成功。
https证书:最严格的方式,也是最严格的方式,基于CA根证书签名的客户端身份认证的方式进行验证。
k8s组件对apiserver组件的访问 kubelet kube-proxy
pod对api server的访问 pod coredns dashborad 都是pod,也需要访问api
客户端访问 kubectl
kubelet kube-proxy:
controller manager sheduler 与apiserver在一台服务器,可以直接使用api server的非安全端口进行访问。(8080端口)
kubectl kubelet kube-proxy 都是通过api server的https证书进行双向验证。进行双向验证,都是用6443端口进行验证。
1、手动签发 二进制部署就是手动签发证书 ca签发把证书匹配到每个对应组件访问6443即可
2、自动签发,kubeadm, kubelet第一次访问api server使用api server使用token,token通过之后,controller mannager会为kubelet生成一个证书,以后都是通过证书访问。kubeadm修改了证书的有效期,默认一年
3、kubeconfig文件包含集群的参数,ca证书,API server地址,还存储了客户端的参数(客户端证书和私钥),集群的名称和用户名
整个k8s的组件都是通过启动时指定访问不用的kubeconfig,可以访问不同的集群----apiserver---namespace---资源对象---pod---容器
kubeconfig即是集群的描述文件,也是一个集群信息的保存文件,包含了集群的访问方式和认证信息。
~/.kube/config保存是kubectl的访问认证信息。
4、serviceAcount:
serviceAcount就是为了方便pod中容器来访问API server。pod的动作(增删改查)动态的,每个pod手动生成一个证书就不现实。
k8s使用的service Account来循环,不需要单独创建,service Account里面包含了统一的认证信息,直接进行api'service访问。
5、secret,保存资源对象,serviceAccount内部,保存的token service-account0token
secret保存的是自定义的保密信息。
6、serviceAcount:
1、token
2、ca.crt
3、namespace
都会被自动的挂载到pod当中去
二、鉴权:之前的认证过程,只是确认了双方都是可信的,可以相互通信的,鉴权是为了确定请求方的访问权限
能做哪些指定的操作。
1、AlwaysDeny:拒绝所有,一般是测试
2、AlwaysAllow:允许所有,用测试
3、ABAC attribute-based access control 基于属性的访问控制
4、webhook:外部访问集群内部的鉴权方式
5、RBAC:role-base access control基于角色的访问控制,也是k8s默认的规则机制
第一个叫做角色 role:指定命名空间的资源控制权限
rolebinding::将角色绑定到指定的命名空间
还有集群
clustrole:可以授权所有命名空间的资源控制权限
clusterrolebinding:将集群的角色绑定到命名空间
准入控制:
是apiserve的一个准入控制器的一个插入列表,不同的插件可以实现不同的准入控制机制,一般情况下建议使用官方默认的准入控制器
limitranger命名空间的配额管理
serviceAccount
resourceQuota:命名空间的配额限制。
useradd lucky
passwd lucky
mkdir /opt/lucky
chmod +x cfssl+
将三个cfssl cfssljson cfssl-cerinfo赋权
vim user-lucky.sh
cat > lucky-csr.json << EOF
{
"CN": "lucky",
"hosts": [],
"key":{
"algo":"ras"
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "Nanjing",
"L": "k8s",
"OU": "system"
}
]
}
EOF
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernets /opt/u=lucky/lucky-csr.json | cfssljson -bare lucky
vim rbac-kubeconfig.sh
APISERVER=$1
# 设置集群参数
export KUBE_APISERVER="https://$APISERVER:6443"
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/pki/ca.crt \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=lucky.kubeconfig
# 设置客户端认证参数
kubectl config set-credentials lucky \
--client-key=/etc/kubernetes/pki/lucky-key.pem \
--client-certificate=/etc/kubernetes/pki/lucky.pem \
--embed-certs=true \
--kubeconfig=lucky.kubeconfig
# 设置上下文参数
kubectl config set-context kubernetes \
--cluster=kubernetes \
--user=lucky \
--namespace=lucky-cloud \
--kubeconfig=lucky.kubeconfig
kubectl create namespace lucky-cloud
chmod +x rbac-kubeconfig.sh
./rbac-kubeconfig.sh 20.0.0.92
查看证书
cat lucky.kubeconfig
mkdir /home/lucky/.kube
cp lucky.kubeconfig /home/lucky/.kube/config
chown -R lucky:lucky /home/lucky/.kube/
vim rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: lucky-cloud
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: lucky-cloud
subjects:
- kind: User
name: lucky
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
kubectl apply -f rbac.yaml
kubectl get role,rolebinding -n lucky-cloud
kubectl get role,rolebinding -n lucky-cloud
切换用户,测试操作权限
su - lucky
vim pod-test.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-test
spec:
containers:
- name: nginx
image: nginx
kubectl create -f pod-test.yaml