4C是啥？

• cloud
• cluster
• container
• code 

4个C是层的关系，外圈不安全，不能指望里面太安全。。。

目录

Cloud

cloud Provider Security

基础架构安全

Cluster

cluster的组件

cluster中的组件（应用中的）

Container

Code

---

Cloud

如果cloud这层vulnerable，就不能保证其上构建的集群是安全的

cloud Provider Security

k8s基于CPS，可以参照其最佳实践

Alibaba Cloud	Alibaba Cloud Security & Compliance Center for Cloud Computing Infrastructure
Amazon Web Services	Cloud Security – Amazon Web Services (AWS)
Google Cloud Platform	https://cloud.google.com/security

基础架构安全

• control plane的网络访问：所有对Kubernetes控制平面的访问都不允许在internet上公开，而是由网络访问控制列表控制，限制为管理集群所需的一组IP地址。
• nodes的网络访问：节点应该配置为只接受来自指定端口上控制平面的连接(通过网络访问控制列表)，并接受NodePort和LoadBalancer类型Kubernetes中的服务的连接。如果可能的话，这些节点不应该完全暴露在公共互联网上。
• k8s访问云供应商的API：每个云提供商需要向Kubernetes控制平面和节点授予一组不同的权限。最好为集群提供云提供者访问，该访问遵循对集群需要管理的资源的最小特权原则。Kops文档提供了IAM策略和角色的相关信息。
• 访问etcd
• etcd加密

Cluster

cluster的组件

Securing a Cluster | Kubernetes

例如k8s API的访问控制，kubelet的访问控制

cluster中的组件（应用中的）

根据应用程序的攻击面不同，您可能需要关注安全性的某个方面。例如:如果您正在运行一个在其他资源链中至关重要的服务(服务a)和一个容易受到资源耗尽攻击的独立工作负载(服务B)，那么如果您不限制服务B的资源，危及服务a的风险是很高的。下表列出了在Kubernetes中运行的安全关注领域和保护工作负载的建议:

• RBAC 授权
• 认证
• 应用密钥管理
• pods安祖pod 安全标准
• service质量，集群资源管理
• 网络policy
• Kubernetes 入口Ingress的TLS

Container

• 容器漏洞扫描和OS依赖的安全，在image构建的中扫描容易的已知漏洞
• 镜像签名，防内容篡改
• 不允许特权用户，创建用户的时候遵守最小特权，
• 强隔离的容器runtime，用container runtime classes提供强隔离 Runtime Class | Kubernetes

Code

就是说自己写的代码的安全，application security范畴

• TLS only
• 尽量控制端口数量
• 三方依赖安全，三方依赖的已知漏洞。。。
• SAST
• DAST