TOP 1、镜像安全
镜像中存在什么？
镜像中存在打包后的code以及base image、tools
安全建议：
1、代码中非必须不使用任何多余的tools或者库。
2、尽量使用小而精且签名的base image.
3、推送到私有仓库前扫描 docker image.(可以集成在CI/CD的流水线中)
4、定期对存储在石私有仓库的docker image 镜像进行扫描。
Top 2、禁止使用root用户运行
在编写docker file以及在pod构建时添加安全上下文，不允许使用root用户。
1、 在编写docker file时创建一个用户专门来跑app.
2、在配置pod时添加安全上下文，禁止使用root用户运行以及使用userid为1000的普通用户来运行。
Top3、管理用户以及应用程序的权限
1、针对于人类用户-访问集群资源-debug
1、使用RBAC
2、先针对不同角色创建想要可以访问的资源或者动作清单。
3、通过RBAC创建想要的客户端证书下发到最终用户。
2、针对于非人类用户-应用程序访问api-server
1、Service Accout
2、同样创建想要可以访问的资源或者动作清单。
3、将权限绑定到相应的Service Account.
**都使用最小权限原则。
Top4、Network Policy
1、不是所有pod都需要互相访问
2、哪怕同一个app都 前端-后端-数据库 也不需要都运行访问
例如：前段不需要访问数据库，而数据库只允许特定的后段进行访问。
解决办法：
1、使用Network Policy限定访问对象以及命名空间。
2、使用istio这类服务网格产品的网络边车来解决微服务以及应用层面的网络策略。
Top 5、TLS加密
一般情况下k8s集群内的应用程序是明文传输，攻击者可以很方便看到集群内部的信息。
解决办法：
1、需要访问的服务之间使用TLS加密通信数据。
Top6、加密k8s集群内部的secret
默认k8s集群内部的secret是base64编码而不是加密。
解决办法：
限制访问：使用 Kubernetes 的 RBAC（Role-Based Access Control）来限制哪些用户和服务可以访问你的 Secret。你应该只允许需要这些 Secret 的服务访问它们。
加密 etcd：Kubernetes 的所有数据，包括 Secret，都存储在 etcd 中。你应该配置 Kubernetes API 服务器来对 etcd 中的数据进行加密。
使用外部密钥管理系统：如果可能的话，你应该考虑使用外部的密钥管理系统，如 HashiCorp Vault 或 AWS KMS，来存储你的敏感数据。这些系统提供了更强大的安全性和更细粒度的访问控制。
定期轮换 Secret：你应该定期更改你的 Secret，并确保旧的 Secret 在被替换后立即失效。
Top7、etcd
etcd保存着整个k8s集群的几乎所有资源信息，攻击者可以访问etcd那么可以说几乎拥有无限制对于k8s集群的访问权限。
解决办法：
限制网络访问：etcd 应该只能被 Kubernetes API 服务器访问，不应该对外部网络开放。你可以使用防火墙规则或网络策略来限制对 etcd 的访问。
启用 TLS：你应该为 etcd 启用 TLS，以加密所有的通信。这包括 etcd 的客户端到服务器的通信（例如，API 服务器到 etcd 的通信），以及 etcd 集群内部的服务器到服务器的通信。
使用强密码：如果你启用了 etcd 的身份验证功能，你应该为每个 etcd 用户设置一个强密码。
定期备份：你应该定期备份 etcd 的数据，以防止数据丢失。你也应该定期测试你的备份恢复流程，以确保它能够正常工作。
启用审计日志：你应该启用 etcd 的审计日志功能，以记录所有的请求。这可以帮助你检测任何未授权的访问尝试，以及跟踪问题的来源。
定期更新和打补丁：你应该定期更新 etcd 到最新版本，并及时应用任何安全补丁。这可以帮助你防止已知的安全漏洞。
使用专用的物理或虚拟机：etcd 应该运行在专用的物理或虚拟机上，不应该与其他应用共享主机。这可以减少 etcd 被其他应用的漏洞所利用的风险。
限制 etcd 的资源访问：你应该限制 etcd 进程的资源访问，例如文件系统、内核参数等。这可以通过使用 Linux 的安全模块，如 SELinux 或 AppArmor 来实现。
Top8 非基础设施数据库的用户、APP数据
这个无需多言，最重要的就是数据。
解决办法：
1、建立完整的备份机制。（方案越贵越有效）
2、完整的备份软件具有恢复功能。
3、最好的办法是建立不可变备份且存储备份的位置要足够安全。
4、保护数据库本身的同时保护备份！
Top 9 建立容器准入规则
k8s集群一般由开发团队使用，但运维由云基础架构。怎么按开发人员遵从容器开发安全实践？
解决办法：
1、建立容器准入规则。例如OPA,Kubewarden
2、上面都工具都具备自动化检查创建和更新的Pod是否符合规则。
Top10 建立网上的容灾机制
这个不必多说，任何运维人员都想自己的基础设施上跑的应用具备容灾能力。
1、基础设施容灾
1、计算资源不超过百分之70，留出余量假设某节点会Down.
2、服务器双电源
3、网络吞吐量富余1个物理接口的流量。
4、所有网络设备均使用高可用方案-堆叠、M-lag
2、数据容灾
1、集群数据和用户数据定期备份并且数据备份的位置足够安全。本地1份、异地1份。
2、备份软件足够可靠且授权足够。
3、软件具备自动恢复能力。
3、应用容灾
1、前段3个副本起步且运行在不同主机上。
2、后端分类型至少2个副本起步且运行在不同主机上。
3、有状态集群服务使用亲和性或者逻辑拓扑域至少一个逻辑拓扑域不同的主机上运行。
4、搭建专门的入口ingress集群.
