K8s进阶6——pod安全上下文，腾讯T2亲自教你

概念：

• PodSecurityPolicy，简称PSP，是K8s中Pod部署时重要的安全校验手段，能够有效地约束应用运行时行为安全。
• 使用PSP对象定义一组Pod在运行时必须遵循的条件及相关字段的默认值，只有Pod满足这些条件才会被K8s接受。
• Pod安全策略实现为一个准入控制器，默认没有启用，当启用后会强制实施Pod安全策略，没有满足的Pod将无法创建。因此，建议在启用PSP之前先添加策略并对其授权。

启用Pod安全策略：

1. kube-apiserver.yaml配置文件添加准入控制器。
2. 重启kubelet，systemctl restart kubelet
   

玩法思路：

1. 创建SA服务账号。
2. 将SA绑定到系统内置Role edit。
3. 创建使用PSP权限的Role qingjun。
4. 将SA绑定到角色qingjun上。
5. 定义PodSecurityPolicy策略。

注意事项：

1. 使用复杂，权限模型存在缺陷，控制不明确，一旦出现问题不好定位，所以将再1.21版本弃用PSP，在1.25版本删除PSP。 弃用官方文献
2. 替代方案KEP 2579。
3. 替代外部控制器方案：K-Rail、 Kyverno、 OPA/Gatekeeper 。

2.1.1 安全策略限制维度

2.2 OPA Gatekeeper方案

前提了解：

• OPA（Open Policy Agent）：是一个开源的、通用策略引擎，可以将策略编写为代码。提供一个种高级声明性语言-Rego来编写策略，并把决策这一步骤从复杂的业务逻辑中解耦出来。
• 是PSP的替代方案，属于外部准入控制器。
• OPA官网
• Gatekeeper项目地址
• Gatekeeper文档

OPA可以用来做什么？

1. 拒绝不符合条件的YAML部署。
2. 允许使用哪些仓库中的镜像。
3. 允许在哪个时间段访问系统。
4. 等等。

OPA Gatekeeper的概念：

• Gatekeeper 是基于 OPA的一个 Kubernetes 策略解决方案，可替代PSP或者部分RBAC功能。因为OPA与K8s对接偏向于底层，不好使用，所以社区就基于OPA引擎开发了OPA Gatekeeper的解决方案，方便使用。
• 当在集群中部署了Gatekeeper组件，APIServer所有的创建、更新或者删除操作都会触发Gatekeeper来处理，如果不满足策略则拒绝。

工作流程图：

2.2.1 安装Gatekeeper

1.下载准备安装yaml文件，下载地址

2.导入文件一键部署，并查看。

[root@k8s-master1 opa]# kubectl apply -f gatekeeper.yaml

2.2.2 编写策略

Gatekeeper的策略由两个资源对象组成：

1. Template模板：在后面我们需要自定义限制策略，策略是怎么实现的就需要我们先写一个实现逻辑，这里就把这个实现逻辑称之为模板，使用rego语言。
2. Contsraint约束：自定义限制策略，当我们创建任何一个资源时可以先通过这个约束来进行过滤处理，违反约束就代表能限制你创建自动动作，不让你创建这个资源。所以约束就是负责K8s资源对象的过滤或者为Template模板提供输入参数。

实现思路：

1. 先使用rego语言编写Template模板，在这个模板里自定义实现逻辑，就相当于写一个脚本逻辑。
2. 自定义Constraint约束，约束格式类似rbac授权那种，要限制什么资源，这个资源在什么组。
3. 当我们创建一个资源时，比如创建deployment时，若是触发了约束，则就会带入到模板里，看是否能违反约束，若是违反约束就相当于出发了开关，不让你创建deployment。

模板核心字段释义：

• 字段containers = input.review.object.spec.template.spec.containers
  • input.review.object ：抓取约束模板里自定义的限制资源。比如我在约束模板里限制deployment资源，这里就是是抓取的deployment资源。
  • .spec.template.spec.containers：代表获取资源对象的yaml文件里.spec.template.spec.containers内容，可以用kubectl explan获取。比如我在约束模板里限制的是deployment资源，那么当我创建deployment资源时就会抓取deployment.yaml文件里的spec.template.spec.containers下的内容，如下图，就是获取下图中的红框内容。此时拿到这块内容，再根据模板里的逻辑进行判断，看最后是否输出的true，若是则代表违反约束，你就不能创建deployment资源。
    

