云原生安全:4C~

云原生安全:4C~_第1张图片

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

你可能感兴趣的:(Security,云原生)