作者 |阿里云容器安全專家，徐越（樂枕）

龍崗網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián)公司,龍崗網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為龍崗上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)營(yíng)銷網(wǎng)站建設(shè)要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的龍崗做網(wǎng)站的公司定做！

責(zé)編 | 屠敏

頭圖 | CSDN 下載自東方 IC

出品 | CSDN（ID：CSDNnews）

容器化帶來的安全隱患

過去的2019 年是企業(yè)容器化爆發(fā)的一年。據(jù)統(tǒng)計(jì)已經(jīng)有超過 90% 的互聯(lián)網(wǎng)企業(yè)正在部署或使用容器，希望能通過更為敏捷的方式快速響應(yīng)市場(chǎng)需求。

然而，伴隨著容器技術(shù)的快速發(fā)展，容器安全問題也逐漸成為企業(yè)所關(guān)注的話題，同時(shí)，開發(fā)和運(yùn)維人員缺乏對(duì)容器的安全威脅和實(shí)踐的認(rèn)識(shí)也可能會(huì)使業(yè)務(wù)從一開始就埋下安全隱患。Tripwire的調(diào)研顯示，60%的受訪者所在公司在過去的一年中發(fā)生過至少一起容器安全事故。在部署規(guī)模超過100個(gè)容器的公司中，安全事故的比例上升到了75%，由此可見，快速擁抱容器化帶來的安全風(fēng)險(xiǎn)不容忽視。本文對(duì)云上容器ATT&CK矩陣做了詳細(xì)闡述，希望能幫助開發(fā)和運(yùn)維人員了解容器的安全風(fēng)險(xiǎn)和落地安全實(shí)踐。

云上容器攻擊矩陣概覽

ATT＆CK框架（Reference ATTACK Matrix for Container on Cloud）是網(wǎng)絡(luò)攻擊中涉及的已知策略和技術(shù)的知識(shí)庫(kù)。為便于企業(yè)構(gòu)建容器化應(yīng)用安全體系，阿里云在傳統(tǒng)主機(jī)安全的基礎(chǔ)上，圍繞自建容器集群以及云原生容器服務(wù)場(chǎng)景，通過全面分析黑客攻擊Docker和K8s的過程和手段，推出容器安全ATT&CK矩陣，讓黑客無所遁形，助力企業(yè)全面提升容器安全能力水位。

云上容器ATT&CK矩陣詳解

1. Initial Access/初始訪問

1.1 云賬號(hào)AK泄露

云平臺(tái)安全是云服務(wù)(容器服務(wù)、VM服務(wù))的基礎(chǔ)，如果業(yè)務(wù)代碼需要通過AccessKey的方式進(jìn)行鑒權(quán)并與云服務(wù)通信，應(yīng)至少為每個(gè)云服務(wù)創(chuàng)建子賬號(hào)并賦予需要的最小權(quán)限，同時(shí)推薦使用云平臺(tái)提供的角色（如阿里云RAM角色）進(jìn)行認(rèn)證和授權(quán)。在實(shí)踐中我們發(fā)現(xiàn)，存在部分管理員在進(jìn)行代碼托管時(shí)，使用主賬號(hào)AK(擁有全部云資源控制權(quán)限)并不慎將其泄露到公開倉(cāng)庫(kù)（如Github），進(jìn)而導(dǎo)致其云服務(wù)遭受入侵的場(chǎng)景，針對(duì)這一風(fēng)險(xiǎn)點(diǎn)，需要企業(yè)在使用云原生服務(wù)及容器化應(yīng)用的過程中時(shí)刻關(guān)注。

1.2 使用惡意鏡像

部分容器開發(fā)者會(huì)使用公開的鏡像源(如dockerhub)下載鏡像并在業(yè)務(wù)環(huán)境中運(yùn)行，但如果不慎使用了存在漏洞的鏡像，會(huì)給業(yè)務(wù)帶來安全風(fēng)險(xiǎn)。此外，攻擊者時(shí)常會(huì)將惡意鏡像部署到dockerhub，并通過誘導(dǎo)安裝或鏈路劫持對(duì)企業(yè)進(jìn)行供應(yīng)鏈攻擊。

示例：一個(gè)在Dockerhub中偽裝成mysql的惡意鏡像，同時(shí)攜帶了挖礦程序：

1.3 K8sAPI Server 未授權(quán)訪問

K8s API Server作為K8s集群的管理入口，通常使用8080和6443端口，其中8080端口無需認(rèn)證，6443端口需要認(rèn)證且有TLS保護(hù)。

如果開發(fā)者使用8080端口，并將其暴露在公網(wǎng)上，攻擊者就可以通過該端口API，直接對(duì)集群下發(fā)指令，或訪問/ui進(jìn)入K8s集群管理dashboard，操作K8s實(shí)施破壞。

1.4 K8s configfile 泄露

K8s configfile作為k8s集群的管理憑證，其中包含有關(guān)K8s集群的詳細(xì)信息，包括它們API Server的地址和登錄憑證。在購(gòu)買托管容器服務(wù)時(shí)，云廠商會(huì)向用戶提供該文件以便于用戶可以通過kubectl對(duì)集群進(jìn)行管理。如果攻擊者能夠訪問到此文件（如辦公網(wǎng)員工機(jī)器入侵、泄露到Github的代碼等），就可以直接通過API Server接管K8s集群，帶來風(fēng)險(xiǎn)隱患。

示例：阿里云容器服務(wù)K8s configfile：

1.5 Docker daemon公網(wǎng)暴露

Docker以client-server模式工作，其中docker daemon服務(wù)在后臺(tái)運(yùn)行，負(fù)責(zé)管理容器的創(chuàng)建、運(yùn)行和停止操作，并提供docker許多其他運(yùn)行時(shí)功能。執(zhí)行docker命令會(huì)調(diào)用一個(gè)客戶端，該客戶端通過Docker的REST API將命令發(fā)送到服務(wù)端(docker daemon)。

在Linux主機(jī)上，docker daemon監(jiān)聽它在/var/run/docker.sock中創(chuàng)建的unix socket。為了使docker daemon可管理，可以通過配置TCP socket將其暴露在網(wǎng)絡(luò)中，一般情況下2375端口用于未認(rèn)證的HTTP通信，2376用于可信的HTTPS通信。

如果管理員測(cè)試業(yè)務(wù)時(shí)配置不當(dāng)導(dǎo)致docker.sock通過2375暴露在公網(wǎng)，攻擊者即可通過該API接管docker服務(wù)。

