k8s安全框架

k8s安全框架K8S安全控制框架主要由下面3个阶段进行控制，通过API Server配置来启用插件：1. Authentication（鉴权）2. Authorization（授权）3. Admission Control（准入控制）整个k8s的操作流程如下K8s Apiserver提供三种客户端身份认证：• HTTPS 证书认证：基于CA证书签名的数字证书认证（kubeconfig）• HTTP

江南道人

989人浏览 · 2022-05-06 09:17:57

江南道人 · 2022-05-06 09:17:57 发布

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

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

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub