K8S安全-RBAC

K8S安全-RBAC

文章目录

​​一、Kubernetes 安全框架​​

​​`1.1.鉴权（Authentication）`​​​​`1.2.授权(Authorization)`​​​​`1.3.准入控制（Admission Control）`​​

​​二、基于角色的权限访问控制：RBAC​​

​​`2.1.角色`​​​​`2.2.角色绑定`​​​​`2.3.主体（subject）`​​

​​三、为devops用户授权访问default命名空间权限​​

​​`3.1.用K8S CA签发客户端证书`​​

​​3.1.1.[Shell脚本安装cfssl](javascript:void(0))​​​​3.1.2.生成客户端证书脚本create_cert.sh​​

​​`3.2.生成kubeconfig授权文件`​​​​`3.3.创建RBAC权限策略`​​

一、Kubernetes 安全框架

K8S安全控制框架主要由下面3个阶段进行控制：

Authentication（鉴权），确认身份Authorization（授权），根据身份授予权限Admission Control（准入控制），类似于电子扫描，可以灵活配置

客户端要想访问K8s集群API Server，一般需要证书、Token或 者用户名+密码；如果Pod访问，需要ServiceAccount

​​1.1.鉴权（Authentication）​​

三种客户端身份认证： • HTTPS 证书认证：基于CA证书签名的数字证书认证 • HTTP Token认证：通过一个Token来识别用户 • HTTP Base认证：用户名+密码的方式认证(基本不用)

​​1.2.授权(Authorization)​​

RBAC（Role-Based Access Control，基于角色的访问控制）：负责完成授权（Authorization）工作。

RBAC根据API请求属性，决定允许还是拒绝。

比较常见的授权维度： • user：用户名 • group：用户分组 • 资源，例如pod、deployment • 资源操作方法：get，list，create，update，patch，watch，delete • 命名空间 • API组

​​1.3.准入控制（Admission Control）​​

Adminssion Control实际上是一个准入控制器插件列表，发送到API Server的请求都需要经过这个列表中的每个准入控制器插件的检查，检查不通过，则拒绝请求。

二、基于角色的权限访问控制：RBAC

​​2.1.角色​​

一组权限的集合

• Role：授权特定命名空间的访问权限 • ClusterRole：授权所有命名空间的访问权限

​​2.2.角色绑定​​

• RoleBinding：将角色绑定到主体（即subject） • ClusterRoleBinding：将集群角色绑定到主体

​​2.3.主体（subject）​​

• User：用户 • Group：用户组 • ServiceAccount：服务账号

三、为devops用户授权访问default命名空间权限

​​3.1.用K8S CA签发客户端证书​​

3.1.1.Shell脚本安装cfssl

3.1.2.生成客户端证书脚本create_cert.sh

#!/bin/bashset -e[ "$#" -ne 1 ] && echo "ERROR:Please Usage:bash $(basename $0) devops(devops表示使用证书的用户)" && exit 1USER_NAME=$1CA_CERT_PATH="/etc/kubernetes/pki"CERT_PATH="/opt/cert"[ ! -d "${CA_CERT_PATH}" ] && echo "ERROR:${CA_CERT_PATH}不存在!!!" && exit 1[ ! -d "${CERT_PATH}" ] && mkdir ${CERT_PATH}cd ${CERT_PATH}cat > ca-config.json < ${USER_NAME}-csr.json <

bash create_cert.sh devops

​​3.2.生成kubeconfig授权文件​​

创建kubeconfig的脚本create_kubeconfig.sh

#!/bin/bashset -e[ "$#" -ne 1 ] && echo "ERROR:Please Usage:bash $(basename $0) devops(devops表示使用kubeconfig的用户)" && exit 1USER_NAME=$1CA_CERT_PATH="/etc/kubernetes/pki"MASTER_URL="! -d "${CA_CERT_PATH}" ] && echo "ERROR:${CA_CERT_PATH}不存在!!!" && exit 1if [ ! -f "${CERT_PATH}"/"${USER_NAME}"-key.pem -o ! -f "${CERT_PATH}"/"${USER_NAME}".pem ];then echo "ERROR:${CERT_PATH}下没有对应的证书和私钥" && exit 1fikubectl config set-cluster kubernetes \ --certificate-authority=${CA_CERT_PATH}/ca.crt \ --embed-certs=true \ --server=${MASTER_URL} \ --kubeconfig=${CERT_PATH}/${USER_NAME}.kubeconfig # 设置客户端认证kubectl config set-credentials ${USER_NAME} \ --client-key=${CERT_PATH}/${USER_NAME}-key.pem \ --client-certificate=${CERT_PATH}/${USER_NAME}.pem \ --embed-certs=true \ --kubeconfig=${CERT_PATH}/${USER_NAME}.kubeconfig# 设置默认上下文kubectl config set-context kubernetes \ --cluster=kubernetes \ --user=${USER_NAME} \ --kubeconfig=${CERT_PATH}/${USER_NAME}.kubeconfig# 设置当前使用配置kubectl config use-context kubernetes --kubeconfig=${CERT_PATH}/${USER_NAME}.kubeconfigecho "INFO:${USER_NAME}用户的kubeconfig文件路径为${CERT_PATH}/${USER_NAME}.kubeconfig"set +e

bash create_kubeconfig.sh devops

测试生成的kubeconfig文件

kubectl --kubeconfig=/opt/cert/devops.kubeconfig get pod

​​3.3.创建RBAC权限策略​​

允许devops用户查看default命名空间下的Pod、deploy、service

rbac.yaml

kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: default name: pod-readerrules:- apiGroups: ["","apps"] resources: ["pods","deployments","services"] #资源 verbs: ["get", "watch", "list"] #对资源的操作---kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: read-pods namespace: defaultsubjects:- kind: User name: devops #与生成证书的名字匹配 apiGroup: rbac.authorization.k8s.ioroleRef: kind: Role name: pod-reader #通过名字与Role匹配 apiGroup: rbac.authorization.k8s.io

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。