CKS认证 | Day5 供应链安全 Trivy、kubesec、Webhook
一、可信任软件供应链概述
可信任软件供应链：指在建设基础架构过程中，涉及的软件都是可信任的。在K8s领域可信软件供应链主要是指镜像，因为一些软件交付物都是镜像，部署的最小载体。
二、构建镜像Dockerfile文件优化
- 减少镜像层：一次RUN指令形成新的一层，尽量Shell命令都写在一行，减少镜像层。
- 清理无用文件：清理对应的残留数据，例如yum缓存。
- 清理无用的软件包：基础镜像默认会带一些debug工具，可以删除掉，仅保留应用程序所需软件，防止黑客利用。
- 选择最小的基础镜像：例如alpine
- 使用非root用户运行：USER指令指定普通用户
示例：构建python web镜像
FROM python
RUN useradd python
RUN mkdir /data/www -p
COPY . /data/www
RUN chown -R python /data
RUN pip install flask -i https://mirrors.aliyun.com/pypi/simple/
WORKDIR /data/www
USER python
CMD python main.py
三、镜像漏洞扫描工具：Trivy
Trivy ：是一种用于容器镜像、文件系统、Git仓库的漏洞扫描工具，适用于 CI 的简单而全面的容器漏洞扫描程序。软件漏洞是指软件或操作系统中存在的 故障、缺陷或弱点。Trivy 检测操作系统包（Alpine、RHEL、CentOS 等）和应用程序依赖 （Bundler、Composer、npm、yarn 等）的漏洞。Trivy 很容易使用，只要安装二进制文件，就可以 扫描了。扫描只需指定容器的镜像名称。与其他镜像扫描工具相比，例如 Clair，Anchore Engine， Quay 相比，Trivy 在准确性、方便性和对 CI 的支持等方面都有着明显的优势。 推荐在 CI 中使用它，在推送到 container registry 之前，你可以轻松地扫描本地容器镜像。
Trivy 具备如下的特征：
- 检测面很全，能检测全面的漏洞，操作系统软件包（Alpine、Red Hat Universal Base Image、Red Hat Enterprise Linux、CentOS、Oracle Linux、Debian、Ubuntu、Amazon Linux、openSUSE Leap、SUSE Enterprise Linux、Photon OS 和 Distrioless）、应用程序依赖项 （Bundler、Composer、Pipenv、Poetry、npm、yarn 和 Cargo）；
- 使用简单，仅仅只需要指定镜像名称；
- 扫描快且无状态，第一次扫描将在 10 秒内完成（取决于网络）。随后的扫描将在一秒钟内完成。 与其他扫描器在第一次运行时需要很长时间（大约 10 分钟）来获取漏洞信息，并鼓励你维护持久的漏洞 数据库不同，Trivy 是无状态的，不需要维护或准备；
- 易于安装测试：
项目地址：https://github.com/aquasecurity/trivy（与kube-bench出自同一家企业aqua）
下载地址：https://github.com/aquasecurity/trivy/releases/download/v0.42.0/trivy_0.42.0_Linux-64bit.tar.gz
1）下载二进制包进行安装
[root@k8s-master-1-71 ~]# mkdir trivy ; cd trivy //非必须创建目录
[root@k8s-master-1-71 trivy]# wget https://github.com/aquasecurity/trivy/releases/download/v0.42.0/trivy_0.42.0_Linux-64bit.tar.gz
[root@k8s-master-1-71 trivy]# tar -zxvf trivy_0.42.0_Linux-64bit.tar.gz
2）相关命令
- 容器镜像扫描：trivy image <镜像名> //优先扫描本地镜像，如无本地镜像则从容器仓库拉取镜像扫描
- 指定容器镜像tar包扫描：trivy image -i <镜像名.tar>
- 打印指定（高危、严重不同等级）漏洞信息： trivy image -s <告警等级> <镜像名>
- JSON格式输出并保存到文件： trivy image <镜像名> -f json -o output.json
示例：
# 对Nginx容器镜像扫描
./trivy image nginx
./trivy image -i nginx.tar# 打印指定（高危、严重）漏洞信息
./trivy image -s HIGH nginx
./trivy image -s HIGH,CRITICAL nginx# JSON格式输出并保存到文件
./trivy image nginx -f json -o /tmp/trivy-output.json例如1：对Nginx容器镜像扫描
[root@k8s-master-1-71 trivy]# ./trivy image nginx | more
2023-06-07T21:25:47.997+0800 INFO Vulnerability scanning is enabled
2023-06-07T21:25:47.998+0800 INFO Secret scanning is enabled
2023-06-07T21:25:47.998+0800 INFO If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2023-06-07T21:25:47.998+0800 INFO Please see also https://aquasecurity.github.io/trivy/v0.42/docs/secret/scanning/#recommendation for faster secret detection
2023-06-07T21:25:48.049+0800 INFO Detected OS: debian
2023-06-07T21:25:48.049+0800 INFO Detecting Debian vulnerabilities...
2023-06-07T21:25:48.148+0800 INFO Number of language-specific files: 0nginx (debian 11.2)
===================
Total: 328 (UNKNOWN: 1, LOW: 98, MEDIUM: 107, HIGH: 87, CRITICAL: 35)
# 总共328个漏洞，(未知:1，低:98，中:107，高:87，严重:35)# 漏洞对应的软件、纰漏的漏洞编号、等级的级别、当前版本、其它版本、概要及漏洞详情
┌─────────────────────┬──────────────────┬──────────┬────────────────────┬─────────────────────────┬──────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Installed Version │ Fixed Version │ Title │
├─────────────────────┼──────────────────┼──────────┼────────────────────┼─────────────────────────┼──────────────────────────────────────────────────────────────┤
│ apt │ CVE-2011-3374 │ LOW │ 2.2.4 │ │ It was found that apt-key in apt, all versions, do not │
│ │ │ │ │ │ correctly... │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2011-3374 │
├─────────────────────┼──────────────────┼──────────┼────────────────────┼─────────────────────────┼──────────────────────────────────────────────────────────────┤
│ bash │ CVE-2022-3715 │ HIGH │ 5.1-2+b3 │ │ a heap-buffer-overflow in valid_parameter_transform │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2022-3715 │
├─────────────────────┼──────────────────┼──────────┼────────────────────┼─────────────────────────┼──────────────────────────────────────────────────────────────┤
│ bsdutils │ CVE-2021-3995 │ MEDIUM │ 1:2.36.1-8 │ 2.36.1-8+deb11u1 │ util-linux: Unauthorized unmount of FUSE filesystems │
│ │ │ │ │ │ belonging to users with similar uid... │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2021-3995 │
│ ├──────────────────┤ │ │ ├──────────────────────────────────────────────────────────────┤
│ │ CVE-2021-3996 │ │ │ │ util-linux: Unauthorized unmount of filesystems in libmount │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2021-3996 │
│ ├──────────────────┼──────────┤ ├─────────────────────────┼──────────────────────────────────────────────────────────────┤
│ │ CVE-2022-0563 │ LOW │ │ │ util-linux: partial disclosure of arbitrary files in chfn │
│ │ │ │ │ │ and chsh when compiled... │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2022-0563 │
├─────────────────────┼──────────────────┤ ├────────────────────┼─────────────────────────┼──────────────────────────────────────────────────────────────┤
│ coreutils │ CVE-2016-2781 │ │ 8.32-4+b1 │ │ coreutils: Non-privileged session can escape to the parent │
│ │ │ │ │ │ session in chroot │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2016-2781 │
│ ├──────────────────┤ │ ├─────────────────────────┼──────────────────────────────────────────────────────────────┤
│ │ CVE-2017-18018 │ │ │ │ coreutils: race condition vulnerability in chown and chgrp │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2017-18018 │
├─────────────────────┼──────────────────┼──────────┼────────────────────┼─────────────────────────┼──────────────────────────────────────────────────────────────┤
...假设查看 coreutils 软件的 CVE-2016-2781 纰漏漏洞，查看漏洞详情 https://avd.aquasec.com/nvd/2016/cve-2016-2781/
例如2：并不是所有漏洞都要处理，主要修复高危漏洞即可，可通过 -s 去过滤高危漏洞
[root@k8s-master-1-71 trivy]# ./trivy image -s CRITICAL nginx | more
例如3：通过导出json格式，方便后期使用其它工具图形展示
[root@k8s-master-1-71 trivy]# ./trivy image nginx -f json -o /tmp/trivy-output.json
[root@k8s-master-1-71 trivy]# cat /tmp/trivy-output.json | more
四、检查YAML文件安全配置：kubesec
kubesec：是一个针对K8s资源清单文件进行安全配置评估的工具，根据安全配置 最佳实践来验证并给出建议。（主要检查控制器）
官网：kubesec.io :: kubesec.io
项目地址：https://github.com/controlplaneio/kubesec
下载地址：https://github.com/controlplaneio/kubesec/releases/download/v2.13.0/kubesec_linux_amd64.tar.gz
1）下载二进制包进行安装
[root@k8s-master-1-71 ~]# mkdir kubesec ; cd kubesec/ //非必须创建配置文件
[root@k8s-master-1-71 kubesec]# wget https://github.com/controlplaneio/kubesec/releases/download/v2.13.0/kubesec_linux_amd64.tar.gz
[root@k8s-master-1-71 kubesec]# tar zxvf kubesec_linux_amd64.tar.gz
2）相关命令
- 检查YAML配置文件：./kubesec scan deployment.yaml
- 使用容器环境执行检查：docker run -i kubesec/kubesec scan /dev/stdin < deployment.yaml
kubesec内置一个HTTP服务器，可直接启用，并远程调用：
- 二进制 ：kubesec http 8080 &
- Docker容器 ：docker run -d -p 8080:8080 kubesec/kubesec http 8080
示例：通过curl将本地的yaml文件提交给kubesec内置的HTTP服务器去进行安全配置评估
curl -sSX POST --data-binary @deployment.yaml http://192.168.1.71:8080/scan例如1：检查deploy-test-kubesec.yaml配置文件
[root@k8s-master-1-71 kubesec]# kubectl create deployment web --image=nginx --dry-run=client -o yaml > deploy-test-kubesec.yaml
[root@k8s-master-1-71 kubesec]# ./kubesec scan deploy-test-kubesec.yaml
[{"object": "Deployment/web.default","valid": true,"fileName": "deploy-test-kubesec.yaml","message": "Passed with a score of 0 points","score": 0,"scoring": {"advise": [{"id": "ApparmorAny", # 是否配置Apparmor"selector": ".metadata .annotations .\"container.apparmor.security.beta.kubernetes.io/nginx\ "","reason": "Well defined AppArmor policies may provide greater protection from unknown threat s. WARNING: NOT PRODUCTION READY","points": 3},{"id": "ServiceAccountName", # 是否配置ServiceAccountName"selector": ".spec .serviceAccountName","reason": "Service accounts restrict Kubernetes API access and should be configured with lea st privilege","points": 3},{"id": "SeccompAny", # 是否配置Seccomp"selector": ".metadata .annotations .\"container.seccomp.security.alpha.kubernetes.io/pod\"" ,"reason": "Seccomp profiles set minimum privilege and secure against unknown threats","points": 1},{"id": "LimitsCPU", # 是否配置LimitsCPU"selector": "containers[] .resources .limits .cpu","reason": "Enforcing CPU limits prevents DOS via resource exhaustion","points": 1},{"id": "LimitsMemory", # 是否配置LimitsMemory"selector": "containers[] .resources .limits .memory","reason": "Enforcing memory limits prevents DOS via resource exhaustion","points": 1},{"id": "RequestsCPU", # 是否配置RequestsCPU"selector": "containers[] .resources .requests .cpu","reason": "Enforcing CPU requests aids a fair balancing of resources across the cluster","points": 1},{"id": "RequestsMemory", # 是否配置RequestsMemory"selector": "containers[] .resources .requests .memory","reason": "Enforcing memory requests aids a fair balancing of resources across the cluster","points": 1},{"id": "CapDropAny", # 是否配置CapDropAny"selector": "containers[] .securityContext .capabilities .drop","reason": "Reducing kernel capabilities available to a container limits its attack surface","points": 1},{"id": "CapDropAll", # 是否配置CapDropAll"selector": "containers[] .securityContext .capabilities .drop | index(\"ALL\")","reason": "Drop all capabilities and add only those required to reduce syscall attack surfac e","points": 1},{"id": "ReadOnlyRootFilesystem", # 是否配置ReadOnlyRootFilesystem"selector": "containers[] .securityContext .readOnlyRootFilesystem == true","reason": "An immutable root filesystem can prevent malicious binaries being added to PATH a nd increase attack cost","points": 1},{"id": "RunAsNonRoot", # 是否配置非root用户运行"selector": "containers[] .securityContext .runAsNonRoot == true","reason": "Force the running image to run as a non-root user to ensure least privilege","points": 1},{"id": "RunAsUser", # 是否配置指定普通用户运行"selector": "containers[] .securityContext .runAsUser -gt 10000","reason": "Run as a high-UID user to avoid conflicts with the host's user table","points": 1}]}}
]或者使用容器环境执行检查：
[root@k8s-master-1-71 kubesec]# docker run -i kubesec/kubesec scan /dev/stdin < deploy-test-kubesec.yaml
例如2：通过curl将本地的yaml文件提交给kubesec内置的HTTP服务器去进行安全配置评估调用
[root@k8s-master-1-71 kubesec]# ./kubesec http 8080 &
[3] 11348[root@k8s-master-1-71 kubesec]# curl -sSX POST --data-binary @deploy-test-kubesec.yaml http://192.168.1.71:8080/scan
五、准入控制器： Admission Webhook
Admission Webhook：准入控制器Webhook是准入控制插件的一种，用于拦截所有向APISERVER发送的 请求，并且可以修改请求或拒绝请求。
Admission webhook 为开发者提供了非常灵活的插件模式，在kubernetes资源持久化之前，管理员通过程序 可以对指定资源做校验、修改等操作。例如为资源自动打标签、pod设置默认SA，自动注入sidecar容器等。
补充：webhook 可以理解为一个简单的API，负责处理一些简单的事件。
1、相关Webhook准入控制器：
1）MutatingAdmissionWebhook：修改资源，理论上可以监听并修改任何经过ApiServer处理的请求
解释：创建的任何资源都可以进行拦截去修改再去部署，比如创建Deployment、Service的YAML文件（实际就是JSON文）提交给API，如果应用了Webhook，APISERVER会负责将用户转发的JSON文件发送给WebhookAPI，通过拿到的文件往里面添加或修改字段，然后再返回给这个准入控制器，就可以再次部署完成后续操作。
2）ValidatingAdmissionWebhook：验证资源是否满足（true / false）
解释：同上，用户提交给APISERVER的任何资源，通过转发到WebhookAPI进行处理、验证资源是否能用，返回true / false
3）ImagePolicyWebhook：镜像策略，主要验证镜像字段是否满足条件
解释：APISERVER将用户提交的资源，且只将镜像contained部分，转发到WebhookAPI进行处理，主要针对镜像字段。
工作流程图：
六、准入控制器： ImagePolicyWebhook
工作流程图：
解释：用户通过kubectl提交创建Deployment资源到kube-apiserver，kube-apiserver通过启用插件去调用ImagePolicyWebhook（既然配置了Webhook，肯定要配置镜像策略服务器API），将客户创建的资源中image镜像字段，通过POST方式去提交到自签证书的HTTPS镜像策略服务器，镜像策略服务器拿到信息去判断该镜像地址是否为可信任的，经过定义的策略逻辑处理，返回一个值true or false。
补充：
1.自签证书：携带ca根证书，颁发的客户端证书。（免费，有效期限制，需要验证）
2.权威域名证书，（不免费，有效期长）
步骤1：准备配置文件 admission_configuration.yaml（声明连接Webhook的信息）—> 在启用API时指定文件
[root@k8s-master-1-71 ~]# mkdir /etc/kubernetes/image-policy/ # 创建配置文件目录# vi /etc/kubernetes/image-policy/admission_configuration.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook # 声明使用的ImagePolicyWebhookconfiguration:imagePolicy:kubeConfigFile: /etc/kubernetes/image-policy/connect_webhook.yaml # 连接webhook镜像策略服务器配置文件allowTTL: 50 # 控制批准请求的缓存时间，单位秒denyTTL: 50 # 控制拒绝请求的缓存时间，单位秒retryBackoff: 500 # 控制重试间隔，单位毫秒defaultAllow: true # 确定webhook后端失效时的行为（比如webhook挂了，依旧运行deply部署）步骤2：准备配置文件 connect_webhook.yaml（声明连接镜像策略服务器地址）
# vi /etc/kubernetes/image-policy/connect_webhook.yaml
apiVersion: v1
kind: Config
clusters:
- cluster:certificate-authority: /etc/kubernetes/image-policy/ssl/webhook.pem # 数字证书，用于验证远程服务server: https://192.168.1.73:8080/image_policy # 需搭建服务去提供镜像策略服务器地址，必须是httpsname: webhook
contexts:
- context:cluster: webhookuser: apiservername: webhook
current-context: webhook
preferences: {}
users:
- name: apiserveruser:client-certificate: /etc/kubernetes/image-policy/ssl/apiserver-client.pem # webhook准入控制器使用的证书client-key: /etc/kubernetes/image-policy/ssl/apiserver-client-key.pem # 对应私钥证书步骤3：生成客户端证书
[root@k8s-master-1-71 ~]# mkdir /etc/kubernetes/image-policy/ssl
# vi /etc/kubernetes/image-policy/ssl/image-policy-certs.sh
cat > ca-config.json <<EOF # 根证书配置文件
{"signing": {"default": {"expiry": "87600h"},"profiles": {"kubernetes": {"expiry": "87600h","usages": ["signing","key encipherment","server auth","client auth"]}}}
}
EOFcat > ca-csr.json <<EOF # 根证书请求配置文件
{"CN": "kubernetes","key": {"algo": "rsa","size": 2048},"names": [{"C": "CN","L": "Beijing","ST": "Beijing"}]
}
EOFcfssl gencert -initca ca-csr.json | cfssljson -bare ca - # 初始化生成根证书密钥
--------------------------------------------------------------------------------cat > webhook-csr.json <<EOF # 客户端请求配置文件
{"CN": "webhook","hosts": ["192.168.1.73" # webhook运行web服务器的地址（https）],"key": {"algo": "rsa","size": 2048},"names": [{"C": "CN","L": "BeiJing","ST": "BeiJing"}]
}
EOFcfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes webhook-csr.json | cfssljson -bare webhook
--------------------------------------------------------------------------------cat > apiserver-client-csr.json <<EOF # apiserver客户端请求配置文件
{"CN": "apiserver","hosts": [],"key": {"algo": "rsa","size": 2048},"names": [{"C": "CN","L": "BeiJing","ST": "BeiJing"}]
}
EOFcfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes apiserver-client-csr.json | cfssljson -bare apiserver-client[root@k8s-master-1-71 ssl]# sh image-policy-certs.sh //执行证书生成脚本
[root@k8s-master-1-71 ssl]# ls
apiserver-client.csr apiserver-client.pem ca-csr.json image-policy-certs.sh webhook-key.pem
apiserver-client-csr.json ca-config.json ca-key.pem webhook.csr webhook.pem
apiserver-client-key.pem ca.csr ca.pem webhook-csr.json
步骤4：修改kube-apiserver.yaml
- 启用准入控制插件，默认没有启用；
- 其次指定连接webhook镜像策略服务器配置文件；
- 创建数据卷，将宿主机 /etc/kubernetes/image-policy 目录挂载到容器中。
# vi /etc/kubernetes/manifests/kube-apiserver.yaml- --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook- --admission-control-config-file=/etc/kubernetes/image-policy/admission_configuration.yaml
...volumeMounts:- mountPath: /etc/kubernetes/image-policy/ # 容器挂载目录name: policyreadOnly: true...volumes:- hostPath:path: /etc/kubernetes/image-policy/ # 指定宿主机挂载到容器的目录type: DirectoryOrCreatename: policy
...
注意：kube-apiserver是通过静态Pod的方式启动，容器指定的admission-control-config-file的文件路径，需使用 hostpath 数据卷将宿主机 /etc/kubernetes/image-policy 目录挂载到容器中。
步骤5：部署镜像服务器（192.168.1.73测试）
自己用python开发一个简单的webhook端点服务器，作用是拒绝部署的镜像没有指定标签（即latest）。
- 自签HTTPS证书
- Docker容器启动镜像策略服务
方式1：本地构建docker容器
提前拷贝证书到部署镜像服务器
[root@k8s-master-1-71 image-policy]# scp ssl/webhook-key.pem ssl/webhook.pem root@192.168.1.73:~# 查看文件
[root@k8s-node2-1-73 ~]# cd image-policy-webhook/ ; ls
Dockerfile main.py webhook-key.pem webhook.pem[root@k8s-node2-1-73 ~]# vi Dockerfile
FROM python
RUN useradd python
RUN mkdir /data/www -p
COPY . /data/www
RUN chown -R python /data
RUN pip install flask -i https://mirrors.aliyun.com/pypi/simple/
WORKDIR /data/www
USER python
CMD python main.py--------------------------------------------------------------------------------
[root@k8s-node2-1-73 ~]# vi main.py
from flask import Flask,request
import jsonapp = Flask(__name__)@app.route('/image_policy',methods=["POST"]) # API地址为image_policy，只接受Post请求
def image_policy():post_data = request.get_data().decode() # 拿到用户提交过来的数据#print("POST数据: %s" %post_data)data = json.loads(post_data) # 解析数据为data对象for c in data['spec']['containers']:if ":" not in c['image'] or ":latest" in c['image']: # 如果镜像里不带冒号或者带:latest说明是镜像使用latest标签allowed, reason = False, "检查镜像失败！镜像标签不允许使用latest!"breakelse:allowed, reason = True, "检查镜像通过."print("检查结果: %s" %reason)result = {"apiVersion": "imagepolicy.k8s.io/v1alpha1","kind": "ImageReview","status": {"allowed": allowed,"reason": reason}}return json.dumps(result,ensure_ascii=False)if __name__ == "__main__":app.run(host="0.0.0.0",port=8080,ssl_context=('/data/www/webhook.pem','/data/www/webhook-key.pem'))[root@k8s-node2-1-73 image-policy-webhook]# docker build -t image-policy-webhook:v1 .
[root@k8s-node2-1-73 image-policy-webhook]# docker run -d --name=testpod -p 8080:8080 image-policy-webhook:v1
[root@k8s-node2-1-73 image-policy-webhook]# docker ps -l //查看容器的进程方式2：远程下载容器镜像
[root@k8s-node2-1-73 ~]# docker run -d -u root --name=image-policy-webhook \
-v $PWD/webhook.pem:/data/www/webhook.pem \
-v $PWD/webhook-key.pem:/data/www/webhook-key.pem \
-e PYTHONUNBUFFERED=1 -p 8080:8080 \
lizhenliang/image-policy-webhook
b35346f0d88e505173512614dfd65df0ad8ca78bf3f99d7914a0518fd4c217ed# 查看容器
[root@k8s-node2-1-73 image-policy-webhook]# docker images | grep webhook
lizhenliang/kube-webhook-certgen v1.1.1 c41e9fcadf5a 20 months ago 47.7MB
lizhenliang/image-policy-webhook latest e0b35b385b82 23 months ago 897MB
测试
kubectl create deployment web1 --image=nginx:1.16
kubectl create deployment web2 --image=nginx
docker logs b35346f0d -f
补充Docker知识：
Docker rmi
docker rmi 通过镜像的 ID 删除镜像。
要删除镜像，首先需要列出所有镜像以获取镜像的 ID，镜像的名称和其他详细信息。 运行简单的命令 docker images -a 或 docker images。
之后，明确要删除哪个镜像，然后执行简单命令 docker rmi <your-image-id>。然后，列出所有镜像并检查，可以确认镜像是否已删除。一次删除多张镜像
当你要一次删除多张镜像时，可以使用一种方法。首先只需列出镜像即可获取镜像的 ID，然后执行简单的命令：
docker rmi <your-image-id> <your-image-id> ...
列出镜像的 ID，每个 ID 之间留一个空格。一次删除所有镜像
要删除所有镜像，有一个简单的命令可以做到：docker rmi $(docker images -q)。
在上面的命令中，有两个命令，第一个在 $() 中执行的命令是 shell 语法，返回以该执行的结果。然后，-q- 是一个选项，用于返回唯一的 ID。$() 返回镜像 ID 的结果，然后 docker rmi 删除所有这些镜像。
小结
本篇为 【Kubernetes CKS认证 DAY5】的开篇学习笔记，希望这篇笔记可以让您初步了解到 构建镜像Dockerfile文件优化、镜像漏洞扫描工具：Trivy、检查YAML文件安全配置：kubesec、准入控制器： Admission Webhook、准入控制器： ImagePolicyWebhook的使用，不妨跟着我的笔记步伐亲自实践一下吧！
Tip：毕竟两个人的智慧大于一个人的智慧，如果你不理解本章节的内容或需要相关笔记、视频，可私信小安，请不要害羞和回避，可以向他人请教，花点时间直到你真正的理解。