K8s | Security - 1

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