【K8S 云原生】K8S的安全机制

目录

一、K8S安全机制概述

1、概念

2、请求apiserver资源的三个步骤：

一、认证：Anthentcation

1、认证的方式：

[1、HTTP TOKEN：](#1、HTTP TOKEN：)

[2、http base：](#2、http base：)

3、http证书：

2、认证的访问类型：

3、签发证书：

二、鉴权

1、概念：

[2、API Server 目前支持以下几种授权策略：](#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 <<EOF
{
  "CN": "lucky",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
	  "ST": "BeiJing",
      "L": "BeiJing",
      "O": "k8s",
	  "OU": "System"
    }
  ]
}
EOF
#API Server 会把客户端证书的 CN 字段作为 User，把 names.O 字段作为 Group

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-cloud

kubectl 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: nginx

kubectl 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用户，测试权限：