安全学习路径：身份、主机、供应链与运行时
使用方式
安全不是“装一个扫描器”，而是身份、权限、边界、供应链、检测和合规的组合。这条路径按“谁能做什么 → 主机怎么加固 → 制品是否可信 → 运行时如何发现”推进。
四个阶段按依赖顺序排列，每个阶段建议留 3–4 小时：
- 先读：读页面时标记三件事：保护对象、攻击面、检测信号。
- 再做：只在隔离环境做实验，涉及提权、防火墙和审计规则的改动要先快照。
- 后测：能说清每个控制是预防、检测还是响应，以及它挡不住什么。
安全控制要能回答“失败了会怎样”。只配置不验证，等于没有控制。
阶段一：身份与权限
目标：能回答“谁在什么条件下，对什么资源，能做什么”，并区分认证、授权和审计。
阅读顺序：
- sudo — 提权规则、命令白名单和环境保留的风险。
- ssh — 密钥认证、代理转发、端口转发和跳板。
- pam — 认证栈、密码策略、失败锁定和会话限制。
- sshd — 禁用密码登录、限制用户和算法配置。
- rbac — Role、ClusterRole、Binding 和 verbs/resources 的组合。
- serviceaccount — 工作负载身份、令牌投射和权限边界。
- kubeconfig — 上下文、证书、token 和集群切换。
- workload-identity — 用云身份替代长期静态密钥。
- ssh-cheatsheet — SSH 配置和排障速查。
- linux-permission-cheatsheet — 权限位、ACL 和特殊位速查。
动手任务：审计本机 sudo 规则和 SSH 认证方式；在测试集群创建一个只能读取指定命名空间 Pod 的 ServiceAccount，并用 kubectl auth can-i 验证边界。
sudo -l
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication'
kubectl create namespace demo
kubectl create serviceaccount reader -n demo
kubectl create role pod-reader --verb=get,list --resource=pods -n demo
kubectl create rolebinding reader --role=pod-reader --serviceaccount=demo:reader -n demo
kubectl auth can-i list pods -n demo --as=system:serviceaccount:demo:reader
过关标准：
- 能区分认证、授权和审计，知道 401 和 403 分别意味着什么。
- 能读懂一条 RBAC 规则覆盖哪些资源和动作，而不是只看名字。
- 知道 ServiceAccount 令牌、kubeconfig 证书和云工作负载身份的有效期与泄露后果。
阶段二：主机加固
目标：减少主机暴露面，建立基线、审计和入侵检测，能发现异常提权、文件篡改和暴力破解。
阅读顺序：
- auditd — 审计规则、命令执行、文件访问和日志检索。
- fail2ban — 登录失败检测、封禁策略和误封风险。
- openscap — SCAP 基线扫描、CIS 配置检查和报告。
- lynis — 主机加固审计和建议项。
- aide — 文件完整性基线、哈希数据库和定期校验。
- rkhunter — rootkit 特征扫描和误报处理。
- selinux-denied — 强制访问控制拒绝的排查方式。
- iptables — 包过滤、状态匹配和规则顺序。
- ufw — 简化防火墙管理，以及它和底层规则的关系。
- firewall-cmd — firewalld 区域、服务和运行时/永久配置。
动手任务：在测试机上跑一次 Lynis 和 OpenSCAP 基线，给敏感文件加一条 audit 规则，用 AIDE 建基线后修改文件验证告警，再配置 fail2ban 观察一次封禁。
sudo lynis audit system
sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis --results report.xml ssg-debian12-ds.xml
sudo auditctl -w /etc/passwd -p wa -k identity
sudo aideinit && sudo aide --check
sudo fail2ban-client status sshd
过关标准：
- 能区分预防控制（防火墙、SELinux）和检测控制（auditd、AIDE、rkhunter）。
- 能写出一条审计规则，并知道
-w、-p、-k 的含义。
- 知道 SELinux 的 enforcing、permissive 和 disabled 三种状态对排障的影响。
阶段三：容器与供应链
目标：让镜像、依赖和构建过程可验证，并用准入策略阻止不合格制品进入集群。
阅读顺序：
- trivy — 镜像、文件系统、IaC 和 SBOM 扫描。
- cosign — 签名、验证、密钥对和 keyless 模式。
- kyverno — 用 Kubernetes 原生策略做校验、变更和生成。
- gatekeeper — OPA/Rego 约束模板和准入控制。
- grype — 基于 SBOM 的漏洞匹配和严重度。
- syft — 生成 SBOM，覆盖镜像和文件系统。
- gitleaks — 在提交和历史中检测密钥泄露。
- semgrep — 源码静态分析和不安全模式检测。
- slsa-verifier — 校验 provenance 和构建来源。
- in-toto — 供应链步骤签名、布局和验证。
动手任务：为一个镜像生成 SBOM 并扫描漏洞，用 cosign 签名，写一条 Kyverno 策略只允许已签名镜像，再用 slsa-verifier 校验一次构建来源。
syft localhost:5000/demo:1.0 -o spdx-json > sbom.json
grype sbom:sbom.json --fail-on high
trivy image --severity HIGH,CRITICAL localhost:5000/demo:1.0
cosign sign --key cosign.key localhost:5000/demo:1.0
cosign verify --key cosign.pub localhost:5000/demo:1.0
过关标准：
- 能区分漏洞、错误配置和密钥泄露，三者需要不同的扫描器和处置流程。
- 知道签名证明“谁签的”，provenance 证明“怎么构建的”，两者不能互相替代。
- 能解释准入控制和运行时检测的先后关系，以及准入被绕过时的风险。
阶段四：运行时与合规
目标：在容器运行时发现异常行为，用最小权限和网络策略限制影响范围，并让密钥和证书可轮换。
阅读顺序：
- falco — 基于系统调用的运行时规则和告警。
- tetragon — eBPF 可观测、进程执行策略和阻断。
- pod-security-admission — privileged、baseline、restricted 三个级别。
- networkpolicy — 默认拒绝、标签选择和出入口规则。
- cert-manager — 证书签发、续期和私钥保护。
- vault — 动态密钥、租约、审计和加密即服务。
- build-openbao — OpenBao 的部署与初始化流程。
- seccomp — 系统调用过滤和默认运行时配置。
- apparmor — 文件、能力和网络访问的强制配置。
- container-security-checklist — 容器上线前的安全检查清单。
动手任务：在测试集群启用 restricted 级别，创建默认拒绝的 NetworkPolicy，只放行必要流量；用 Falco 或 Tetragon 捕获一次容器内启动 shell 的行为；用 Vault 或 OpenBao 发放一个有租期的凭据。
kubectl create namespace demo-restricted
kubectl label namespace demo-restricted pod-security.kubernetes.io/enforce=restricted
kubectl -n demo-restricted run bad-pod --image=busybox --privileged -- sleep 3600
kubectl create namespace demo-runtime
kubectl -n demo-runtime run demo-pod --image=busybox -- sleep 3600
kubectl -n demo-runtime apply -f default-deny.yaml
kubectl -n demo-runtime exec -it demo-pod -- sh
kubectl logs -n falco -l app=falco --tail=20
vault kv put secret/demo password=change-me
vault lease renew "$LEASE_ID"
过关标准：
- 能说清预防、检测、响应三类控制各由哪些组件承担。
- 知道 Pod Security Admission 三个级别分别限制什么，以及为什么不能替代运行时检测。
- 能解释 NetworkPolicy 默认全通、必须显式拒绝的原因。
- 知道密钥轮换失败时，应用如何降级以及如何验证新凭据生效。
常见误区
- 把防火墙当成唯一边界，忽略内部横向移动和工作负载身份。
- 扫描器没报漏洞就认为安全，忽略配置、密钥和供应链。
- 给 CI 或工作负载过大的权限，泄露后可以修改生产。
- 只做镜像扫描，不做签名验证和准入控制。
- 开启 SELinux 后遇到拒绝就切 permissive，不查审计日志。
- 把合规报告等同于安全能力，不验证控制是否真的生效。
- 密钥写进环境变量、镜像或 Git 历史，泄露后无法追溯和轮换。
读完自测
合上页面，先回答，再展开对照。
- RBAC 中的 Role 和 ClusterRole 有什么区别？什么情况下必须用 ClusterRole？
- 镜像扫描、签名和 provenance 分别解决供应链中的什么问题？
- Pod Security Admission 设为 restricted 后，为什么还需要 Falco 或 Tetragon？
答案
- Role 只在某个命名空间内生效，ClusterRole 是集群范围或跨命名空间复用。需要授权集群级资源（如 nodes、persistentvolumes、clusterroles）或通过 ClusterRoleBinding 在所有命名空间生效时，必须使用 ClusterRole。
- 镜像扫描发现已知漏洞和错误配置；签名证明镜像由可信主体签署且未被篡改；provenance 证明镜像由哪个仓库、提交和流水线构建。扫描不能防止篡改，签名不能说明构建过程，provenance 不能替代漏洞检测。
- restricted 只约束 Pod 的安全上下文和字段组合，无法发现运行后的异常行为，例如容器内启动 shell、读取敏感文件、发起意外外连或执行挖矿程序。运行时检测基于系统调用和行为规则，能弥补准入控制看不到的部分。
相关条目