🚦 透過K8s執行服務，除了確保服務穩定與正確性，另一大課題便是「安全性」控管，在整體架構的設計當中，由API進行各元件的溝通，很直覺的能想到控制平台(control plane)需使用安全性的溝通方式(TLS)，另外如同部署時使用各種元件管理，也設計有相關的安全性元件，像是Secret將value做基本的保護，在工作負載(workload)方面，pod和容器的安全性可各自做管理，有關基礎政策的訂定，K8s有原生的機制 (NetworkPolicy或ValidatingAdmissionPolicy等)，另外也可參考雲端代管提供的服務或K8s週邊的項目

雲原生平台安全性管控，由階段分層有：

• 開發階段(develop): 零安全架構、code review、威脅模型分析等
• 發行階段(distribute): 容器映像檔、程式成品(artifact)及相關執行程式的元件的內容及取得過程安全
• 部署階段(deployment): 限制部署內容、位置及特定人員
• 執行階段(runtime):
  • access: API安全性控管(TLS)，進行驗證及權限管理
  • compute: 元件控管獨立設定，並做整合，像是作業系統層級、容器層級等
  • storage: 外部存儲擴充，並做加密處理

後續介紹以執行階段的access及compute為主

TLS certificates

Transport Layer Security (TLS)，確保網路通訊伺服器端(server)以及用戶端(client)之間資料的私密性及安全性，由合法的證書機構(certificate authority, CA)頒發憑證(certificates)，此有效憑證確保API之間溝通安全，伺服器端及用戶端來往皆需要有合法有效的憑證：

• Server: 對外開放HTTPS服務，讓其它元件用戶使用於操作K8s叢集
  • KUBE-API SERVER: 兼具SERVER及CLIENT身分，可共用同一對公私鑰，或分為兩對公私鑰作區分
  • ETCD SERVER
  • KUBLET SERVER
• Client:
  • ADMIN USER
  • KUBE-SCHEDULER
  • KUBE-CONTROLLER-MANAGER
  • KUBE-PROXY
  • KUBE-API SERVER

產生憑證 (選用OpenSSL工具)
CA憑證: 給CA自己的憑證，為自簽名證書

1. 產生private key: openssl genrsa -out ca.key 2048
2. 發出CSR(certificate signing request): openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr

• 請求端的公鑰及身分資訊，CN(Common Name)為簽署名稱，系統完整名稱或FQDN等

4. 生成自簽名的根證書: openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt

• 以自產生的私鑰，簽署csr，生成一個自簽名的X.509 證書

管理員ADMIN USER

1. 產生private key: openssl genrsa -out admin.key 2048
2. 發出CSR: 管理員權限, 指定該證書的GROUP為system:masters
   openssl req -new -key admin.key -subj "/CN=kube-admin/OU=system:masters" -out admin.csr

• kube-apiserver預定義部分權限角色，此群組將綁定至角色: cluster-admin，具有調用kube-apiserver的所有權限

3. 以自產生的私鑰，簽署csr，生成一個自簽名的X.509 證書: 為admin user建立private key的時候, 需要指定 CA certificate and the CA key: openssl x509 -req -in admin.csr –CA ca.crt -CAkey ca.key -out admin.crt

KUBE API SERVER

1. 產生private key: openssl genrsa -out apiserver.key 2048
2. 發出CSR: 指定該證書的GROUP為kube-apiserver: openssl req -new -key apiserver.key -subj \ "/CN=kube-apiserver" -out apiserver.csr -config openssl.cnf

• 多個別名都需要設定好, 後續才能建立有效連線
• Kubernetes.default
• Kubernetes.default.svc
• Kubernetes.default.svc.cluster.local
• ip address
• 執行api server pod的 ip address

# 設置檔案 openssl.cnf
[req]
req_extensions = v3_req
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation,
subjectAltName = @alt_names
[alt_names]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.local
IP.1 = <IP>
IP.2 = <IP>

3.以自產生的私鑰，簽署csr，生成一個自簽名的X.509 證書:openssl x509 -req -in apiserver.csr \ -CA ca.crt -CAkey ca.key -out apiserver.crt

元件產製過程相同，系統元件依據類型，選定CN前綴名稱
* ==API 相關的角色==
* system:authenticated
* system:unauthenticated
* ==user相關的角色==
* system:masters
* ==核心元件相關的角色==
* system:kube-scheduler
* system:kube-controller-manager
* system:kube-proxy
* system:node:<node_name>
* KUBE-API SERVER
* ETCD-SERVER

就像瀏覽器都內建CA驗證機構的根憑證(root certificates)，在配置server或client憑證的時候，皆須指定CA憑證，此為叢集內有效的證書，

kube-apiserver建立一系列預設的角色與權限綁定，其前綴帶有關鍵字SYSTEM, 表示由cluster controle plane直接管理

完成產製證書後，便是配置API請求時所需的公私鑰及證書，可透過：

• 帶入參數: curl https://kube-apiserver:6443/api/v1/pods --key admin.key --cert admin.crt --cacert ca.crt
• 配置檔(kubeconfig)設定:

  apiVersion: v1
  clusters:
  - cluster:
      certificate-authority: ca.crt
      server: https://kube-apiserver:6443
    name: kubernetes
  kind: Config
  users:
  - name: kubernetes-admin
    user:
      client-certificate: admin.crt
      client-key: admin.key
  

元件通訊設定證書

• etcd: 多server配置(peer)，因此配置項目除本體之外，也要設定peer的CA及公私鑰
  • etcd本體
  • peer
• kube-apiserver: 包含多個別名，在產生證書的時候，需同步設定以建立有效連線
  • kube-apiserver本體
  • 對kublet
  • 對etcd
• kubectl node:
  • kubelet (server and client): 表示屬於system:nodes