4C是啥?
- cloud
- cluster
- container
- code
4个C是层的关系,外圈不安全,不能指望里面太安全。。。
目录
Cloud
cloud Provider Security
基础架构安全
Cluster
cluster的组件
cluster中的组件(应用中的)
Container
Code
Cloud
如果cloud这层vulnerable,就不能保证其上构建的集群是安全的
cloud Provider Security
k8s基于CPS,可以参照其最佳实践
基础架构安全
- 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