在Kubernetes中应用零信任的两种快速配置方法 | inext

对于组织而言，将销售数据保存在SaaS CRM中，将客户数据保存在公共云中（使用Kubernetes之类）以及将内部数据保存在本地数据中心（裸机）中并不少见。不仅如此，访问该数据的员工和客户遍布全球。
开箱即用，Kubernetes带有一些很棒的但不安全的默认值。所有Pod都可以与其他Pod对话，并且所有Pod都可以与Internet对话。对于开始来说很棒，但是最终您将需要锁定一切。
我们将从真正的零信任开始-一种默认的“拒绝所有”策略，该策略不允许任何内容进行对话。

// Default Deny All Network Policy
apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata:   
  name: default-deny-all 
spec:   
  podSelector: {}   
  policyTypes:   
  - Ingress   
  - Egress

该策略对我而言确实巩固了零信任的概念，此处的策略是默认情况下拒绝所有内容，然后慢慢添加更多的宽松策略以覆盖原始default-deny-all策略。

在InfoSec社区中，我们将此称为“最小特权原则”。像许多新的安全趋势一样，零信任依赖于这一久经考验的原则。这是我们将覆盖default-deny-all政策的方式：

// Allow Access from App A to App B
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-my-app
spec:
  podSelector:
    [b]matchLabels:
      app: app-1[/b]
  ingress:
  - from:
    - podSelector:
        [b]matchLabels:
          app: app-2[/b]
  egress:
  - to:
    - podSelector:
        [b]matchLabels:
          app: app-2[/b]

乍一看可能有点令人困惑，但是像其他Kubernetes一样，matchLabels也是我们希望连接的点。从入口和出口的角度来看，此政策实质上是将带有一个labels的Pod连接到下一个labels（我已用粗体显示）。在这种情况下，带有标签的Pod app: app-1只能接收流量（入口），并向带有标签的Pod发送流量（出口）app: app-2。

更直观地讲- 入口部分允许app-1←app-2
出口部分允许APP-1→APP-2
总共这给了我们app-1←→app-2

网络策略是将您的Kubernetes群集开箱即用的理想工具-当它们成为强大的持续集成/持续部署管道的一部分时，它非常强大（DevSecOps的梦想！）