K8s | Security - 1

Posted on Edited on In Views:

K8s Security Primitives

Secure K8s

kube-apiserver

What is kube-apiserver?
kube-apiserver 是 Kubernetes 控制平面的核心組件之一，扮演整個叢集的大腦與出入口。
它提供一個 HTTP REST API，所有的內部元件（如 kubelet、controller-manager）與外部工具（如 kubectl、CI/CD pipeline）都透過它來與 Kubernetes 互動。

🔐 常見安全設定

類型 範例設定方式
認證 Token、憑證、HTTP Basic、OIDC、Webhook
授權 RBAC、ABAC、Webhook
傳輸加密 HTTPS、TLS 憑證
請求限制 Audit Policy、Rate Limiting、Webhook 驗證器

✅ 小提醒

  • kube-apiserver 是無狀態的（stateless），可橫向擴展以提高高可用性。
  • 狀態都存放在 etcd。
  • 若 apiserver 掛掉，只要 etcd 還在，叢集狀態不會遺失。

Authentication (驗證): Who can access?

  1. Files – Username and Passwords
  2. Files – Username and Tokens
  3. Certificates
  4. External Authentication providers - LDAP
  5. Service Accounts

Authorization (授權): What can they do?

  1. RBAC Authorization
  2. ABAC Authorization
  3. Node Authorization
  4. Webhook Mode

TLS Certificates

Kube ApiServer (Master)

  • ETCD CLUSTER (Master)
  • Kube Scheduler (Master)
  • Kube Controller Manager (Master)
  • Kubelet (Worker Nodes)
  • Kube Proxy (Worker Nodes)

Network Policies

Authentication

Kubernetes 本身 的確 「不主動管理帳號（account）」，但它提供帳號的概念與機制，讓外部系統或管理者進行 身份驗證與授權整合。

✅ 結論：K8s 不管理帳號，但提供「授權架構」

功能面向 Kubernetes 做的事
帳號管理 ❌ 不管理 User 帳號，需依賴外部系統驗證
認證機制 ✅ 提供多種身份驗證接口
授權（RBAC） ✅ 控制誰能對什麼資源做什麼操作
Service Account ✅ 自動建立與管理，供 Pod 使用

Accounts

User (使用者帳號) 會先經過 kube-apiserver (Authenticate User) 驗證後，才 Process request。

1
2
3
Admins      --- kubectl                              -
                                                      |---> kube-apiserver ---> Process request
Developers  --- curl https://kube-server-ip:6443/    -

Authentication 流程圖

1
2
3
4
5
6
7
[kubectl]      [curl / script]    [Pod / Controller]
   │                 │                       │
   └──────┐     ┌────┴────────┐       ┌──────┘
          ▼     ▼             ▼       ▼
             [ kube-apiserver ]
                     │
            [ AuthN → AuthZ → Admission → etcd ]

Accounts 類型比較

類型 說明 Kubernetes 是否自動管理？
User Account（使用者帳號） 給人類使用者（例如 Admin、DevOps） ❌ 不會管理，也不儲存在 K8s 中
Service Account（服務帳號） 給 Pod 或內部控制器使用 ✅ 由 K8s 管理與建立

User (使用者帳號)

例如：Admins, Developers

  • K8s 不會建立、儲存或驗證 User 帳號。
  • 常見身份驗證來源（通常透過外部系統提供。需由管理者或 DevOps 架設）：
    • X.509 憑證（最常見，kubectl 預設方式）
    • OIDC = OpenID Connect（例如與 Google、GitHub、Keycloak 整合）
    • LDAP / Active Directory (AD)
    • Webhook Token Auth（自定 API）
  • 雖然身份驗證交由外部處理，K8s 仍可用 RBAC 對這些使用者進行授權（例如管控這個 user 可否 get pod）。

Service Accounts (服務帳號)

例如：CI/CD Bots

  • K8s 每個 namespace 會預設建立一個名為 default 的 service account (SA)。
  • 若 Pod 未指定 SA，會自動綁定 default。
  • Pod 會透過 SA 的 Token Secret 自動掛載存取 kube-apiserver。（例如：與 etcd 同步、看其他資源）
  • 可使用 RBAC 控制其存取權限。
  • 常用指令： 
    1
    2
    3
    4
    5
    # 建立 ServiceAccount
    kubectl create serviceaccount <sa_name> -n <namespace>

    # 查詢
    kubectl get serviceaccounts -n <namespace>