示例：Docker daemon的2375端口的暴露：

dockerdaemon-Htcp://0.0.0.0:2375-Hunix:///var/run/docker.sock

1.6 容器內(nèi)應(yīng)用漏洞入侵

同主機(jī)安全一樣，容器中運(yùn)行的應(yīng)用側(cè)漏洞（如WEB應(yīng)用RCE漏洞、Redis未授權(quán)訪問等）也會(huì)成為黑客的突破口，攻擊者可以利用這些漏洞進(jìn)入容器內(nèi)部并發(fā)起進(jìn)一步攻擊。

1.7 Master節(jié)點(diǎn)SSH登錄憑證泄露

常見的容器集群管理方式是通過登錄Master節(jié)點(diǎn)或運(yùn)維跳板機(jī)，然后再通過kubectl命令工具來控制k8s。在此情況下，前置節(jié)點(diǎn)的SSH憑證泄露或被攻破也會(huì)使K8s集群暴露在風(fēng)險(xiǎn)中。

1.8 私有鏡像庫(kù)暴露

在容器化應(yīng)用場(chǎng)景中，公司使用鏡像來進(jìn)行持續(xù)集成和自動(dòng)化部署，這些鏡像往往通過專用的私有鏡像庫(kù)來管理。暴露在公網(wǎng)的私有鏡像庫(kù)極有可能遭受攻擊者入侵，并通過劫持供應(yīng)鏈來滲透下游業(yè)務(wù)。

以Harbor為例，Harbor是一個(gè)用于存儲(chǔ)和分發(fā)Docker鏡像的企業(yè)級(jí)Registry開源服務(wù)器，集成了Docker Hub、Docker Registry、谷歌容器等。它提供了一個(gè)簡(jiǎn)單的GUI，允許用戶根據(jù)自己的權(quán)限下載、上傳和掃描鏡像。在過去的數(shù)年里，Harbor逐漸受到人們的關(guān)注并成為CNCF的孵化項(xiàng)目，被企業(yè)廣泛應(yīng)用。Harbor在2019年披露了一個(gè)嚴(yán)重漏洞CVE-2019-16097，該漏洞允許攻擊者通過發(fā)送惡意請(qǐng)求以管理員權(quán)限創(chuàng)建用戶，從而接管Harbor。該漏洞利用方式簡(jiǎn)單，對(duì)暴露在公網(wǎng)的Harbor服務(wù)構(gòu)成較大威脅。

2.Execution/執(zhí)行

2.1 通過kubectl進(jìn)入容器

Kubectl是一個(gè)管理k8s集群的命令行工具，kubectl在$HOME/.kube目錄中尋找一個(gè)名為config的文件并連接API Server進(jìn)行鑒權(quán)操作。攻擊者可以通過kubectl exec指令在任意pod內(nèi)部執(zhí)行命令。

示例：kubectl exec進(jìn)入pod內(nèi)部執(zhí)行指令：

xy@x-8~/D/t/K8s_demo>kubectlgetpod

NAMEREADYSTATUSRESTARTSAGE

app-1-wp-01/1Running0182d

app-1-wp-11/1Running0182d

myapp1/1Running011d

myappnew1/1Running011d

xy@x-8~/D/t/K8s_demo>kubectlexec-itmyappnew/bin/bash

root@myappnew:/#whoami

root

2.2 創(chuàng)建后門容器

攻擊者可通過擁有pods權(quán)限的用戶創(chuàng)建基礎(chǔ)鏡像并利用其執(zhí)行后續(xù)滲透操作。

示例：通過yaml文件創(chuàng)建pod，并將pod的根目錄/掛載到容器/mnt目錄下，操作宿主機(jī)文件：

xy@x-8~/D/test>catmymaster.yaml

apiVersion:v1

kind:Pod

metadata:

name:myappnew

spec:

containers:

-image:nginx

name:container

volumeMounts:

-mountPath:/mnt

name:test-volume

volumes:

-name:test-volume

hostPath:

path:/

xy@x-8~/D/test>kubectlcreate-f~/Desktop/test/mymaster.yaml

pod/myappnewcreated

xy@x-8~/D/test>kubectlexec-itmyappnew/bin/bash

root@myappnew:/#cd/mnt

root@myappnew:/mnt#ls

bincheckappetcliblost+foundmntprocrunsrvtmpvar

bootdevhomelib64mediaoptrootsbinsysusr

2.3 通過K8s控制器部署后門容器

Kubernetes中運(yùn)行了一系列控制器(Controllers)來確保集群的當(dāng)前狀態(tài)與期望狀態(tài)保持一致。例如，ReplicaSet控制器負(fù)責(zé)維護(hù)集群中運(yùn)行的Pod數(shù)量；Node控制器負(fù)責(zé)監(jiān)控節(jié)點(diǎn)的狀態(tài)，并在節(jié)點(diǎn)出現(xiàn)故障時(shí)及時(shí)做出響應(yīng)。

攻擊者在擁有controllers權(quán)限情況下可以通過ReplicaSet/DaemonSet/Deplyment創(chuàng)建并維持后門容器。

示例：攻擊者通過controllers攻擊：

xy@x-8~/D/test>catnginx-deploy.yaml

apiVersion:apps/v1

kind:Deployment

metadata:

name:nginx-deployment

labels:

app:nginx-test

spec:

replicas:1

selector:

matchLabels:

app:nginx

template:

metadata:

labels:

app:nginx

spec:

containers:

-image:nginx

name:container

volumeMounts:

-mountPath:/mnt

name:test-volume

volumes:

-name:test-volume

hostPath:

path:/

xy@x-8~/D/test>kubectlapply-fnginx-deploy.yaml

deployment.apps/nginx-deploymentcreated

xy@x-8~/D/test>kubectlgetpods

NAMEREADYSTATUSRESTARTSAGE

app-1-wp-01/1Running0183d

app-1-wp-11/1Running0183d

myapp1/1Running012d

myappnew1/1Running038m

nginx-deployment-b676778d6-lcz4p1/1Running055s

2.4 利用Service Account連接API Server執(zhí)行指令

Kubernetes區(qū)分用戶和服務(wù)(Service Account)兩種賬戶，其中用戶賬戶便于管理員與集群交互，服務(wù)賬號(hào)用于Pod進(jìn)程調(diào)用Kubernetes API或其他外部服務(wù)。

K8s pod中默認(rèn)攜帶服務(wù)賬戶的訪憑證，如果被入侵的pod存在高權(quán)限的用戶，則容器中可以直接通過service account向K8s下發(fā)指令。

