走进云原生的安全防线

近日见闻

1. 2023年中国开源开发者报告发布，感兴趣的可以后台回回复"开源报告"查看详细pdf报告，主要介绍了三部分、开发者事件回顾、大语言模型（LLM）相关领域的技术发展，包括国内外的各种AI工具以及中国开源未来发展趋势。--oschina
2. Golang 通用代码生成器仙童发布 2.4.0 电音仙女尝鲜版二，改进三大部分生成功能群 --https://gitee.com/jerryshensjf/Fairchild
3. 句子摘抄

拯救我们的不再是任何道理或技巧，

只有直面的勇气。

——洛莉·戈特利布

在云原生的世界中，安全不是一个待选项，而是必需品。随着越来越多敏感应用的转移到云端，确保这些应用的安全变得至关重要。如何构建起一道坚不可摧的安全防线，保护你的应用不受攻击？我们一起一探究竟。

一个安全的容器生命周期大致包括镜像安全、容器编排以及运行时安全。

[镜像安全]

一个安全的镜像等同于稳固的基础。假设一个应用的镜像被植入了恶意代码，那么每一个基于该镜像启动的容器都可能成为攻击者的跳板。因此，镜像签名和扫描是必不可少的，工具如Clair和Docker Notary可以在这里发挥作用，确保使用安全、经过验证的镜像是防御的第一步。

• 比如使用Docker Content Trust在Docker Engine中启用内容信任，确保只运行经过签名验证的镜像。
• 私有仓库漏洞扫描

配置：Docker Content Trust

export DOCKER_CONTENT_TRUST=1
docker pull alpine:latest

• 最小化镜像：创建精简的容器镜像，仅包含运行应用必需的组件和库，减少攻击面。
• 漏洞扫描：定期使用Clair等工具扫描镜像，及时发现并修复已知的安全漏洞。

[容器编排安全]

容器编排工具很多，如最流行的Kubernetes，管理着容器的生死。若k8s受到攻击，后果不堪设想。保护编排层的关键是限制访问权限、强化身份认证和审计日志。以Kubernetes为例，使用Role-Based Access Control (RBAC) 控制访问，利用OpenID Connect (OIDC) 加强身份验证。如果黑客通过钓鱼邮件获取了运维人员的Kubernetes管理凭证，可能会在集群中植入恶意Pod。

策略有那些呢？

• API服务器保护：通过API服务器的安全端口进行通信，并使用TLS证书加密
• 配置Kubernetes审计日志，记录所有的API调用，以便在出现安全事件时进行调查。
• 最小权限：实施RBAC，对集群中的用户和服务账户赋予最小化的权限。

配置：Kubernetes RBAC

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

该Role对象定义了一个名为pod-reader的角色，该角色允许用户在默认命名空间中读取Pods。

[运行时安全]

运行时是容器安全的最后一环，Falco等运行时安全工具可以监控异常行为，防止潜在的攻击。比如，Falco能够监测到一个容器突然尝试读取系统关键文件，这可能是一个入侵的信号。

策略：

• 行为监控：使用Falco等运行时安全工具来监控容器的异常行为。
• 资源限制：为每个容器设置CPU和内存的使用限制，避免单一容器的资源滥用。

配置示例：Falco规则定义

- rule: Contact K8s API Server From Container
  desc: Detect any attempt to contact the K8s API Server from a container
  condition: outbound and k8s_api_server
  output: "Contact K8S API Server from container (command=%proc.cmdline %container.info)"
  priority: WARNING

该Falco规则用于检测容器是否尝试与Kubernetes API服务器通信，这可能是不正当行为的标志。

服务网格的安全功能：微服务的保护伞

服务网格如Istio提供了应用层面的安全特性，这些特性可以保护微服务架构中的服务间通信。服务网格提供了一个独立于应用代码的方式来实现服务间的通信控制和安全保障。

[加密通信]

服务网格能够确保服务间的通信加密，即使在传输过程中数据被截获，也无法被解读。考虑一下，银行间的交易数据若在传输中不加密，后果将不言而喻。

配置示例：Istio PeerAuthentication

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

这个Istio PeerAuthentication配置将服务间的通信模式设置为STRICT，强制启用mTLS。

[微服务认证与授权]

服务网格使得每个微服务都可以进行细粒度的认证与授权，确保只有合适的服务能够调用另一服务。例如，你不会希望一个前端服务直接访问支付系统。

配置示例：Istio AuthorizationPolicy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-viewer
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  rules:
  - to:
    - operation:
        methods: ["GET"]

这个Istio AuthorizationPolicy配置确保只有对productpage服务有GET请求权限的用户才可以访问。

实例分析 —— 一次真实的攻防演练

结合某科技公司的案例，看看他们是如何应用上述安全措施来防御攻击的。

场景设定：该公司使用Kubernetes和Istio，但是攻击者通过社工手段获取了一个开发者的凭据。攻击者尝试利用这些凭据部署一个恶意的容器。

应对策略：

• 利用Docker Notary对镜像签名，防止未签名的镜像部署。
• Kubernetes的RBAC拒绝了非授权用户对集群的更改。
• 利用Istio的策略防止来自未知服务的数据泄露尝试。

通过这样的多层次防护，即使攻击者具有某些凭据，也无法对系统造成实质性的损害。