kube-apiserver 的 Auth Mechanisms

類型 說明 建議使用？
Static Password File 使用 CSV 格式帳號密碼 🚫 不建議（不安全、不易擴展）
Static Token File 使用 Token 存放在檔案中 🚫 不建議（實驗、測試用途）
X.509 憑證 使用 client cert 登入 API（kubectl 預設） ✅ 建議（成熟且穩定）
OIDC（OpenID Connect） OAuth2 相容身份系統（如 Google） ✅ 建議（支援 SSO）
Webhook Token Auth 將請求導向自定 API 做身份驗證 ✅ 建議（彈性高）

補充說明：Static File Auth

在 kubeadm 安裝環境中，如果使用 static token/password 認證方式，需透過 Volume 將檔案掛載進 kube-apiserver。
⚠️ 生產環境不建議使用 static file authentication，請優先使用憑證或 OIDC。

TLS Basics (PRE-REQ)

TLS Certificates

TLS（Transport Layer Security）是用來加密兩端通訊的重要技術 (網路通訊加密協定)，常見於 HTTPS、Kubernetes、SSH 等場景。
TLS 憑證基於 公開金鑰加密（Public Key Cryptography） 和 PKI 架構。

Symmetric Encryption（對稱式加密）

  • 雙方共用 同一把密鑰 來加解密。
  • 加密快速，但 密鑰分發困難、不安全 (密鑰交換困難)。
  • 適合資料傳輸，但不適合建立安全連線。

Asymmetric Encryption（非對稱式加密）

  • 一對金鑰：Private Key（私鑰） 與 Public Key（公開鑰 / 公開鎖, aka. Public Lock）
  • 加密與解密由不同金鑰完成：
    • 公鑰加密 → 私鑰解密
    • 私鑰簽名 → 公鑰驗證
  • ✅ 適用於建立安全連線與身分驗證
    Public Key = 公開鎖，只有私鑰才能解開它。

金鑰與憑證範例

1
2
3
4
5
6
7
8
9
10
11
12
# 產生 SSH 金鑰對（與 TLS 相似邏輯）
ssh-keygen

# 預設產出兩個檔案：
# 1. 私鑰 (Private Key): ~/.ssh/id_rsa    → 對應 TLS 中的 *.key 或 *-key.pem
# 2. 公鑰 (Public Key): ~/.ssh/id_rsa.pub → 對應 TLS 中的 *.crt 或 *.pem

# 登入使用 SSH 私鑰
ssh -i id_rsa user1@server1

# 查看伺服器上允許的公鑰
cat ~/.ssh/authorized_keys

Certificate Authority (CA)

  • CA 是受信任的憑證簽發單位，用來簽署憑證以證明身份真實性。
  • 憑證中包含：
    • 公鑰
    • 實體資訊（如：CN、OU、DNS name）
    • CA 的簽名
  • TLS 憑證是由 CA 簽發（或自簽）後，附上「公鑰 + 身份資訊」的檔案。
  • 常見格式：.crt、.pem

Public Key Infrastructure (PKI)

建立、簽署與管理憑證(公私鑰 + 憑證)的信任架構

PKI 架構包含：

  • 憑證簽署請求（CSR）：由持有私鑰者發出，請求 CA 簽名
  • CA 簽發憑證：根據 CSR 回傳正式憑證
  • 憑證鏈（Chain of Trust）：Root Certificates、Server Certificates、Client Certificates 串接
  • 憑證有效性檢查（OCSP、CRL）：憑證撤銷機制

TLS 運作核心概念（整合）

元件 內容
Private Key 自己保管，負責解密資料或產生數位簽章
Public Key 發給對方，讓對方對資料加密或驗證簽章
Certificate（憑證） 公鑰 + 身份資訊（如 CN、OU），經 CA 簽章
TLS 通訊 初始階段使用 非對稱加密 交換對稱密鑰 → 後續資料交換使用 對稱加密

Server Certificates for Servers

  • kube-api server
  • etcd server
  • kubelet server

Client Certificates for Clients

  • admin
  • kube-scheduler
  • kube-controller-manager
  • kube-proxy

Generate Certificates

Tools:

  1. EASYRSA
  2. OPENSSL
  3. CFSSL

Certificate Authority (CA)

1
2
3
4
5
6
7
8
# Generate Keys
openssl genrsa -out ca.key 2048

# Certificate Signing Request
openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr

# Sign Certificates
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt

View Certificate Details

Certificate Workflow & API

KUBECONFIG