示例：service account在容器內(nèi)部的默認(rèn)路徑：

cd/var/run/secrets/kubernetes.io/serviceaccount

示例：帶憑證訪問API server的方式：

curl-voa-shttps://192.168.0.234:6443/version

#以下命令相當(dāng)于kubectlgetno

curl-shttps://192.168.0.234:6443/api/v1/nodes?watch--headerAuthorization:BearereyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tOGprZmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2DydmljZS1hY2NvdW50LnVpZCI6Ijg4Y2ZmNmYzLWY0NzktMTFlOS1iZmY1LTJlYzU3MmZlMWRjOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.OU740qNcSf0Z__vAO1XJWUw9fvNNI2e4LxHypkpzREmnqrK9UZ-rrp9tG8Vxbc65FlPFj9efdpfWYExxjDDQwQTi-5Afmk4EA6EH-4vEs4V1r4gb0za8cyPVSAjzmEh7uIMgQHVo7y32V_BqUd8cmBoTdgnTY8Nx2QvMClvoYvEWvDKhbMnQjWH1x5Z6jK0iNg7btlK_WXnz8-yU2a0-jgoZFZ8D_qX16mZJ_ZoxEwPNTeNR8pP1l3ebZGVqBQA1PIFVG4HOlYomZya_DWGleMRYpulnECtBOTYyswzCwN8qJUVsdv6yWH1blWHKzYrkcoDmp2r6QhekaG1KFoX_YA--cacertca.crt

2.5 帶有SSH服務(wù)的容器

含有SSH服務(wù)的容器暴露了新的攻擊面，由于暴力破解或者登錄憑證泄露，攻擊者可以進(jìn)入到容器內(nèi)部執(zhí)行指令進(jìn)行惡意操作。這種情況多見于自建容器或K8s環(huán)境(一些運(yùn)維人員將容器當(dāng)做VM使用)。此外當(dāng)攻擊者逃逸到node節(jié)點(diǎn)時(shí)可以通過添加賬號(hào)或?qū)懭?.ssh/authorized_keys等方式利用SSH下發(fā)后續(xù)惡意指令。

2.6 通過云廠商CloudShell下發(fā)指令

針對(duì)VM和容器服務(wù)的管理，云服務(wù)商往往會(huì)提供沙箱化的便捷管理工具，在云賬號(hào)憑證泄露的情況下，攻擊者可以通過云廠商提供的API接管集群。此外云廠商沙箱本身的安全問題也會(huì)影響到用戶集群安全。

示例：通過Cloud Shell管理集群：

3.Persistence/持久化

3.1 部署遠(yuǎn)控客戶端

（參考2.3部分通過K8s控制器部署后門容器）攻擊者通過K8s DaemonSet向每個(gè)Node中植入后門容器，這些容器可以設(shè)置為特權(quán)容器并通過掛載宿主機(jī)的文件空間來進(jìn)一步向每個(gè)Node植入二進(jìn)制并遠(yuǎn)控客戶端，從而完成Node層持久化，且后續(xù)操作不會(huì)觸發(fā)K8s層的審計(jì)策略。

3.2 通過掛載目錄向宿主機(jī)寫入文件

一種常見的容器逃逸方法，如果容器/Pod啟動(dòng)時(shí)將VM的核心目錄以寫權(quán)限掛載(如/root, /proc, /etc等)，則攻擊者進(jìn)入容器后可以修改敏感文件進(jìn)行逃逸，如利用/etc/crontab執(zhí)行定時(shí)任務(wù)、修改/root/.ssh/authorized_keys獲取SSH登錄權(quán)限、讀取其他進(jìn)程空間內(nèi)容等。

示例：不安全的目錄掛載：

dockerrun-it-v/root:/rootubuntu/bin/bash

寫入SSH憑證

(echo-enn;catid_rsa_new.pub)>>/root/.ssh/authorized_keys

3.3 K8s cronjob持久化

Cronjob是K8s controller的一種，用于創(chuàng)建基于時(shí)間的調(diào)度任務(wù)(類似主機(jī)的/etc/crontab)。攻擊者在獲取controller create權(quán)限后可以創(chuàng)建cronjob實(shí)現(xiàn)持久化。

示例：cronjob持久化

xy@x-8~/D/test>catcronjob.yaml

apiVersion:batch/v1beta1

kind:CronJob

metadata:

name:echotest

spec:

schedule:*/1****

jobTemplate:

spec:

template:

spec:

containers:

-name:container

image:nginx

args:

-/bin/sh

--c

-echotest

restartPolicy:OnFailure

xy@x-8~/D/test>kubectlcreate-fcronjob.yaml

cronjob.batch/echotestcreated

xy@x-8~/D/test>kubectlgetcronjobs

NAMESCHEDULESUSPENDACTIVELASTSCHEDULEAGE

echotest*/1****False326s3m8s

3.4 在私有鏡像庫(kù)的鏡像中植入后門

（參考1.8私有鏡像庫(kù)暴露）攻擊者在接管企業(yè)私有鏡像庫(kù)之后，可以進(jìn)行拉取私有鏡像竊取信息、刪除倉(cāng)庫(kù)中的鏡像、替換倉(cāng)庫(kù)中的鏡像、為已有鏡像添加后門、在鏡像服務(wù)中創(chuàng)建后門賬號(hào)等惡意操作。

一種持久化攻擊方式是在dockerfile中加入額外的惡意指令層來執(zhí)行惡意代碼，同時(shí)該方法可以自動(dòng)化并具有通用性。同時(shí)在Docker鏡像的分層存儲(chǔ)中，每一層的變化都將以文件的形式保留在image內(nèi)部，一種更為隱蔽的持久化方式是直接編輯原始鏡像的文件層，將鏡像中原始的可執(zhí)行文件或鏈接庫(kù)文件替換為精心構(gòu)造的后門文件之后再次打包成新的鏡像，從而實(shí)現(xiàn)在正常情況下無行為，僅在特定場(chǎng)景下觸發(fā)的持久化工具。

3.5 修改核心組件訪問權(quán)限

攻擊者通過ConfigMap修改Kubelet使其關(guān)閉認(rèn)證并允許匿名訪問，或暴露API Server的未授權(quán)HTTP接口，使其在后續(xù)滲透過程中擁有持續(xù)的后門命令通道。

4. Privilege Escalation/權(quán)限提升

4.1 利用特權(quán)容器逃逸

