【K8S 云原生】K8S的安全机制
目录
一、K8S安全机制概述
1、概念
2、请求apiserver资源的三个步骤：
一、认证：Anthentcation
1、认证的方式：
1、HTTP TOKEN：
2、http base：
3、http证书：
2、认证的访问类型：
3、签发证书：
二、鉴权
1、概念：
2、API Server 目前支持以下几种授权策略：
三、准入控制
四、实验
一、K8S安全机制概述
1、概念
K8S中的安全机制，分布式的集群管理工具，就是容器编排。
安全机制的核心：apiserver作为整个集群内部通信的中介，也是外部控制进入的入口
所有的apiserver都是围绕apiserver来设计的
2、请求apiserver资源的三个步骤：
1、认证
2、鉴权
3、准入控制
三个条件通过了，才能在K8S集群中创建
一、认证：Anthentcation
1、认证的方式：
1、HTTP TOKEN：
通过token识别合法用户。token是一个很长，很复杂的一个字符串，字符串是用来表达客户的一种方式
每一个token对应一个用户名，用户名存储在apiserver能够访问的文件中
客户端发起请求时，http haeder中包含token
客户端发起请求—token—apiserver（验证用户名存储文件）—解码—用户名—访问集群
2、http base：
用户+密码的验证方式。用户名和密码都是通过base64进行加密，加密完成的字符串，http request的haeder Atuthorization发送给服务端。服务端收到加密字符串，解码，获取用户名名和密码，验证通过，登录成功
3、http证书：
面向公众来说，他是最严格的方式，也是最严谨的方式。基于CA根证书签名的客户端身份验证进行验证
2、认证的访问类型：
K8S组件对apiserve组件的访问。kubelet，kube-proxy
pod对apiserver的访问。pod-corndns，dashborad，也需要访问api
客户端kubectl访问
kubelet、kube-proxy
controller-manager、scheduler与apiserver在一台服务器，可以直接使用apiserver的非安全端口进行访问。
kubectl、kubelet、kube-proxy都是通过apiserver的http证书，进行双向验证，都是用6443端口进行验证
3、签发证书：
1、手动签发，二进制部署就是手动签发证书。CA签发—把证书匹配到每个对应组件。然后访问6443即可
2、自动签发，kubeadm就是自动签发。kubelet第一次访问apiserver使用token认证，token通过之后，controller-manager会为kubelet生成一个证书
以后都是通过证书访问。kubeadm部署时修改了证书的有效期。默认1年，改成10年
3、kubeconfig，这个文件包含集群的参数，CA证书，apiserver地址，客户端的参数（客户端证书和私钥），集群的名称和用户名。
K8S中的组件通过启动时指定访问不同的kubeconfig文件，可以访问不同的集群—apiserver—namespace—资源对象—pod—容器
kubeconfig即使集群的文件，也是一个集群信息的保存文件，包含集群访问方式和认证信息
一般都在家目录下 ~/.kube/config 这个文件保存的是kubectl的访问认证信息
4、serviceAccount：
serviceAccount就是为了方便pod中的容器来访问apiserver。pod动态的的动作（增删改查），每个pod手动生成证书就不现实了。于是K8S就使用了serviceAccount来进行循环验证，service Account里面包含了统一的认证信息，直接进行apiserver访问
5、Secret，保存资源对象
serviceAccount，保存的token，service-account-token
Secret保存到的是自定义的保密信息
6、serviceAccount保存的信息
token：
ca.crt
namespace
都会被自动的挂载到pod中去
二、鉴权
1、概念：
之前的认证过程，只是确认了双方都是可信的，可以互相通信的，鉴权是为了确定请求方的访问权限，能做哪些操作
之前搭建K8S进行的角色操作
kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous
kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user kubernetes-admin
#创建用户，给权限，绑定集群2、API Server 目前支持以下几种授权策略：
1、AlwaysDeny：拒绝所有，一般是测试
2、AlwaysAllow：允许所有，用于测试
3、ABAC attribute-based access control：基于属性的访问控制
4、webhook：外部访问集群内部的鉴权方式
5、RBAC role-base access control：基于角色的访问控制，K8S最常用的规则，也是K8S现在默认的规则机制
角色：role，指定命名空间的资源控制权限
角色绑定：rolebinding，将角色绑定到指定的命名空间
集群角色：clusterrole，可以授权所有命名空间的资源控制权限
集群角色绑定：clusterrolebinding，将集群的角色绑定到命名空间
三、准入控制
准入控制是apiserver的一个准入控制器的插件列表，不同的插件可以实现不同的准入控制机制
一般情况下，建议使用官方默认的准入控制器
limitRanger（命名空间的配额管理）、serviceAccount、resourceQuota（命名空间的配额限制）都属于准入控制器
四、实验
实验目的：实现不同用户管理自己的命名空间
创建一个用户：
useradd lucky
passwd lucky
#创建用户lucky密码
su - lucky
#切换用户
kubectl get pods
#创建lucky-cloud，lucky用户只能管理lucky-cloud命名空间，其他命名空间没权限
创建用于用户连接到 API Server 所需的证书和 kubeconfig 文件
先上传证书生成工具 cfssl、cfssljson、cfssl-certinfo 到 /usr/local/bin 目录中
chmod +x /usr/local/bin/cfssl*
mkdir /opt/lucky
cd /opt/lucky
vim user-cert.sh
#写脚本
cat > lucky-csr.json <
chmod +x user-cert.sh
./user-cert.sh
cd /etc/kubernetes/pki/
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /opt/lucky/lucky-csr.json | cfssljson -bare lucky
#/etc/kubernetes/pki/ 目录中会生成 lucky-key.pem、lucky.pem、lucky.csr
cd /opt/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
#创建lucky-cloud命名空间
chmod +x rbac-kubeconfig.sh
./rbac-kubeconfig.sh 20.0.0.61
# 使用上下文参数生成 lucky.kubeconfig 文件
kubectl config use-context kubernetes --kubeconfig=lucky.kubeconfig#查看证书
cat lucky.kubeconfig
mkdir /home/lucky/.kube
cp lucky.kubeconfig /home/lucky/.kube/config
chown -R lucky:lucky /home/lucky/.kube/
RBAC授权
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-cloudkubectl apply -f rbac.yaml
kubectl get role,rolebinding -n lucky-cloud
创建在
vim pod-test.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-test
namespace: lucky-cloud
spec:
containers:
- name: nginx
image: nginxkubectl create -f pod-test.yaml切换用户，测试操作权限
su - lucky
用户能对lucky-cloud命名空间进行操作
但是访问svc会被拒绝，访问其他命名空间也会被拒绝
RoleBinding 的用户只能管理指定的命名空间中的资源
也可以通过绑定 admin 角色，来获得管理员权限
kubectl create rolebinding lucky-admin-binding --clusterrole=admin --user=lucky --namespace=lucky增加rbac角色权限：
回到lucky用户，测试权限：
