在了解 OS 內如何配置後，今天要討論的是針對 pod 的安全性可以怎麼做配置。

Security Context

可以設定在 container 啟動時要使用什麼 user/ group 以及 Root 的權限，設定時可以分兩種(1)pod lever (2)container level
注意 capabilities 只能放在 container level
(1) pod level

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

(2) Container level

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
  image: ubuntu
spec:
  containers:
  - name: sec-ctx-demo
    image: ubuntu
    securityContext:
      runAsUser: 1000
      runAsGroup: 3000
      fsGroup: 2000

securityContext 中可以設定 allowPrivilegeEscalation: false以防止特權提升

Admission Controllers

當使用者透過 kubectl 向 kube-apiserver 發出請求時會經過以下途徑

user -> Authentication -> Authorization -> Admission Controllers -> kube-apiserver

前面有先介紹過 Authentication 以及 Authorization ，這邊先快速帶過

• Authentication 主要是存於 .kube/config 中，主要是在輸入 kubectl 時會自動帶入連線的資訊
• Authorization 則是提供使用者有 create, get, delete 等權限，會透過 role, clusterrole, 以及 binding 賦予

倘若我們需要控制讓使用者不能 create 一些物件時，可以透過 Admission Controllers 進行限制或者修改， 注意 Adminission Controllers 不能限制 get, watch or list 等行為。

可以分為 (1)Mutating 以及 (2)Validating， Mutating 指的是當在請求的時候如果有開啟該功能會協助將缺少的配置修改成 default 的設定； Validating 則是確認是否可以進行部署。會先 Mutating 再 Validating 。

注意，如果透過 Mutating 修改的內容只能透過kubectl get pods -o yaml查看，無法透過kubectl describe pod查看，get 顯示的是 etcd 中完整的實際配置

設定

一般而言預設會開啟一些控制項，如果需要查看該控制項可以透過以下指令查看

kubectl exec -it kube-apiserver-controlplane -n kube-system -- kube-apiserver -h | grep enable-admission-plugins

1. 除預設外如果需要啟用 Admission Controllers 額外功能，可以在 api-server 中啟用並設定 kube-apiserver

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...

2. 禁用 Admission Controllers 的預設功能，同樣可以在 api-server 中啟用並設定 kube-apiserver

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

3. 控制項設定
   其實在這當中會有非常多的控制項，若以考試為出發，最長被問到的會是 ImagePolicyWebhook ，在建立時會建立一個 Webhook ，當在建立 pod 時會到該 webhook 確認是否能夠下載該 image 。以下將以 ImagePolicyWebhook 為例說明如何設定：
   (1) 配置檔可以分為 yaml 的配置
   (1)-1 建立時可以建立兩個檔案分別是 AdmissionConfiguration 以及 ImagePolicy 具體配置

# imagepolicyconfig
imagePolicy:
  kubeConfigFile: /path/to/kubeconfig/for/backend
  # time in s to cache approval
  allowTTL: 50
  # time in s to cache denial
  denyTTL: 50
  # time in ms to wait between retries
  retryBackoff: 500
  # determines behavior if the webhook backend fails
  defaultAllow: true

# ImagePolicy
# admission-config.yaml (主配置檔)
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    path: imagepolicyconfig.yaml  # 指向具體配置檔 

並且在 kube-apiserver 中指定 ImagePolicy 的檔案
(1)-2 或者可以合成成一個檔案

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    configuration:
      imagePolicy:
        kubeConfigFile: <path-to-kubeconfig-file>
        allowTTL: 50
        denyTTL: 50
        retryBackoff: 500
        defaultAllow: true

會需要特別注意defaultAllow這個設定，該設定項主要是指當Webhook失效時是否一律禁止

(2) 上方有提及的 kubeconfig 主要是以下格式

# clusters refers to the remote service.
clusters:
  - name: name-of-remote-imagepolicy-service
    cluster:
      certificate-authority: /path/to/ca.pem    # CA for verifying the remote service.
      server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.

# users refers to the API server's webhook configuration.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
      client-key: /path/to/key.pem          # key matching the cert

(3)在kube-apiserver 裝指定 config 檔位置

--enable-admission-plugins=ImagePolicyWebhook
--admission-control-config-file=/path/to/admission-config.yaml

(4) 當建立 Pod 時，kube-apiserver 會發送這個 ImageReview Request 給 Webhook 服務，Webhook 服務收到後判斷是否允許該映像
用戶建立 Pod → kube-apiserver → 發送 ImageReview → Webhook 服務 → 回傳允許/拒絕

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "spec": {
    "containers": [
      {
        "image": "myrepo/myimage:v1"
      },
      {
        "image": "myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
      }
    ],
    "annotations": {
      "mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
    },
    "namespace": "mynamespace"
  }
}

綜合以上pod security 概念上則可以分為(1) 使用原生的系統 Pod Security Adminission 及 Pod Security Standard (2) 第三方軟體 Open Policy Agnet (OPA) ，最基礎的而言主要是依賴 securityContext 的設定，除了在當中直接設定 runAsUser, privileged 外，在 kube-apiserver 中 --enable-admission-plugins=PodSecurity 也有對應的配置。
提供類似限制

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

1. Pod Security Adminission (PSA) - 提供對 pod 不同層級的限制，會在 pod 建立時檢視，主要是針對 namespace 賦予
   使用時會在 namespace 上賦予 label pod-security.kubernetes.io/<MODE>: <LEVEL>

Pod Security Adminission 也就是 MDOE 可分為 (1)enforce (2)audit (3)warn

Pod Security Standard 也就是 LEVEL 可分為 (1)Privileged (2)Baseline (3)Restricted

配置時可以交叉配置如

pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: baseline
pod-security.kubernetes.io/warn: privileged

2. Open Policy Agent (OPA)
   使用時會透過第三方的來進行 Authentication 以及 Authorization

參考資料
https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
https://kubernetes.io/docs/concepts/security/pod-security-admission/
https://kubernetes.io/docs/concepts/security/pod-security-standards/
https://github.com/open-policy-agent/opa/releases
https://www.openpolicyagent.org/docs/policy-language