Docker允許特權(quán)容器訪問宿主機(jī)上的所有設(shè)備，同時(shí)修改AppArmor或SELinux的配置，使特權(quán)容器擁有與那些直接運(yùn)行在宿主機(jī)上的進(jìn)程幾乎相同的訪問權(quán)限。在這種情況下，攻擊者從特權(quán)容器逃逸是極其容易實(shí)現(xiàn)的。

示例：將系統(tǒng)盤掛載到容器內(nèi)部，讀寫宿主機(jī)文件：

root@d000b330717d:/#fdisk-l

Disk/dev/vda:40GiB,42949672960bytes,83886080sectors

Units:sectorsof1*512=512bytes

Sectorsize(logical/physical):512bytes/512bytes

I/Osize(minimum/optimal):512bytes/512bytes

Disklabeltype:dos

Diskidentifier:0xe2eb87fa

DeviceBootStartEndSectorsSizeIdType

/dev/vda1*2048838860468388399940G83Linux

root@d000b330717d:/#mkdir/mnt1

root@d000b330717d:/#mount/dev/vda1/mnt1

root@d000b330717d:/#cd/mnt1

root@d000b330717d:/mnt1#ls

binetcinitrd.img.oldlost+foundoptrunsysvar

boothomelibmediaprocsbintmpvmlinuz

devinitrd.imglib64mntrootsrvusrvmlinuz.old

4.2 K8s Rolebinding添加用戶權(quán)限

K8s使用基于角色的訪問控制(RBAC)來進(jìn)行操作鑒權(quán)，允許管理員通過 Kubernetes API 動(dòng)態(tài)配置策略。某些情況下運(yùn)維人員為了操作便利，會(huì)對(duì)普通用戶授予cluster-admin的角色，攻擊者如果收集到該用戶登錄憑證后，可直接以高權(quán)限接管K8s集群。少數(shù)情況下，攻擊者可以先獲取角色綁定(RoleBinding)權(quán)限，并將其他用戶添加cluster-admin或其他高權(quán)限角色來完成提權(quán)。

4.3 利用掛載目錄逃逸

參考（3.2通過掛載目錄向宿主機(jī)寫入文件），攻擊者在容器內(nèi)部可以利用掛載通道修改宿主機(jī)文件來實(shí)現(xiàn)逃逸。

4.4 利用操作系統(tǒng)內(nèi)核漏洞逃逸

操作系統(tǒng)內(nèi)核安全（如Linux內(nèi)核）是容器安全體系的基石，是實(shí)現(xiàn)容器隔離設(shè)計(jì)的前提。內(nèi)核漏洞的利用往往從用戶空間非法進(jìn)入內(nèi)核空間開始，在內(nèi)核空間賦予當(dāng)前或其他進(jìn)程高權(quán)限以完成提權(quán)操作。在云原生場(chǎng)景中，云廠商會(huì)在VM層為操作系統(tǒng)內(nèi)核漏洞進(jìn)行補(bǔ)丁修復(fù)，避免用戶被已公開的內(nèi)核漏洞攻擊。

4.5 利用Docker漏洞逃逸

Docker軟件歷史上出現(xiàn)過多個(gè)高危安全漏洞，目前仍有一定影響的是兩個(gè)2019年的漏洞：Docker runc RCE(CVE-2019-5736)和Docker cp RCE(CVE-2019-14271)。兩個(gè)漏洞均利用了Docker本身的功能設(shè)計(jì)缺陷，利用覆蓋容器內(nèi)部runc文件、libnss庫(kù)，從而實(shí)現(xiàn)從容器到宿主機(jī)的逃逸行為。從攻擊者角度來看，這兩個(gè)漏洞均需要與宿主機(jī)交互才會(huì)觸發(fā)payload執(zhí)行，實(shí)戰(zhàn)中并不高效，但Docker既要隔離又要通信的機(jī)制設(shè)計(jì)或許會(huì)在未來暴露出更多問題。在云服務(wù)商提供的托管K8s集群以及Serverless服務(wù)中，Docker服務(wù)自身安全性會(huì)由云服務(wù)商維護(hù)，相比自建，安全性會(huì)更有保障。

4.6 利用K8s漏洞進(jìn)行提權(quán)

容器化基礎(chǔ)設(shè)施每一環(huán)的軟件漏洞都會(huì)帶來安全風(fēng)險(xiǎn)。Kubernetes特權(quán)升級(jí)漏洞(CVE-2018-1002105)允許普通用戶在一定前提下提升至K8s API Server的高權(quán)限。該漏洞需要用戶擁有對(duì)某個(gè)namespace下pod的操作權(quán)限，同時(shí)需要client到API Server和kubelet的網(wǎng)絡(luò)通路來實(shí)施攻擊。同樣，該漏洞在云服務(wù)中已經(jīng)被服務(wù)商修復(fù)，在自建的K8s集群中仍有發(fā)揮空間。

4.7 容器內(nèi)訪問docker.sock逃逸

當(dāng)docker.sock被掛載到容器內(nèi)部時(shí)，攻擊者可以在容器內(nèi)部訪問該socket，管理docker daemon。

docker-v/var/run/docker.sock:/var/run/docker.sock

此時(shí)容器內(nèi)部可以與docker deamon通信，并另起一個(gè)高權(quán)限的惡意容器，從而拿到root shell。

示例：與docker deamon通信：

find/-namedocker.sock

curl--unix-socket/var/run/docker.sockhttp://127.0.0.1/containers/json

4.8 利用Linux Capabilities逃逸

容器即隔離，容器在設(shè)計(jì)上使用cgroup、namespace等對(duì)宿主機(jī)的資源進(jìn)行隔離及調(diào)度使用，同時(shí)也支持使用Linux capabilities做細(xì)粒度的權(quán)限管控。從這一角度來看，不安全的權(quán)限分配會(huì)為容器逃逸提供通路。

示例：K8s YAML配置中對(duì)capabilities的支持：

securityContext:

capabilities:

drop:

-ALL

add:

-NET_BIND_SERVICE

docker會(huì)以白名單方式賦予容器運(yùn)行所需的capabilities權(quán)限，我們可以在docker run命令中使用 --cap-add 以及 --cap-drop 參數(shù)控制capabilities。以下命令對(duì)容器開放了宿主機(jī)的進(jìn)程空間，同時(shí)賦予容器CAP_SYS_PTRACE權(quán)限，此時(shí)攻擊者在容器內(nèi)部可以注入宿主機(jī)進(jìn)程從而實(shí)現(xiàn)逃逸。

