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

20-08-06 banq

对于组织而言,将销售数据保存在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的梦想!)

 

              

猜你喜欢