目录

k8s安全框架

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

案例

 操作示例

测试

授权

案例：为指定用户授权访问不同命名空间权限

拓展

k8s安全框架 K8S安全控制框架主要由下面3个阶段进行控制，通过API Server配 置来启用插件： 1. Authentication（鉴权） 2. Authorization（授权） 3. Admission Control（准入控制） 整个k8s的操作流程如下 K8s Apiserver提供三种客户端身份认证： • HTTPS 证书认证：基于CA证书签名的数字证书认证（kubeconfig） • HTTP Token认证：通过一个Token来识别用户（serviceaccount） • HTTP Base认证：用户名+密码的方式认证（1.19版本弃用） 授权（Authorization ） RBAC（Role-Based Access Control，基于角色的访问控制）：负责完成授权（Authorization）工作。RBAC根据API请求属性，决定允许还是拒绝。 比较常见的授权维度： • user：用户名 • group：用户分组 • 资源，例如pod、deployment • 资源操作方法：get，list，create，update，patch，watch，delete • 命名空间 • API组 准入控制（Admission Control） Adminssion Control实际上是一个准入控制器插件列表，发送到API Server的请求都需要经过这个列表中的每个准入控制器插件的检查，检查不通过，则拒绝请求。 启用一个准入控制器：

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...

关闭一个准入控制器：

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

查看默认启用：

kubectl exec kube-apiserver-k8s-master -n kube-system -- kube-apiserver -h | grep enable-admission-plugins

例如，通过这个命令我们可以查看，， 这里面包含已启用以及全部可启用

基于角色的权限访问控制：RBAC RBAC（Role-Based Access Control，基于角色的访问控制）， 是K8s默认授权策略，并且是动态配置策略（修改即时生效）。 主体（subject） • User：用户 • Group：用户组 • ServiceAccount：服务账号 角色 • Role：授权特定命名空间的访问权限 • ClusterRole：授权所有命名空间的访问权限 角色绑定 • RoleBinding：将角色绑定到主体（即subject） • ClusterRoleBinding：将集群角色绑定到主体 注：RoleBinding在指定命名空间中执行授权，ClusterRoleBinding在集群范围执行授权。

案例 为指定用户授权访问不同命名空间权限，例如新入职一个小弟，希望让他先熟悉K8s集群，为了安全性，先不能给他太大权限，因此先给他授权访问default命名空间Pod读取权限。 实施大致步骤： 1. 用K8S CA签发客户端证书 2. 生成kubeconfig授权文件 3. 创建RBAC权限策略 4. 指定kubeconfig文件测试权限：

kubectl get pods --kubeconfig=./aliang.kubeconfig

 操作示例 首先，我们要知道所有kubeadm安装的k8s所有配置文件存放地，在/etc/kubernetes下的pki中 一般ca即是根证书 1、用cfssl来利用ca来生成客户端证书 先将rbac.zip传到master目录并解压 将cfssl工具包也传入服务器，并直接解压到/usr/bin目录下

tar zxvf cfssl.tar.gz -C /usr/bin/

进入rbac文件

cd rbac/

进入cert进行修改

vi cert.sh

这两个对应的是用户名和根证书 直接执行

bash cert.sh

这两个即为生成的证书 接下来，生成kubectl授权文件 即，实际上我们使用kubectl命令时，是kubectl将请求发给了api，其中kubectl本身也需要配置文件。他的配置文件在/root/.kube 这里的config即是安全权限证书 回到刚刚的rbac目录，修改生成config脚本

cd /root/rbac

vi kubeconfig.sh

kubectl config set-cluster kubernetes   --certificate-authority=/etc/kubernetes/pki/ca.crt   --embed-certs=true   --server=https://192.168.209.110:6443   --kubeconfig=aliang.kubeconfig # 设置客户端认证 kubectl config set-credentials aliang   --client-key=aliang-key.pem   --client-certificate=aliang.pem   --embed-certs=true   --kubeconfig=aliang.kubeconfig # 设置默认上下文 kubectl config set-context kubernetes   --cluster=kubernetes   --user=aliang   --kubeconfig=aliang.kubeconfig