dockerrun-it--pid=host--cap-add=CAP_SYS_PTRACEubuntu

5. DefenseEvasion/防御逃逸

5.1 容器及宿主機(jī)日志清理

攻擊者在獲得一定權(quán)限之后，可以擦除容器內(nèi)部及宿主機(jī)的系統(tǒng)日志以及服務(wù)日志，為企業(yè)的入侵事件復(fù)盤以及溯源增加難度。目前容器運(yùn)行時(shí)安全解決方案中均采用實(shí)時(shí)的日志采集、自保護(hù)方案以及日志采集異常的預(yù)警，來解決日志惡意擦除導(dǎo)致的溯源問題。同時(shí)，在云原生的容器攻防戰(zhàn)場(chǎng)中，惡意卸載安全產(chǎn)品agent以切斷日志采集能力也逐漸成為了常見的攻擊方式。

5.2K8s Audit日志清理

Kubernetes Audit功能提供了與安全相關(guān)的按時(shí)間順序排列的記錄集，記錄單個(gè)用戶、管理員或系統(tǒng)其他組件影響系統(tǒng)的活動(dòng)順序。日志提供了包括事件、時(shí)間、用戶、作用對(duì)象、發(fā)起者、執(zhí)行結(jié)果等詳細(xì)信息，為運(yùn)行時(shí)安全審計(jì)提供便利。攻擊者可以通過清理本地日志文件(用戶/服務(wù)商可自定義位置)以及切斷服務(wù)商/安全產(chǎn)品的日志上傳通道(卸載agent或者阻斷網(wǎng)絡(luò)通路)來隱藏對(duì)K8s集群的操作，一些容器安全產(chǎn)品通過K8s AuditSink功能將日志導(dǎo)出到外部審計(jì)，也可通過修改K8s配置進(jìn)行開啟或關(guān)閉。

示例：阿里云容器服務(wù)KubernetesAudit審計(jì)中心：

5.3利用系統(tǒng)Pod偽裝

K8s在部署時(shí)會(huì)在kube-system namespace中置一些常見的功能性pod。在云廠商提供的容器服務(wù)中，集群還會(huì)默認(rèn)攜帶一些云服務(wù)的組件(如日志采集、性能監(jiān)控的agent)。攻擊者可以利用常見的K8s內(nèi)置pod作為后門容器，或?qū)⒑箝T代碼植入這些pod來實(shí)現(xiàn)隱蔽的持久化。

示例：阿里云托管版K8s服務(wù)內(nèi)置pod：

xy@x-8~/D/test>kubectlgetdeployments--namespace=kube-system

NAMEREADYUP-TO-DATEAVAILABLEAGE

alibaba-log-controller1/111183d

alicloud-application-controller1/111183d

alicloud-disk-controller1/111183d

alicloud-monitor-controller1/111183d

aliyun-acr-credential-helper1/111183d

coredns2/222183d

metrics-server1/111183d

nginx-ingress-controller2/222183d

tiller-deploy1/111183d

5.4通過代理或匿名網(wǎng)絡(luò)訪問K8s API Server

利用代理或匿名網(wǎng)絡(luò)執(zhí)行攻擊是常見的反溯源行為，在K8s Audit日志中記錄了每個(gè)行為發(fā)起者的源IP，通過公網(wǎng)訪問API Server的IP將會(huì)被記錄并觸發(fā)異常檢測(cè)和威脅情報(bào)的預(yù)警。

示例：K8s Audit日志對(duì)pod exec行為的記錄：

5.5清理安全產(chǎn)品Agent

目前主流容器運(yùn)行時(shí)的安全產(chǎn)品部署方式有兩種：平行容器模式和主機(jī)agent模式。前者創(chuàng)建安全容器采集pod、K8s集群日志以及實(shí)現(xiàn)網(wǎng)絡(luò)代理；后者在VM層對(duì)容器層的進(jìn)程網(wǎng)絡(luò)文件進(jìn)行采集。攻擊者在獲取到集群管理權(quán)限或逃逸到宿主機(jī)時(shí)，可以通過清理掉安全產(chǎn)品植入的探針，破壞日志完整性，使后續(xù)攻擊行為無法被審計(jì)工具發(fā)現(xiàn)。在這一過程中，安全容器或主機(jī)agent異常離線往往會(huì)觸發(fā)保護(hù)性告警。

5.6 創(chuàng)建影子API Server

攻擊者可以復(fù)制原生API Server的配置，修改關(guān)鍵參數(shù)（例如關(guān)閉認(rèn)證，允許匿名訪問，使用HTTP請(qǐng)求），再使用這些修改過的參數(shù)創(chuàng)建Pods。攻擊者可以通過這個(gè)影子API Server直接獲取etcd內(nèi)存儲(chǔ)的內(nèi)容，使后續(xù)滲透行為在審計(jì)日志中匿名。

5.7 創(chuàng)建超長(zhǎng)annotations使K8s Audit日志解析失敗

一般情況下云廠商/安全產(chǎn)品會(huì)使用自身日志服務(wù)的agent對(duì)K8s Audit日志進(jìn)行采集和解析，以便于與后續(xù)審計(jì)規(guī)則結(jié)合。在入侵檢測(cè)中，日志的采集-存儲(chǔ)-計(jì)算的過程會(huì)受限于agent的性能占用、Server端日志服務(wù)以及其他云產(chǎn)品/開源組件對(duì)存儲(chǔ)和計(jì)算的限制，過長(zhǎng)的字段將有可能觸發(fā)截?cái)?，?dǎo)致敏感信息無法經(jīng)過審計(jì)規(guī)則從而繞過入侵檢測(cè)，K8s API請(qǐng)求中允許攜帶1.5MiB的數(shù)據(jù)，但在Google StackDriver日志服務(wù)僅允許解析256KB的內(nèi)容，這將導(dǎo)致Audit日志中的敏感信息(如創(chuàng)建Pod時(shí)的磁盤掛載配置項(xiàng))繞過審計(jì)。

示例：通過無意義的超長(zhǎng)annotations攻擊日志分析鏈路：

apiVersion:v1

kind:Pod

metadata:

name:annotations-bypass

annotations:

useless-key:useless-value(1MiB)

...

6. Credential Access/竊取憑證

6.1 K8s Secret泄露

