k8s—安全机制

本文介绍: 请求api资源：1、认证2、鉴权3、准入机制三个条件都通过，才可以在k8s集群当中创建。

k8s的安全机制，分布式集群管理工具，就是容器编排。安全机制的核心：APIserver。为整个集群内部通信的中介，也是外控控制的入口。所有的机制都是围绕apiserver来进行设计：

请求api资源：

1、认证

2、鉴权

3、准入机制

三个条件都通过，才可以在k8s集群当中创建。

认证

认证：Authentcation

HTTP TOKEN：通过token识别合法用户。tocken是一个很长很复杂的字符串，字符串是用来表达客户的一种方1、式。每一个token对应一个用户名，用户名存储在apiserver能够访问的文件中。

客户端发起请求时，http heard包含token

客户端发起请求—————token————-apiserver（用户存储文件）————–解码————–用户名————–访问集群。

2、http base：用户+密码的验证方式。用户和密码都是通过base64进行加密，加密完成的字符串，http request的headr Authorization发送给服务端。服务端收到加密字符串，解码，获取用户名和密码，验证通过，登录成功。

3、https证书：最严重的方式，也是最严谨的方式，基于CA根证书签名的用户端身份进行验证。

认证的访问类型：

k8s组件对api server组件的访问：kubelet kube-proxy

pod对APl server的访问。pod coredns、dashboard都是pod，也需要访问api

客户端访问、kubectl访问

kubelet kube-proxy controller manager sheduler 与apiserver在一台服务器，可以直接使用api server的非安全端口访问。

kubectl kubelet kube-proxy 都是通过apiserver的https证书，进行双向验证，都是用6443端口进行验证。

签发证书的方式

1、手动签发：二进制部署就是手动签发，CA签发—-把证书匹配到每个对应组件，然后访问6443即可

2、自动签发：kubeadm，kubelet第一次访问api server使用token，token通过之后，controller manager会为kubelet生成一个证书以后都是通过证书访问。kubeadm修改了证书的有效期，默认1年。

3、kubeconfig文件包含集群的参数，CA证书，APIserver地址，客户端的证书（客户端的证书和私钥），集群的名称和用户名。

k8s组件通过启动时指定访问不同的kubeconfig，可以访问不同的集群——–apiserver———–namespace——–资源对象——pod——–容器

kubeconfig既是集群的描述文件，也是一个集群信息的保存文件，包含了集群的访问方式和认证信息

~/.kube/config 保存的时kubectl的访问认证信息

4、serviceAccount：就是为了方便pod中的容器访问apiserver。pod的一切动作（增删查改）动态的，每个pod需要手动生成一个证书，使用serviceAccount来进行循环认证，service Account 里面包含了统一的认证信息，直接进行api server访问。

5、secret：保存资源对象、保存的是自定义的保密信息。

serviceAccount保存的是token service-account-token

serviceAccount的组成部分

1、token

2、ca.crt

3、namespace

这三个部分都会被自动挂载到pod当中

认证

鉴权：之前的认证过程只是确认了双方都是可信的。可以互相通信。健全是为了确定请求方的访问权限。

能做哪些指定的操作。这些操作都是由鉴权来决定的。

通俗来讲：能做那些操作。

鉴权的策略

1、AlwayDeny：拒绝所有，一般测试

2、AlwaysAllow：允许所有，应用测试

3、ABAC attribute-based access control 基于属性的访问控制

4、webhook：外部访问集群内部的的鉴权方式

5、RBAC role-based access control 基于角色的控制访问控制，也是k8s现在默认的规则机制。

角色：

role：指定密码空间的资源控制限制

rolebind：将角色绑定到指定的命名空间

集群

clusterrole：可以授权所有命名空问的资源控制权限

clusterrolebinding：将集群的角色绑定到命名空间

准入控制：

准入控制是apiserver的一个准入控制器的插件列表，不同的插件可以实现不同的准入控制机制。

一般情况下，建议使用官方默认的准入控制器 limitRanger（命名空间的配额管理）、serviceAccount、resourceQuota（命名空间的配额限制）都属于准入控制器。

3、实验，实现不同用户管理自己的命名空间

实验举例

实验目的：实现不同用户管理自己的命名空间

认证—>—鉴权—>—准入机制

命名空间： lucky-cloud

上传证书文件并赋权

useradd lucky
passwd lucky
#创建一个用户
 
mkdir lucky
cd /usr/local/bin/
chmod +x cfssl*
 
vim user-cert.sh
cat > lucky-csr.json <<EOF
{
 "CN": "lucky",
 "hosts": [],
 "key": {
   "algo": "rsa",
   "size": 2048
},
 "names": [
  {
   "C": "CN",
   "ST": "Nanjing",
   "O": "k8s",
   "OU": "system"
   }
  ]
}
  EOF
 
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
#基于设定的信息，创建一个认证证书

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
chmod +x rbac-kubeconfig.sh
./rbac-kubeconfig.sh 192.168.10.10
#此处为master的ip
 
# 使用上下文参数生成 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-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
 
kubectl get pods -o wide

//访问 svc 资源就会被拒绝
kubectl get svc
 
//也无法访问 default 命名空间
kubectl get pods -n default
 
//使用 root 用户查看
kubectl get pods -n lucky-cloud -o wide
 
//也可以通过绑定 admin 角色，来获得管理员权限
kubectl create rolebinding lucky-admin-binding --clusterrole=admin --user=lucky --namespace=lucky