一、最小特權原則（POLP）

1）最小特權原則 (Principle of least privilege，POLP) ：
是一種信息安全概念，即為用戶提供執行其工作職責所需的最 小權限等級或許可。 最小特權原則被廣泛認為是網絡安全的最佳實踐，也是保護高價值數據和資產的特權訪問的基本方式。

2）最小特權原則 (POLP) 重要性：

• 減少網絡攻擊面：當今，大多數高級攻擊都依賴于利用特權憑證。通過限制超級用戶和管理員權限，最小權限執行有 助于減少總體網絡攻擊面。
• 阻止惡意軟件的傳播： 通過在服務器或者在應用系統上執行最小權限，惡意軟件攻擊（例如SQL注入攻擊）將很難 提權來增加訪問權限并橫向移動破壞其他軟件、設備。
• 有助于簡化合規性和審核：許多內部政策和法規要求都要求組織對特權帳戶實施最小權限原則，以防止對關鍵業務系 統的惡意破壞。最小權限執行可以幫助組織證明對特權活動的完整審核跟蹤的合規性。

3）在團隊中實施最小特權原則 (POLP) ：

• 在所有服務器、業務系統中，審核整個環境以查找特權帳戶（例如SSH賬號、管理后臺賬號、跳板機賬號）；
• 減少不必要的管理員權限，并確保所有用戶和工具執行工作時所需的權限；
• 定期更改管理員賬號密碼；
• 監控管理員賬號操作行為，告警通知異常活動。

二、AppArmor 限制容器對資源訪問

AppArmor（Application Armor） 是一個 Linux 內核安全模塊，可用于限制主機操作系統上運行的進程的功能。每個 進程都可以擁有自己的安全配置文件。安全配置文件用來允許或禁止特定功能，例如：網絡訪問、文件讀/寫/執行權限等。（類似SELinux）

AppArmor 對操作系統和應用程序所受到的威脅進行從內到外的保護，簡單的說，AppArmor 是與 SELinux 類似的一個訪問控制系統，通過它可以指定程序可以讀、寫或運行哪些文件，是否可以打開 網絡端口等。作為對傳統 Unix 的自主訪問控制模塊的補充，AppArmor 提供了強制訪問控制機制，它 已經被整合到 2.6 版本的 Linux 內核中。目前 Ubuntu 自帶了 Apparmor。

官網：AppArmor - Ubuntu Wiki

Linux發行版內置：Ubuntu、Debian

使用場景：AppArmor 可以配置為任何應用程序減少潛在的攻擊面，并且提供更加深入的防御。 它通過調整配置文件進行配置，以允許特定程序或容器所需的訪問， 如 Linux 權能字、網絡訪問、文件權限等。防止黑客在二進制目錄下放如木馬文件替換常用命令等。

2.1 Apparmor兩種工作模式：

1. Enforcement（強制模式） ：在這種模式下，配置文件里列出的限制條件都會得到執行，并且對于違反這些限制條 件的程序會進行日志記錄。（類似SELinux的enforcing）
2. Complain（投訴模式）：在這種模式下，配置文件里的限制條件不會得到執行，Apparmor只是對程序的行為進行 記錄。一般用于調試。例如程序可以寫一個在配置文件里注明只讀的文件，但 Apparmor 不會對程序的行為進行限 制，只是進行記錄。（類似SELinux的permissive）

常用命令：
參考：Ubuntu Manpage: apparmor_parser - loads AppArmor profiles into the kernel

• apparmor_status：查看AppArmor配置文件的當前狀態的
• apparmor_parser：將AppArmor配置文件加載到內核中
  • apparmor_parser <profile> ? ? ? ?# 加載到內核中
  • apparmor_parser -r <profile> ? ? # 重新加載配置
  • apparmor_parser -R <profile> ? ?# 刪除配置
• aa-complain：將AppArmor配置文件設置為投訴模式，需要安裝apparmor-utils軟件包
• aa-enforce：將AppArmor配置文件設置為強制模式，需要安裝apparmor-utils軟件包

2.2 K8s使用AppArmor的先決條件：

K8s版本v1.4+，檢查是否支持：kubectl describe node | grep AppArmor

• Linux內核已啟用AppArmor，查看cat /sys/module/apparmor/parameters/enabled
• CRI 容器運行時 需要支持AppArmor，目前Docker已支持

官網：使用 AppArmor 限制容器對資源的訪問 | Kubernetes

示例：AppArmor 目前處于測試階段，因此在注解中指定AppArmor策略配置文件。

apiVersion: v1
kind: Pod
metadata:name: hello-apparmorannotations:container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_ref>
...