# 设置当前使用配置

kubectl config use-context kubernetes --kubeconfig=aliang.kubeconfig

集群ip需要改，证书名看需求 执行脚本生成证书

bash kubeconfig.sh

可以看到生成的证书如下

测试 我们在kubectl命令的时候引用我们刚刚生成的config

kubectl get pod --kubeconfig=aliang.kubeconfig

这个是以新生成的config来执行kubectl命令，可以看到，他报没有权限，即还未授权

授权

vi rbac.yaml

其中，role即新建的角色，roleBinding是将角色与刚刚新建的主题绑定 执行

kubectl apply -f rbac.yaml

再用之前生成的config执行get pod，发现这次就可以执行了  但deployment和svc还是不行，原因是刚刚只对pods进行了授权

案例：为指定用户授权访问不同命名空间权限 创建角色（权限集合）：

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata:   namespace: default   name: pod-reader rules: - apiGroups: [“”] # api组，例如apps组，空值表示是核心API组，像namespace、pod、service、pv、pvc都在里面   resources: [“pods”] #资源名称（复数），例如pods、deployments、services   verbs: [“get”, “watch”, “list”] # 资源操作方法

将用户与角色绑定：

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:   name: read-pods   namespace: default subjects: - kind: User # 主体   name: aliang # 主体名称   apiGroup: rbac.authorization.k8s.io roleRef: # 绑定的角色   kind: Role   name: pod-reader # 角色名称   apiGroup: rbac.authorization.k8s.io

其中，使用

kubectl api-resources

可以查看所有的组对应的功能 授权deployment 例如，刚刚的congig只能访问pods，我现在要给刚刚生成的config授权访问deployment 使用

kubectl api-resources |grep deployment

找出deployment对应的组名 第三列斜杠左侧就是组名 例如pods他的组是空的。即他在k8s的核心组里面。在rbac中以“”为表达 加入deployment组名在刚刚的rbac规则yaml上，并在资源名上写明deployment

vi rbac.yaml

kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata:   namespace: default   name: pod-reader rules: - apiGroups: ["","apps"]   resources: ["pods","deployments"]   verbs: ["get", "watch", "list"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:   name: read-pods   namespace: default subjects: - kind: User   name: aliang   apiGroup: rbac.authorization.k8s.io roleRef:   kind: Role   name: pod-reader   apiGroup: rbac.authorization.k8s.io

执行

kubectl apply -f rbac.yaml

可以看到，这次即可使用deployment，svc依旧不行 授权service 授权service的方式通上，首先，先通过命令查询service在哪个组 发现service本身就在核心组 这样只需要在资源名称中加入services即可

vi rbac.yaml

kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata:   namespace: default   name: pod-reader rules: - apiGroups: ["","apps"]   resources: ["pods","deployments","services"]   verbs: ["get", "watch", "list"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:   name: read-pods   namespace: default subjects: - kind: User   name: aliang   apiGroup: rbac.authorization.k8s.io roleRef:   kind: Role   name: pod-reader   apiGroup: rbac.authorization.k8s.io

kubectl apply -f rbac.yaml

更新，然后再使用新建证书查看service

kubectl get svc --kubeconfig=aliang.kubeconfig

验证成功

拓展 kubectl命令可以在集群网络通用内的任何服务器执行，只需要指定专门的证书，即刚刚生成的证书传到其他服务器。其他服务器也可以用此证书来操作k8s集群， 如例，将文件传到其他服务器 这样在其他服务器指定这个配置文件也可以操作集群 如果想不指定配置文件让他成为默认配置文件的话，将这个文件改名移动到kubectl默认访问路径就行

mv aliang.kubeconfig .kube/config

这样就不需要指定，默认使用