K8s容器運行環境安全加固image-20230528102956392目錄[toc]1、最小特權原則（POLP）最小特權原則 (Principle of least privilege，POLP

K8s容器運行環境安全加固

目錄

[toc]

1、最小特權原則（POLP）

最小特權原則 (Principle of least privilege，POLP) ：是一種信息安全概念，即為用戶提供執行其工作職責所需的最小權限等級或許可。

最小特權原則被廣泛認為是網絡安全的最佳實踐，也是保護高價值數據和資產的特權訪問的基本方式。

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

? 減少網絡攻擊面：當今，大多數高級攻擊都依賴于利用特權憑證。通過限制超級用戶和管理員權限，最小權限執行有助于減少總體網絡攻擊面。

? 阻止惡意軟件的傳播： 通過在服務器或者在應用系統上執行最小權限，惡意軟件攻擊（例如SQL注入攻擊）將很難提權來增加訪問權限并橫向移動破壞其他軟件、設備。

? 有助于簡化合規性和審核：許多內部政策和法規要求都要求組織對特權帳戶實施最小權限原則，以防止對關鍵業務系統的惡意破壞。最小權限執行可以幫助組織證明對特權活動的完整審核跟蹤的合規性。

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

? 在所有服務器、業務系統中，審核整個環境以查找特權帳戶（例如SSH賬號、管理后臺賬號、跳板機賬號）；

? 減少不必要的管理員權限，并確保所有用戶和工具執行工作時所需的權限；

? 定期更改管理員賬號密碼；

? 監控管理員賬號操作行為，告警通知異常活動。

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

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

Linux發行版內置：Ubuntu、Debian centos里默認沒有內置AppArmor。與其同功能的程序centos里是selinux(但是selinux使用起來相對比較復雜，因此工作環境里一般都是關閉狀態的)

Apparmor兩種工作模式：

? Enforcement（強制模式） ：在這種模式下，配置文件里列出的限制條件都會得到執行，并且對于違反這些限制條件的程序會進行日志記錄。

? Complain（投訴模式）：在這種模式下，配置文件里的限制條件不會得到執行，Apparmor只是對程序的行為進行記錄。一般用于調試。

常用命令:

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

K8s使用AppArmor的先決條件：

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

? Linux內核已啟用AppArmor，查看 cat /sys/module/apparmor/parameters/enabled

? 容器運行時需要支持AppArmor，目前Docker已支持

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

示例：

apiVersion: v1nkind: Podnmetadata:n name: hello-apparmorn annotations:n container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_ref>n...n? <container_name> Pod中容器名稱n? <profile_ref> Pod所在宿主機上策略名(配置文件)，默認目錄/etc/apparmor.d

== 案例：容器文件系統訪問限制-2023.5.28(測試成功)==

步驟：

1、將自定義策略配置文件保存到/etc/apparmor.d/

2、加載配置文件到內核：apparmor_parser

3、Pod注解指定策略配置名

本次測試為ubuntu k8s環境，這里只做文檔記錄。

• 創建pod

• 默認情況，在容器里是可以隨意創建文件的

• 限制容器某個目錄/文件的目的

黑客攻擊場景，限制容器進程對其它特定目錄/文件的寫入

• 創建策略文件

相當于一個黑名單，黑名單之外的都可以。

usr/bin等目錄。

• 將策略文件加載到內核中（注意：這里在是node1上配置的）

• Pod注解指定策略配置名

是宿主機的能力，宿主機對容器上的進程做訪問控制，因為容器是宿主機上的一個進程。

• 部署

• 驗證

符合預期。

生產用的并不多，有一定復雜性，不用過多去研究它。

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

Seccomp（Secure computing mode） 是一個 Linux 內核安全模塊，可用于應用進程允許使用的系統調用。

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

Linux發行版內置：CentOS、Ubuntu

== 案例：Seccomp 限制容器進程系統調用-2023.5.28(測試成功)==

GA：畢業

• 實戰步驟

graph LRn A[實戰步驟] -->B(1.隨意查看一個容器)n A[實戰步驟] -->C(2.宿主機上創建配置文件)n A[實戰步驟] -->D(3.創建pod)n A[實戰步驟] -->E(4.測試)

• 實驗環境

實驗環境：n1、win10,vmwrokstation虛機；n2、k8s集群：3臺centos7.6 1810虛機，1個master節點,2個node節點n k8s version：v1.20.0n docker://20.10.7

• 實驗軟件

鏈接：https://pan.baidu.com/s/12Gq4QoK3_iSbBOZslhhZJg?pwd=0820 n提取碼：0820 n2023.5.28-seccomp-code

1.隨意查看一個容器

[root@k8s-master1 ~]#kubectl get ponNAME READY STATUS RESTARTS AGEnbusybox 1/1 Running 10 6d10hn……n[root@k8s-master1 ~]#kubectl exec -it busybox -- shn/ #n/ # chmod 777 /etc/hosts

默認，在容器里是可以執行chmod命令的。

接下來，我們將使用Seccomp 限制容器進程系統調用，阻止chmod命令的運行。

有些命令對應的系統調用方法和命令名同名，但有些是不同的，這些需要注意下。

2.宿主機上創建配置文件

本次，我們在k8s-node2節點上配置策略文件。

[root@k8s-node2 ~]#mkdir /var/lib/kubelet/seccompn[root@k8s-node2 ~]#vi /var/lib/kubelet/seccomp/chmod.jsonn{n"defaultAction": "SCMP_ACT_ALLOW",n"syscalls": [n {n "names": [n "chmod"n ],n "action": "SCMP_ACT_ERRNO"n }n ]n}

3.創建pod

[root@k8s-master1 ~]#mkdir seccompn[root@k8s-master1 ~]#cd seccomp/napiVersion: v1nkind: Podnmetadata:n name: hello-seccompnspec:n nodeName: "k8s-node2"n securityContext:n seccompProfile:n type: Localhostn localhostProfile: chmod.jsonn containers:n - image: nginxn name: webnn#部署：n[root@k8s-master1 seccomp]#kubectl apply -f pod.yaml npod/hello-seccomp created

4.測試

[root@k8s-master1 seccomp]#kubectl get ponNAME READY STATUS RESTARTS AGEnbusybox 1/1 Running 10 6d10hnbusybox2 1/1 Running 10 6d10hnhello-seccomp 1/1 Running 0 23snpy-k8s 1/1 Running 2 4dnweb520 1/1 Running 0 2d23hn[root@k8s-master1 seccomp]#kubectl exec -it hello-seccomp -- bashnroot@hello-seccomp:/# chmod 777 /etc/hosts nroot@hello-seccomp:/#

哎，好奇怪，這個chmod命令依然還可以在這個容器里運行。

我們再換個busybox鏡像再測試下：

[root@k8s-master1 seccomp]#cp pod.yaml pod2.yamln[root@k8s-master1 seccomp]#vim pod2.yaml napiVersion: v1nkind: Podnmetadata:n name: hello-seccomp2nspec:n nodeName: "k8s-node2"n securityContext:n seccompProfile:n type: Localhostn localhostProfile: chmod.jsonn containers:n - image: busyboxn name: busyboxn command:n - sleepn - 24hnn#部署：n[root@k8s-master1 seccomp]#kubectl apply -f pod2.yamlnpod/hello-seccomp2 creatednn#測試：n[root@k8s-master1 seccomp]#kubectl get ponNAME READY STATUS RESTARTS AGEnhello-seccomp 1/1 Running 0 4m26snhello-seccomp2 1/1 Running 0 4sn[root@k8s-master1 seccomp]#kubectl exec -it hello-seccomp2 -- shn/ #n/ # chmod 777 /etc/hostsnchmod: /etc/hosts: Operation not permittedn/ #

哇哦，這里使用busybox鏡像測試，就符合預期效果了，但是前面的那個nginx鏡像對chmod系統調用沒有效果。

這里我們再增加下一條系統調用規則（阻止mkdir命令的使用）

#修改sccomp策略文件：n[root@k8s-node2 ~]#vi /var/lib/kubelet/seccomp/chmod.jsonn{n"defaultAction": "SCMP_ACT_ALLOW",n"syscalls": [n {n "names": [n "chmod",n "mkdir"n ],n "action": "SCMP_ACT_ERRNO"n }n ]n}nn#創建新的測試podn#這個需要重新創建pod才能生效：n#而AppArmor是修改就能生效，是加載到內核里的。n[root@k8s-master1 seccomp]#cp pod.yaml pod3.yamln[root@k8s-master1 seccomp]#cp pod2.yaml pod4.yamln[root@k8s-master1 seccomp]#vim pod3.yamlnapiVersion: v1nkind: Podnmetadata:n name: hello-seccomp3nspec:n nodeName: "k8s-node2"n securityContext:n seccompProfile:n type: Localhostn localhostProfile: chmod.jsonn containers:n - image: nginxn name: webnn[root@k8s-master1 seccomp]#vim pod4.yaml napiVersion: v1nkind: Podnmetadata:n name: hello-seccomp4 nspec:n nodeName: "k8s-node2"n securityContext:n seccompProfile:n type: Localhostn localhostProfile: chmod.jsonn containers:n - image: busyboxn name: busyboxn command:n - sleepn - 24h nn#部署：n[root@k8s-master1 seccomp]#kubectl apply -f pod3.yaml npod/hello-seccomp3 createdn[root@k8s-master1 seccomp]#kubectl apply -f pod4.yamlnpod/hello-seccomp4 creatednn#測試：n[root@k8s-master1 seccomp]#kubectl get ponNAME READY STATUS RESTARTS AGEn……nhello-seccomp3 0/1 Error 2 25snhello-seccomp4 1/1 Running 0 22sn[root@k8s-master1 seccomp]#kubectl logs hello-seccomp3 n/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configurationn/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/n/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.shn10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.confn10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.confn/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.shn/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.shn/docker-entrypoint.sh: Configuration complete; ready for start upn2023/05/27 23:40:25 [emerg] 1#1: mkdir() "/var/cache/nginx/client_temp" failed (1: Operation not permitted)nnginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (1: Operation not permitted)nn[root@k8s-master1 seccomp]#kubectl exec -it hello-seccomp4 -- shn/ # chmod 777 /etc/hostsnchmod: /etc/hosts: Operation not permittedn/ # mkdir anmkdir: can't create directory 'a': Operation not permittedn/ #

可以看到，nginx鏡像的pod無法啟動，報nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (1: Operation not permitted)錯誤。

說明禁用mkdir命令成功了，同樣busybox鏡像也是可以禁用成功的。

至于，chmod命令nginx鏡像沒能實現效果，可能和鏡像有關吧（或者系統調用的名稱不同）。

[root@k8s-master1 seccomp]#kubectl exec -it hello-seccomp -- bash #(nginx鏡像)nroot@hello-seccomp:/# cat /etc/issuenDebian GNU/Linux 11 n l

測試結束。

關于我

我的博客主旨：

• 排版美觀，語言精煉；
• 文檔即手冊，步驟明細，拒絕埋坑，提供源碼；
• 本人實戰文檔都是親測成功的，各位小伙伴在實際操作過程中如有什么疑問，可隨時聯系本人幫您解決問題，讓我們一起進步！

微信二維碼 x2675263825 （舍得）， qq：2675263825。

微信公眾號 《云原生架構師實戰》

語雀

https://www.yuque.com/xyy-onlyone

csdn https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

知乎 https://www.zhihu.com/people/foryouone

最后

好了，關于本次就到這里了，感謝大家閱讀，最后祝大家生活快樂，每天都過的有意義哦，我們下期見！