K8s使用Secret對(duì)象對(duì)access key、密碼、OAuth token和ssh key等敏感信息進(jìn)行統(tǒng)一管理。pod定義時(shí)可以引用secret對(duì)象以便在運(yùn)行時(shí)訪問。攻擊者可以通過pod內(nèi)部service account或更高權(quán)限用戶來獲取這些secret內(nèi)容，從中竊取其他服務(wù)的通信憑證。

示例：查看并下載K8s secret保存的憑據(jù)：

xy@x-8~>kubectlgetsecrets--namespace=kube-system

NAMETYPEDATAAGE

admin-token-ltbcrkubernetes.io/service-account-token3184d

alibaba-log-controller-token-9kv4mkubernetes.io/service-account-token3184d

aliyun-acr-credential-helper-token-vwmlwkubernetes.io/service-account-token3184d

attachdetach-controller-token-l5bfhkubernetes.io/service-account-token3184d

bootstrap-signer-token-qbrx7kubernetes.io/service-account-token3184d

bootstrap-token-509e2bbootstrap.kubernetes.io/token6184d

certificate-controller-token-dgpjnkubernetes.io/service-account-token3184d

cloud-node-controller-token-647swkubernetes.io/service-account-token3184d

...

xy@x-8~>kubectlgetsecretalibaba-log-controller-token-9kv4m--namespace=kube-system-oyaml

6.2 云產(chǎn)品AK泄露

云原生的應(yīng)用部署流程中會(huì)涉及到各種云產(chǎn)品的API通信，當(dāng)某應(yīng)用被攻破后，攻擊者可以通過K8s secret或者掛載到本地的憑證文件來獲取相關(guān)服務(wù)的AK并進(jìn)行橫向移動(dòng)。一種常見的場(chǎng)景是：入侵WEB應(yīng)用后獲取云存儲(chǔ)(OSS)、云數(shù)據(jù)庫(kù)(RDS)、日志服務(wù)的通信憑證，并進(jìn)一步竊取數(shù)據(jù)。

示例：關(guān)于云產(chǎn)品AK的掃描規(guī)則已被工具化：

6.3 K8sService Account憑證泄露

此類場(chǎng)景多見于辦公網(wǎng)運(yùn)維PC、跳板機(jī)以及通過SSH管理的master節(jié)點(diǎn)上。黑客在攻破此類服務(wù)器時(shí)，可以檢查本地是否存在kubectl鑒權(quán)所需的配置文件(一般在$HOME/.kube/config)，該文件通常包含了登錄K8s集群的全部信息。

6.4 應(yīng)用層API憑證泄露

在復(fù)雜業(yè)務(wù)場(chǎng)景以及微服務(wù)架構(gòu)中，K8s各個(gè)服務(wù)之間、容器與VM之間會(huì)通過API方式進(jìn)行通信，竊取其通信憑證可用于橫向滲透。

6.5 利用K8s準(zhǔn)入控制器竊取信息

K8s準(zhǔn)入控制器(Admission Controller)用于hook客戶端對(duì)API Server的請(qǐng)求。其中變更(mutating)控制器可以修改被其接受的對(duì)象；驗(yàn)證(validating)控制器可以審計(jì)并判斷是否允許該請(qǐng)求通過。準(zhǔn)入控制器是可以串聯(lián)的，在請(qǐng)求到達(dá)API Server之前，如有任何一個(gè)控制器拒絕了該請(qǐng)求，則整個(gè)請(qǐng)求將立即被拒絕，并向終端用戶返回一個(gè)錯(cuò)誤。

為了便于用戶部署自己的準(zhǔn)入服務(wù)，K8s提供了動(dòng)態(tài)準(zhǔn)入控制(Admission Webhook)功能，即用于接收準(zhǔn)入請(qǐng)求并對(duì)其進(jìn)行處理的HTTP回調(diào)機(jī)制。

一種利用動(dòng)態(tài)準(zhǔn)入控制實(shí)現(xiàn)持久化的方式：攻擊者在獲取cluster-admin權(quán)限后，可以創(chuàng)建惡意的準(zhǔn)入控制器hook掉所有的API訪問，引用攻擊者的外部webhook作為validating服務(wù)，這樣k8s就會(huì)將攜帶敏感信息的API請(qǐng)求發(fā)送到攻擊者所用服務(wù)器。

示例：利用準(zhǔn)入控制器后門，使用通配符hook全部操作，使用failurePolicy和timeoutSeconds參數(shù)做到用戶側(cè)無感，從而實(shí)現(xiàn)隱蔽的數(shù)據(jù)竊取(如：K8s secret創(chuàng)建時(shí)發(fā)送到API的AK信息)。

apiVersion:admissionregistration.k8s.io/v1

kind:ValidatingWebhookConfiguration

...

webhooks:

-name:my-webhook.example.com

failurePolicy:Ignore

timeoutSeconds:2

rules:

-apiGroups:[*]

apiVersions:[*]

operations:[*]

