TOP10-k8s-安全措施

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 来实现。