2.2.3 案例1

需求：

• 禁止容器启用特权。若用户创建的资源里有开启特权容器参数，则限制用户不能创建资源。

实现代码逻辑：

• violation函数返回的是布尔值True或者False。我取deployment.yaml文件里的特权容器参数，若返回值为false，则不会继续往下执行函数，属于放行不做拦截；若返回值为true，则说明整个函数表达式已通过，代表违反约束需要拦截，就相当于触碰到开关起到拦截作用。

1.编写模板和约束，在模板里使用rego脚本匹配约束里面的的资源。

##模板
[root@k8s-master1 opa]# cat privileged_tpl.yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: qingjun
spec:
crd:
spec:
names:
kind: qingjun
targets:

• target: admission.k8s.gatekeeper.sh
  rego: | ##自定义匹配策略，使用rego语言编写。
  package admission ##传入一个依赖包，唯一的，类似命名空间。
  violation[{“msg”: msg}] { ##定义一个key-value变量。
  containers = input.review.object.spec.template.spec.containers ##获取自定义对象的pod.yaml里对应的字段。
  c_name := containers[0].name ##获取第一个容器名称并赋予变量名为c_name，0代表第一个。
  containers[0].securityContext.privileged ##获取第一个容器的securityContext.privileged值。这里是判断返回是否为true，返回true说明违反约束。
  msg := sprintf(“提示：'%v’容器禁止启用特权！”,[c_name]) ##打印结果。
  }
  [root@k8s-master1 opa]# kubectl apply -f privileged_tpl.yaml

##约束
[root@k8s-master1 opa]# cat privileged_constraints.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: qingjun
metadata:
name: baimu
spec:
match:
kinds:

• apiGroups: [“apps”]
  kinds:
• “Deployment”
• “DaemonSet”
• “StatefulSet”
  [root@k8s-master1 opa]# kubectl apply -f privileged_constraints.yaml

2.测试一，当创建deployment资源时，没有匹配到“securityContext.privileged: true” 字段，说明该容器没有启用特权，可以正常创建，没有违反约束，所以最后可以正常创建deploy。

3.测试二，当创建deployment资源时，匹配到“securityContext.privileged: false ”字段，说明没有开启特权容器，最后可以正常创建deploy。

4.测试三，当创建deployment资源时，匹配到“securityContext.privileged: true”字段，说明容器需要开启特权，需要限制不能开启，所以最后不能创建deployment资源。

5.修改deploy.yaml容器名称，最后会打印出详细错误信息，方便测试。

2.2.4 案例2

需求：

• 只允许使用特定的镜像仓库。

实现代码逻辑：

• violation函数返回的是布尔值True或者False。我取deployment.yaml文件里的容器名前缀参数，若返回值为false，则不会继续往下执行函数，属于放行不做拦截；若返回值为true，则说明整个函数表达式已通过，代表违反约束需要拦截，就相当于触碰到开关起到拦截作用。

1.编写模板和约束。在约束里指定要限制的字段，这里就是限制只能拉取192.168.130.152/qingjun个人仓库的镜像，然后再把参数传入到模板里。

##模板。
[root@k8s-master1 test2]# cat image-check_tpl.yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: image-check
spec:
crd:
spec:
names:
kind: image-check
validation:
openAPIV3Schema:
properties: ##接受约束传过来的参数prefix值。
prefix:
type: string
targets:

• target: admission.k8s.gatekeeper.sh
  rego: |
  package image
  violation[{“msg”: msg}] {
  containers = input.review.object.spec.template.spec.containers ##获取containers下的内容。
  image := containers[0].image ##获取镜像名。
  not startswith(image, input.parameters.prefix) ##input.parameters.prefix获取约束中的参数，并和image比较，判断两者是否相同为true。
  msg := sprintf(“提示：'%v’镜像地址不在可信任仓库！”, [image])
  }

##函数逻辑释义：
1、startswith(qingjun/flask-demo:v4， qingjun/) ，两者比较相等，输入值为true。
2、startswith(192.168.130.152/qingjun/， qingjun/) ，两者比较不相等，输出值为false。
3、startswith(A，B)，当A=B，则为true，此时会拦截，所以跟我们想要的结果相反，需要把输出值变成false才能放行，所以前面加个not取反即可。
4、not sartswith(qingjun/flask-demo:v4, qingjun/) ，对输出值取反，最终返回false，放行不拦截。
5、not startswith(192.168.130.152/qingjun/，qingjun/)，对输出值取反，最红返回true，不放行会拦截。

##约束。
[root@k8s-master1 test2]# cat image-check_constraints.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: image-check
metadata:
name: image-check
spec:
match:
kinds:

• apiGroups: [“apps”]
  kinds:
• “Deployment”
• “DaemonSet”
• “StatefulSet”
  parameters: # 传递给opa的参数
  prefix: “192.168.130.152/qingjun” ##镜像前缀，仓库名称。

2.先导入模板，再导入约束测试效果。拉取公共仓库的镜像直接拦截，拉取192.168.130.152/qingjun/个人仓库的镜像可以创建成功。

[root@k8s-master1 test2]# kubectl apply -f image-check_tpl.yaml
[root@k8s-master1 test2]# kubectl apply -f image-check_constraints.yaml

三、gVisor

前提了解：

• 容器的应用程序可以直接访问Linux内核的系统调用，容器在安全隔离上还是比较弱，虽然内核在不断地增强自身的安全特性，但由于内核自身代码极端复杂，CVE 漏洞层出不穷。所以要想减少这方面安全风险，就是做好安全隔离，阻断容器内程序对物理机内核的依赖。
• Google开源的一种gVisor容器沙箱技术就是采用这种思路，gVisor隔离容器内应用和内核之间访问，提供了大部分Linux内核的系统调用，巧妙的将容器内进程的系统调用转化为对gVisor的访问。
• gVisor兼容OCI，与Docker和K8s无缝集成，很方面使用。
• 项目地址

gVisor 组件架构图：

• Runsc 是一种 Runtime 引擎，负责容器的创建与销毁。
• Sentry 负责容器内程序的系统调用处理。
• Gofer 负责文件系统的操作代理，IO 请求都会由它转接到 Host 上。
  

作用原理：

1.1 gVisor与Docker集成

前提了解：

• gVisor内核要求：Linux 3.17以上版本。
• 如果用的是Centos7则需要升级内核，Ubuntu不需要。
• docker使用的Runtime引擎是runc，与gVisor集成后就可以支持runsc。使用默认runc创建的容器内核是宿主机的内核，没有隔离，使用runsc创建的容器内核时gvisor模拟创建的内核，是与宿主机内核隔离起来了。
  

CentOS7内核升级步骤：

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install kernel-ml-devel kernel-ml –y
grub2-set-default 0
reboot
uname -r

3.1.1 内核版本升级

1.升级前内核版本。

2.安装一个源。

[root@k8s-master1 ~]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
[root@k8s-master1 ~]# rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm

3.升级内核一个包，指定使用刚才安装的那个源，源里面有最新的内核包。

[root@k8s-master1 ~]# yum --enablerepo=elrepo-kernel install kernel-ml-devel kernel-ml –y

4.设置开机自启，并重启系统查看当前内核版本。

[root@k8s-master1 ~]# grub2-set-default 0
[root@k8s-master1 ~]# reboot

3.1.2 安装gvisor

1.集成之前，docker只支持默认的runc。

2.准备二进制文件，官方参考地址。

[root@k8s-master2 ~]# cat test.sh
set -e
ARCH=$(uname-m)URL=https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH}
wget ${URL}/runsc ${URL}/runsc.sha512
${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512

[root@k8s-master2 ~]# sh test.sh

3.配置环境变量，并将runsc集成到docker配置文件里。

[root@k8s-master1 gvisor]# mv runsc /usr/local/bin/
[root@k8s-master1 gvisor]# chmod +x /usr/local/bin/runsc

[root@k8s-master1 gvisor]# runsc install

4.修改docker配置文件，去掉systemctl ，因为gvisor与systemctl不兼容，去掉之后的配置如下。

[root@k8s-master1 gvisor]# cat /etc/docker/daemon.json
{
“registry-mirrors”: [
“https://b9pmyelo.mirror.aliyuncs.com”
],
“runtimes”: {
“runsc”: {
“path”: “/usr/local/bin/runsc”
}
}
}

5.重启docker，再次查看docker就支持runsc了。

3.1.3 docker中验证

1.先用默认的runc创建一个容器，进去查看容器内核版本，现实的是宿主机的内核版本。

[root@k8s-master1 gvisor]# docker run -d --name=qingjun_1 nginx
[root@k8s-master1 gvisor]# docker exec -it qingjun_1 /bin/bash

2.再使用runsc创建一个容器，进入查看容器里的内核不再是宿主机的内核版本，而是gvisor自己模拟的内核，容器内所有的命令操作系统调用都是发送给模拟出来的内核，然后有它再转发到实际的宿主机内核。

3.1.4 兼容服务

注意事项：

• gvisor也存在兼容问题，并不是所有的容器都可以很好的使用此技术方案，目前支持的服务如下：
• 查看地址
  

3.2 与Containerd集成

• 注意：这里我是在K8s集群中第二个节点测试的，同样要保证系统内核版本。

3.2.1 切换containerd容器引擎

1.准备配置，若是直接使用docker容器引擎的，则可以忽略这步，在搭建k8s集群时已经配置了。

cat > /etc/sysctl.d/99-kubernetes-cri.conf << EOF
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sysctl -system

2.安装containerd，安装docker时已经给装上了，若没有装需要安装一下。

cd /etc/yum.repos.d
wget http://mirrors.aliyun.com/dockerce/linux/centos/docker-ce.repo
yum install -y containerd.io

3.准备runsc二进制文件，安装gvisor。

[root@k8s-master2 gv]# mv runsc /usr/local/bin/
[root@k8s-master2 gv]# mv containerd-shim-runsc-v1 /usr/local/bin/
[root@k8s-master2 gv]# chmod +x /usr/local/bin/runsc
[root@k8s-master2 gv]# chmod +x /usr/local/bin/containerd-shim-runsc-v1

4.生成配置文件，修改相关参数。

containerd config default > /etc/containerd/config.toml

参数一：修改pause镜像地址，修改成国内地址，方便拉取。

sandbox_image = “registry.aliyuncs.com/google_containers/pause:3.2”

参数二：Cgroup驱动改为systemd，可选项。

SystemdCgroup = true

参数三：增加runsc容器运行时，注意需要安装gvisor，且需要安装gvisor时的那两个文件。

[plugins.“io.containerd.grpc.v1.cri”.containerd.runtimes.runsc]
runtime_type = “io.containerd.runsc.v1”

参数四：配置docker镜像加速器。

https://b9pmyelo.mirror.aliyuncs.com

5. 重启containerd，配置kubelet使用containerd。

[root@k8s-master2 pod]# systemctl restart containerd

#可以使用默认的，修改成containerd即可。
[root@k8s-master2 pod]# cat /var/lib/kubelet/kubeadm-flags.env
unix:///run/containerd/containerd.sock

#也可以再生成定义一个。
vi /etc/sysconfig/kubelet
KUBELET_EXTRA_ARGS=–container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock --cgroup-driver=systemd

#重启
[root@k8s-master2 pod]# systemctl restart kubelet

5.检查。

6.准备crictl连接containerd配置文件。containerd也有 ctr 管理工具，但功能比较简单，一般使用crictl工具检查和调试容器。

cat > /etc/crictl.yaml << EOF
runtime-endpoint: unix:///run/containerd/containerd.sock
EOF

7.命令查看。

3.2.2 验证 （K8s使用gVisor运行容器）

• RuntimeClass 是一个用于选择容器运行时配置的特性，容器运行时配置用于运行 Pod 中的容器。

1.创建runtimeclass策略。

[root@k8s-master2 pod]# cat runtimeclass.yaml

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数网络安全工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注网络安全获取）

还有兄弟不知道网络安全面试可以提前刷题吗？费时一周整理的160+网络安全面试题，金九银十，做网络安全面试里的显眼包！

王岚嵚工程师面试题（附答案），只能帮兄弟们到这儿了！如果你能答对70%，找一个安全工作，问题不大。

对于有1-3年工作经验，想要跳槽的朋友来说，也是很好的温习资料！

【完整版领取方式在文末！！】

93道网络安全面试题

内容实在太多，不一一截图了

黑客学习资源推荐

最后给大家分享一份全套的网络安全学习资料，给那些想学习 网络安全的小伙伴们一点帮助！

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

1️⃣零基础入门

① 学习路线

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

② 路线对应学习视频

同时每个成长路线对应的板块都有配套的视频提供：

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算

伴们一点帮助！

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

1️⃣零基础入门

① 学习路线

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

② 路线对应学习视频

同时每个成长路线对应的板块都有配套的视频提供：

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算