resources:[*/*]

scope:*

...

7. Discovery/探測(cè)

7.1 訪問K8s API Server

（參考2.4利用Service Account連接API Server執(zhí)行指令）攻擊者進(jìn)入pod之后，可以通過curl或wget等http客戶端，或使用編譯好的報(bào)文構(gòu)造工具，直接訪問K8s REST API，當(dāng)service account具有高權(quán)限時(shí)可以直接下發(fā)命令進(jìn)行橫向移動(dòng)。而當(dāng)用戶具有低權(quán)限時(shí)，也可能通過API Server探測(cè)到集群內(nèi)部的資源信息、運(yùn)行狀態(tài)以及secret，有利于尋找下一個(gè)突破點(diǎn)。

7.2 訪問Kubelet API

在kubernetes集群中，每個(gè)Node節(jié)點(diǎn)都會(huì)啟動(dòng)Kubelet進(jìn)程，用來處理Master節(jié)點(diǎn)下發(fā)到本節(jié)點(diǎn)的任務(wù)，管理Pod和其中的容器。包括10250端口的認(rèn)證API、10255端口的只讀API以及10256端口的健康檢查API。

其中10255端口可以無需授權(quán)進(jìn)行只讀訪問，攻擊者可以訪問/pods獲取到node、pod地址以及pod的掛載情況、環(huán)境變量等敏感信息，輔助還原業(yè)務(wù)場(chǎng)景和集群網(wǎng)絡(luò)拓?fù)?，以尋找后續(xù)攻擊點(diǎn)。

關(guān)于Kubelet API官方并未提供文檔，更多接口可在Kubelet源碼中挖掘。一些有用的路徑：

http://{node_ip}:10255/pods

http://{node_ip}:10255/spec

10250的端口當(dāng)前版本中默認(rèn)需要認(rèn)證，但在老版本的K8s集群中或在用戶權(quán)限(system:anonymous)被錯(cuò)誤配置的情況下，可以嘗試直接通過10250端口下發(fā)指令。

示例：命令下發(fā)：

root@myappnew:/#curl--insecurehttps://192.168.0.237:10250/pods

Unauthorized

7.3 Cluster 內(nèi)網(wǎng)掃描

黑客通常會(huì)對(duì)Node、Pod、Service三個(gè)網(wǎng)段進(jìn)行主機(jī)存活探測(cè)和端口掃描，然后從K8s內(nèi)置服務(wù)、用戶應(yīng)用、第三方K8s插件等角度尋找更多攻擊面，同時(shí)會(huì)通過找到Node IP并訪問Kubelet API獲取pod的詳細(xì)拓?fù)湫畔ⅰ?/p>

阿里云容器服務(wù)默認(rèn)CIDR：

7.4 訪問K8s Dashboard所在的Pod

Kubernetes Dashboard為用戶提供WEB界面，便于創(chuàng)建、修改和管理Kubernetes資源(如 Deployment，Job，DaemonSet等)。Dashboard的部署取決于云廠商和用戶自身的配置，在官方的部署流程中，dashboard會(huì)創(chuàng)建獨(dú)立的Namespace、Service、Role以及ServiceAccount。

示例：阿里云容器服務(wù)提供的dashboard：

由于K8s pod之間默認(rèn)允許通信，攻擊者在進(jìn)入某個(gè)pod之后，可以通過信息收集或內(nèi)網(wǎng)掃描的方式發(fā)現(xiàn)K8s dashboard所在service地址，并通過kubernetes-dashboard service account進(jìn)行認(rèn)證操作。

7.5 訪問私有鏡像庫(kù)

參考1.8和3.4關(guān)于私有鏡像庫(kù)的攻擊面，攻擊者可以在K8s secret或本地配置文件中找到私有鏡像庫(kù)的連接方式，并在權(quán)限允許的情況下劫持私有鏡像庫(kù)中的鏡像，實(shí)現(xiàn)橫向移動(dòng)和持久化。

7.6 訪問云廠商服務(wù)接口

（參考6.2云產(chǎn)品AK泄漏）在云原生的容器化應(yīng)用中，服務(wù)往往會(huì)與多種內(nèi)外部API進(jìn)行交互，攻擊者可以通過收集這些API的登錄憑據(jù)或測(cè)試是否存在未授權(quán)訪問來進(jìn)行攻擊準(zhǔn)備。

此外，在某些云服務(wù)商提供的CaaS或Serverless容器中，為便于使用者與底層云基礎(chǔ)設(shè)施進(jìn)行通信，廠商通過植入專用pod或者將API掛載到業(yè)務(wù)pod的方式提供額外的接口，這些接口也會(huì)成為攻擊者收集信息過程中的突破口。

7.7 通過NodePort訪問Service

K8s service的暴露方式由三種ClusterIP，NodePort和LoadBalancer。其中LoadBalancer多與云廠商的負(fù)載均衡類產(chǎn)品集成，具有較強(qiáng)的流量審計(jì)能力。

一些業(yè)務(wù)場(chǎng)景中存在著K8s與VM并存的內(nèi)網(wǎng)環(huán)境，當(dāng)攻擊者通過非容器化的弱點(diǎn)進(jìn)入內(nèi)網(wǎng)時(shí)，可以借助NodePort進(jìn)行橫向移動(dòng)。在頻繁迭代的業(yè)務(wù)中，使用NodePort的服務(wù)相比ClusterIP更加固定，可用做控制通道來穿透網(wǎng)絡(luò)邊界管控以及防火墻的限制。

默認(rèn)情況下，K8s集群NodePort分配的端口范圍為：30000-32767。

8. Lateral Movement/橫向移動(dòng)

8.1 竊取憑證攻擊云服務(wù)

（參考6.2云產(chǎn)品AK泄漏）攻擊者利用容器內(nèi)部文件或K8s secret中竊取到的云服務(wù)通信憑證進(jìn)行橫向移動(dòng)。

8.2 竊取憑證攻擊其他應(yīng)用

參考第6節(jié)的各項(xiàng)內(nèi)容。在基礎(chǔ)設(shè)施高度容器化的場(chǎng)景中，絕大部分服務(wù)都是API化的，這使憑證竊取成為擴(kuò)展攻擊面、獲取目標(biāo)數(shù)據(jù)的重要手段。K8s集群、云產(chǎn)品以及自建應(yīng)用的通信憑證都是攻擊者竊取的目標(biāo)。

8.3通過Service Account訪問K8s API

（參考2.4利用Service Account連接API Server執(zhí)行指令）攻擊者在容器內(nèi)部可通過Service Account訪問K8s API刺探當(dāng)前pod用戶權(quán)限，并在權(quán)限允許的前提下對(duì)API下發(fā)指令或利用K8s提權(quán)漏洞訪問集群中的其他資源。

8.4Cluster內(nèi)網(wǎng)滲透

一般情況下，K8s會(huì)默認(rèn)允許Cluster內(nèi)部的pod與service之間直接通信，這構(gòu)成了一個(gè)大內(nèi)網(wǎng)環(huán)境。攻擊者在突破一個(gè)pod之后，可以通過內(nèi)網(wǎng)掃描收集服務(wù)信息并通過應(yīng)用漏洞、弱口令以及未授權(quán)訪問等方式滲透Cluster的其他資源。K8s支持通過自帶的網(wǎng)絡(luò)策略(NetworkPolicy)來定義pod的通信規(guī)則，一些網(wǎng)絡(luò)側(cè)插件、容器安全產(chǎn)品也支持東西向的通信審計(jì)與管控。

8.5 通過掛載目錄逃逸到宿主機(jī)

（參考3.2通過掛載目錄向宿主機(jī)寫入文件）攻擊者可以利用掛載到容器內(nèi)部的目錄完成從pod到node的移動(dòng)。

8.6 訪問K8sDashboard

（參考7.4訪問K8s Dashboard所在的Pod）攻擊者在進(jìn)入某個(gè)pod之后，可以通過信息收集或內(nèi)網(wǎng)掃描的方式發(fā)現(xiàn)K8s dashboard所在service地址，并在管理員權(quán)限配置失當(dāng)?shù)那闆r下通過K8s Dashboard下發(fā)指令。

8.7 攻擊第三方K8s插件

為了快速上手，很多K8s快速入門指南都會(huì)介紹一些好用的插件和配置方案，但教程的創(chuàng)建者很少考慮到真實(shí)生產(chǎn)業(yè)務(wù)中的安全問題，而這些插件往往在初始的幾個(gè)版本中存在鑒權(quán)方面的漏洞(如API默認(rèn)允許未授權(quán)訪問)，直到被攻擊者反復(fù)測(cè)試之后才會(huì)逐漸穩(wěn)定可靠。這些不安全的配置以及使用的第三方K8s插件/工具會(huì)引入新的攻擊面，并為橫向移動(dòng)提供便利。

示例：常見的利用第三方組件進(jìn)行橫向移動(dòng)的過程：

攻擊者進(jìn)入pod后，通過未授權(quán)訪問或漏洞攻擊第三方組件，并利用這些組件的權(quán)限操縱K8s集群。

9. Impact/影響

9.1 破壞系統(tǒng)及數(shù)據(jù)

以破壞為目的的攻擊者可能會(huì)停止或禁用系統(tǒng)上的服務(wù)、刪除某些核心文件及數(shù)據(jù)以使合法用戶無法使用這些服務(wù)。停止關(guān)鍵服務(wù)可能會(huì)抑制防御方對(duì)事件的響應(yīng)，并有利于攻擊者的最終目標(biāo)。

9.2 劫持資源

常見于攻擊者通過自動(dòng)化腳本入侵并植入挖礦程序進(jìn)行獲利。

9.3 DoS

攻擊者會(huì)發(fā)起DoS攻擊，影響系統(tǒng)的可用性。容器化場(chǎng)景中的DoS攻擊包括對(duì)業(yè)務(wù)層、K8s API層的攻擊以及對(duì)Pod資源的搶占。

9.4 加密勒索

在傳統(tǒng)主機(jī)安全場(chǎng)景中，有經(jīng)驗(yàn)的攻擊者會(huì)找到企業(yè)核心數(shù)據(jù)并對(duì)其進(jìn)行加密勒索。由于容器場(chǎng)景的資源彈性較大，且后端數(shù)據(jù)的產(chǎn)生、存儲(chǔ)、銷毀鏈路往往通過云服務(wù)API實(shí)現(xiàn)，而非在用戶磁盤上進(jìn)行，企業(yè)可以通過云原生的快照與備份服務(wù)來實(shí)現(xiàn)資產(chǎn)備份，避免核心數(shù)據(jù)丟失。

阿里云容器安全解決方案

阿里云容器服務(wù)（ACK）提供高性能可伸縮的容器應(yīng)用管理服務(wù)，支持企業(yè)級(jí)Kubernetes容器化應(yīng)用的生命周期管理。阿里云容器鏡像服務(wù)（ACR）是云原生時(shí)代的重要基礎(chǔ)設(shè)施之一，支撐阿里巴巴經(jīng)濟(jì)體容器鏡像托管，分鐘級(jí)分發(fā)萬(wàn)節(jié)點(diǎn)。自2015年起，先后服務(wù)了數(shù)千家企業(yè)，托管了數(shù) PB容器鏡像數(shù)據(jù)，支撐月均鏡像拉取數(shù)億次。

為了幫助云上客戶更好的做好容器安全建設(shè)，阿里云重點(diǎn)關(guān)注容器構(gòu)建、容器部署和容器運(yùn)行三大生命周期階段，結(jié)合容器ATT&CK矩陣，提供自動(dòng)化的容器安全檢測(cè)和響應(yīng)能力；同時(shí)聯(lián)合阿里云原生容器安全服務(wù)，共同面向客戶推出云上容器安全一體化方案，助力企業(yè)容器化進(jìn)程。

借助云安全中心，阿里云可以為客戶提供自動(dòng)化的安全編排與響應(yīng)能力，全面提升容器安全易用性；同時(shí)為容器鏡像提供漏洞掃描和修復(fù)，并支持整合在容器構(gòu)建流程中，避免部署存在風(fēng)險(xiǎn)的容器；對(duì)于運(yùn)行時(shí)的容器被植入 Webshell、挖礦病毒等場(chǎng)景，自動(dòng)化將隔離惡意樣本，并通過聯(lián)動(dòng)云防火墻，針對(duì)存在漏洞的容器，提供虛擬補(bǔ)丁的能力，緩解安全風(fēng)險(xiǎn)。

寫在最后

理解容器ATT&CK矩陣是構(gòu)建容器安全能力的第一步，除了上述涉及的能力和措施外，阿里云安全團(tuán)隊(duì)建議用戶在實(shí)施容器化過程中需要遵循以下幾點(diǎn)安全規(guī)范，從不同角度緩解容器化帶來的風(fēng)險(xiǎn)：

在應(yīng)用生命周期中關(guān)注您的鏡像，容器，主機(jī)，容器管理平臺(tái)以及相關(guān)云服務(wù)的安全性，了解潛在風(fēng)險(xiǎn)以及如何保護(hù)整體容器環(huán)境的運(yùn)行免受危害。

收集并妥善保管K8s集群、第三方CI組件以及云服務(wù)的API通信憑證，避免因人工誤操作導(dǎo)致的AK泄露。

由于容器應(yīng)用生態(tài)涉及到的中間件較多，系統(tǒng)管理者需要關(guān)注這些中間件的漏洞披露情況并及時(shí)做好脆弱性管理和補(bǔ)丁升級(jí)工作。

最后，針對(duì)上述容器ATT&CK矩陣，阿里云推出容器安全運(yùn)行檢測(cè)清單，企業(yè)可以根據(jù)下圖中所展示的內(nèi)容檢測(cè)自己的容器安全水位，以便及時(shí)發(fā)現(xiàn)問題及時(shí)修復(fù)。

內(nèi)容致謝：

陳吳棟（自樸） 阿里云高級(jí)產(chǎn)品經(jīng)理、魏俊欣（艾格） 阿里云高級(jí)安全專家、邱戈川（了哥） 阿里云高級(jí)技術(shù)專家、杜航（達(dá)丁） 阿里云容器解決方案架構(gòu)師

分享文章：云上容器ATT&CK矩陣詳解，阿里云助力企業(yè)容器化安全落地
網(wǎng)頁(yè)網(wǎng)址：http://www.rwnh.cn/article38/cpdhsp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站、ChatGPT、品牌網(wǎng)站制作、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)