• <container_name> ? ? # Pod中容器名稱
• <profile_ref> ? ? # Pod所在宿主機上策略名，默認目錄/etc/apparmor.d/

補充：AppArmor 基于Linux內核實現，需要在宿主機上執行加載操作，kubelet會讀取加載的配置文件應用到容器中，執行相應的策略限制（包括容器文件、目錄、網絡等）

2.3 訪問控制與資源限制

1）文件系統的訪問控制
Apparmor 可以對某一個文件，或者某一個目錄下的文件進行訪問控制，包括以下幾種訪問模式：

字符	描述
r	讀
w	寫
a	追加
k	文件鎖定
l	鏈接
x	可執行

匹配目錄和文件：

通配符	描述	示例
*	在目錄級別匹配 零個或多個字符	/dir/* 匹配目錄中的任何文件 /dir/a* 匹配目錄中以a開頭的任意文件 /dir/*.png 匹配目錄中以.png結尾的任意文 件 /dir/a*/ 匹配/dir里面以a開頭的目錄 /dir/*a/ 匹配/dir里面以a結尾的目錄
**	在多個目錄級別 匹配零個或多個 字符	/dir/** 匹配/dir目錄或者/dir目錄下任何文件 和目錄 /dir/**/ 匹配/dir或者/dir下面任何目錄
[]、[^]	字符串，匹配其 中任意字符	/dir/[^.]* 匹配/dir目錄中以.之外的任何文件 /dir/**[^/] 匹配/dir目錄或者/dir下面的任何 目錄中的任何文件

在配置文件中的寫法，如：/tmp r, (表示可對/tmp 目錄下的文件進行讀取)

注意：沒在配置文件中列出的文件，程序是不能訪問

2）資源限制
Apparmor 可以提供類似系統調用 setrlimit 一樣的方式來限制程序可以使用的資源。要限制資源， 可在配置文件中這樣寫：
set rlimit [resource] <= [value],
其 resource 代表某一種資源，value 代表某一個值，要對程序可以使用的虛擬內存做限制時，可以 這樣寫：
set rlimit as<=1M, （可以使用的虛擬內存最大為 1M）

3）訪問網絡
Apparmor 可以程序是否可以訪問網絡進行限制，在配置文件里的語法是：
network [ [domain] [type] [protocol] ]
要讓程序可以進行所有的網絡操作，只需在配置文件中寫：
network,?
要允許程序使用在 IPv4 下使用 TCP 協議，可以這樣寫：
network inet tcp,

使用Ubuntu搭建k8s環境下安裝apparmor

apt-get install apparmor-utils apparmor-profiles apparmor-profiles-extra -y

注：Apparmor 的 profile 配置文件保存在目錄/etc/apparmor.d，對應的日志3721
文件記錄在 /var/log/messages

---

案例：限制容器對目錄或者文件的訪問

實施步驟：
1.將自定義策略配置文件保存到 /etc/apparmor.d/
2.加載配置文件到內核：apparmor_parser <profile>
3.創建Pod時，注解指定策略配置名

工作流程：

---

1）自定義策略配置文件

vi /etc/apparmor.d/k8s-deny-write
# include <tunables/global>    //導入依賴
profile k8s-deny-write flags=(attach_disconnected) {   //指定策略名# include <abstractions/base>file,              # 允許所有文件讀寫deny /bin/** w,    # 拒絕所有文件寫deny /data/www/** w,
}

• 第一行：導入依賴，遵循C語言約定
• 第二行：指定策略名
• 第三行：{} 策略塊

2）加載配置文件到內核

# 查看加載的配置文件
apparmor_parser status

# 加載配置文件到內核
apparmor_parser k8s-deny-write

3）創建Pod并注解指定策略配置名YAML文件

apiVersion: v1
kind: Pod
metadata:name: hello-apparmorannotations:container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-deny-write
spec:nodeName: k8s-node1   # 由于策略是指定加載在宿主機，需要指定該宿主機節點containers:- name: helloimage: busyboxcommand: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

注釋：container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-deny-write

• hello 指定的【spec】字段中創建的容器名字；表示對這個容器進行實在策略的應用。
• localhost 表示指定本地的策略文件的策略名（注：是配置策略中的策略名，非文件名）

三、Seccomp 限制容器進程系統調用

對于 Linux 來說，用戶層一切資源相關操作都需要通 過系統調用來完成；系統調用實現技術層次上解耦， 內核只關心系統調用API的實現，而不必關心誰調用的。

調用關系圖：

Seccomp（Secure computing mode） 是一個 Linux 內核安全模塊，可用于應用進程允許使用的系統調用。 容器實際上是宿主機上運行的一個進程，共享宿主機內核，如果所有容器都具有任何系統調用的能力，那么容器如果被 入侵，就很輕松繞過容器隔離更改宿主機系統權限或者進入宿主機。 使用Seccomp機制就可以限制容器系統調用，有效減少攻擊面。

Linux發行版內置：CentOS、Ubuntu

K8s使用Seccomp的先決條件：

Seccomp在Kubernetes 1.3版本引入，在1.19版本成為GA版本，因此K8s中使用Seccomp可以通過以下兩種方式：

• <profile> ? # Pod所在宿主機上策略文件名，默認目錄：/var/lib/kubelet/seccomp

1）1.19版本之前

annotations:seccomp.security.alpha.kubernetes.io/pod: "localhost/<profile>"

2）1.19版本+

apiVersion: v1
kind: Pod
metadata:name: hello-seccomp
spec:securityContext:seccompProfile:type: LocalhostlocalhostProfile: <profile>    # Pod所在宿主機上策略文件名，默認目錄：/var/lib/kubelet/seccompcontainers:
...

seccomp 基本配置文件包括三個元素：

• defaultAction：在 syscalls部分未定義的任何 系統調用默認動作為允許
  • SCMP_ACT_ALLOW 允許
• syscalls
  • names 系統調用名稱，可以換行寫多個
  • SCMP_ACT_ERRNO 阻止系統調用

---

示例：禁止容器使用chmod

1）自定義seccomp策略配置文件：

注意：Pod所在宿主機上配置策略文件，默認目錄/var/lib/kubelet/seccomp（沒有該目錄則自己創建）

[root@k8s-node1-1-72 ~]# mkdir /var/lib/kubelet/seccomp
[root@k8s-node1-1-72 ~]# vi /var/lib/kubelet/seccomp/chmod.json
{"defaultAction": "SCMP_ACT_ALLOW","syscalls": [{"names": ["chmod"],"action": "SCMP_ACT_ERRNO"}]
}

2）創建Pod并注解指定策略配置名YAML文件

[root@k8s-master-1-71 ~]# kubectl apply -f test-seccomp.yaml
apiVersion: v1
kind: Pod
metadata:name: hello-seccomp
spec:nodeName: k8s-node1-1-72           # 由于策略是指定加載在宿主機，需要指定該宿主機節點securityContext:seccompProfile:type: LocalhostlocalhostProfile: chmod.json     # 指定Pod所在宿主機上策略文件名containers:- image: busyboxname: bscommand:- sleep- 24h

測試：在Pod中授予 /etc/hosts 執行權限

[root@k8s-master-1-71 ~]# kubectl get pods
NAME                        READY   STATUS    RESTARTS        AGE
hello-seccomp               1/1     Running   0               5s
[root@k8s-master-1-71 ~]# kubectl exec -it hello-seccomp -- sh/ # chmod +x /etc/hosts
chmod: /etc/hosts: Operation not permitted

示例：禁止容器使用mkdir

注意：編輯策略文件后，需要重啟Pod才生效

vi /var/lib/kubelet/seccomp/chmod.json
{"defaultAction": "SCMP_ACT_ALLOW","syscalls": [{"names": ["chmod"，"mkdir"     # 注意：增加系統調用需要添加【，】],"action": "SCMP_ACT_ERRNO"}]
}# 需要重啟Pod，加載生效
[root@k8s-master-1-71 ~]# kubectl delete -f test-seccomp.yaml
[root@k8s-master-1-71 ~]# kubectl apply -f test-seccomp.yaml
[root@k8s-master-1-71 ~]# kubectl exec -it hello-seccomp -- sh
/ # mkdir /data
mkdir: can't create directory '/data': Operation not permitted

補充：大多數容器運行時都提供一組允許或不允許的默認系統調用。通過使用 runtime/default 注釋 或將 Pod 或容器的安全上下文中的 seccomp 類型設置為 RuntimeDefault，可以輕松地在 Kubernetes 中應用默認值。

Docker默認配置說明：Seccomp security profiles for Docker | Docker Docs

課后作業

1、在工作節點上加載課堂上講解的apparmor策略文件k8s-deny-write，并在 Pod中應用該策略
2、在工作節點上加載課堂上講解的seccomp文件，禁止容器里使用chmod命令， 并在Pod中應用該策略
?

小結

本篇為 【Kubernetes CKS認證 DAY3】的開篇學習筆記，希望這篇筆記可以讓您初步了解到 最小特權原則（POLP）、AppArmor 限制容器對資源訪問，不妨跟著我的筆記步伐親自實踐一下吧！

---

Tip：畢竟兩個人的智慧大于一個人的智慧，如果你不理解本章節的內容或需要相關筆記、視頻，可私信小安，請不要害羞和回避，可以向他人請教，花點時間直到你真正的理解。