在Kubernetes中應用零信任的兩種快速配置方法 | inext

banq發表於2020-08-06

對於組織而言，將銷售資料儲存在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的夢想！）


 

相關文章