Rekt-Dev/k8s-incident-response

# k8s-incident-response 用于在 kubeadm 集群上进行事件响应的运维操作手册和脚本。这些内容最初是作为 CKS 考试准备编写的，在通过考试后，逐渐演变成了家庭实验室集群中实际使用的工具。该考试测试了关于 etcd 备份/恢复、证书管理以及 runtime 安全的知识——本仓库让这些知识能够立即付诸实践。 ## 集群环境 - **节点：** k8s (control plane, 192.168.1.110), k8s1, k8s2 - **Kubernetes 版本：** v1.35.x (由 kubeadm 管理) - **Runtime 安全：** Falco - **CNI：** Calico ## 仓库结构 ``` etcd/ backup.sh Snapshot save with cert paths pre-configured for this cluster restore.sh Full restore procedure including control plane restart verify.sh Verify snapshot integrity certificates/ check-expiry.sh Check all cert expiry dates, flag <30 and <90 day warnings rotate-apiserver.md Step-by-step cert rotation procedure node-isolation/ isolate-node.sh Cordon, drain, and network policy isolate a suspected node investigate.sh Collect forensics from the API side before direct node access falco/ custom-rules.yaml Falco rules tuned for this cluster's workload patterns triage-playbook.md Response guide for each Falco alert category rbac-audit/ audit-bindings.sh Full RBAC audit — overprivileged bindings, wildcard roles find-clusteradmin.sh Find all principals with cluster-admin access ``` ## 快速参考 ### etcd 备份 ``` # 立即获取快照 sudo ./etcd/backup.sh # 验证最新快照 sudo ./etcd/verify.sh # 列出现有备份 ls -lh /var/backups/etcd/ ``` ### 检查证书过期时间 ``` sudo ./certificates/check-expiry.sh # 或者直接使用 kubeadm： sudo kubeadm certs check-expiration ``` ### 隔离受损节点 ``` # Cordon、drain 和 network-isolate ./node-isolation/isolate-node.sh k8s1 # 收集 forensics ./node-isolation/investigate.sh k8s1 ``` ### RBAC 审计 ``` # 全面 audit ./rbac-audit/audit-bindings.sh # 查找所有 cluster-admin 访问权限 ./rbac-audit/find-clusteradmin.sh ``` ## etcd 备份策略 Kubeadm etcd 存储了所有的集群状态：Secrets、ConfigMaps、Deployments、RBAC 策略，所有的一切。如果没有可用的 etcd 备份，control plane 发生故障就意味着必须从零开始重建整个集群。 备份脚本使用了 `etcdctl snapshot save` 命令以及位于 `/etc/kubernetes/pki/etcd/` 目录下由 kubeadm 管理的证书。该快照是整个键值对存储的某一时间点的副本。 **建议：** 设置定时任务每天运行 `backup.sh`。将备份存储在节点之外（NFS、兼容 S3 的存储等）。如果磁盘发生故障，存放在与 etcd 同一磁盘上的备份将毫无用处。 ``` # cron 示例（以 root 身份在 control plane 上） 0 2 * * * /opt/k8s-incident-response/etcd/backup.sh /mnt/nfs-backup/etcd >> /var/log/etcd-backup.log 2>&1 ``` **恢复时间：** 在该集群上，完整的恢复过程（停止组件、恢复、重启）大约需要 3-5 分钟。在你需要它之前先进行练习——CKS 考试会在时间压力下测试此项。 ## 证书管理 由 kubeadm 管理的证书默认在 1 年后过期（CA 证书在 10 年后过期）。对于运行了一年多且未进行过 kubeadm 升级的家庭实验室集群，所有的叶子证书可能都已经过期了。 `kubeadm upgrade` 会在升级过程中自动续期证书。如果你不打算升级，请运行 `kubeadm certs renew all` 并每年重启一次 control plane 组件。 Worker 节点的 kubelet 证书默认会自动轮换（已启用 `RotateKubeletClientCertificate`）。请验证是否正在执行此操作： ``` # 在 worker node 上 ls -la /var/lib/kubelet/pki/ # kubelet-client-current.pem 应该有一个近期的修改日期 ``` ## Falco 设置 Falco 在此集群上以 DaemonSet 的形式安装： ``` helm repo add falcosecurity https://falcosecurity.github.io/charts helm install falco falcosecurity/falco \ --namespace falco --create-namespace \ --set driver.kind=modern_ebpf \ --set falco.grpc.enabled=true \ --set falco.grpcOutput.enabled=true ``` 自定义规则可以放置在每个节点的 `/etc/falco/rules.d/` 目录下，或者通过 Helm chart 的 `customRules` 值进行配置。此仓库中的 `custom-rules.yaml` 可以通过 ConfigMap 挂载： ``` kubectl create configmap falco-custom-rules \ --from-file=custom_rules.yaml=falco/custom-rules.yaml \ -n falco ``` ## 经验总结 **CKS 考试中的 etcd 恢复任务是时间最紧迫的。** 在时间限制下练习完整的流程——停止 API server、恢复、重启、验证——是最好的准备方式。在这个集群上，从干净状态开始的整个流程需要 4 分钟。 **Falco 会不断针对合法的 kubectl exec 触发告警。** 安装 Falco 后的第一周，针对正常的开发者调试产生了数百个警报。调整 `custom-rules.yaml` 中的例外列表以匹配实际的使用模式，大约花了一周的时间。 **RBAC 审计能揭示配置漂移。** 在该集群运行 6 个月后运行 `audit-bindings.sh` 发现了 3 个服务账户的权限比最初预期的要宽泛得多——这些是测试期间遗留下来且从未被清理掉的。定期的 RBAC 审计是值得花时间去做的。 **在事件发生期间排空节点可能是错误的做法。** 如果一个 pod 正在执行可疑操作，并且你需要捕获它正在做的事情，排空节点会将其迁移到其他地方，从而丢失 runtime 状态。考虑先在网络层进行隔离，然后在排空之前进行调查。 ## 相关仓库 - [k8s-security-hardening](https://github.com/Rekt-Dev/k8s-security-hardening) — 本操作手册所围绕的预防性控制措施 - [k8s-production-patterns](https://github.com/Rekt-Dev/k8s-production-patterns) — 受到保护的集群工作负载

标签：Cutter, etcd备份, PB级数据处理, 子域名突变, 安全运维, 库, 应急响应, 脚本工具, 证书管理, 运维