淺談Docker安全性支援
【編者的話】Docker作為最重視安全的容器技術之一，在很多方面都提供了強安全性的預設配置，其中包括：容器root使用者的Capability能力限制、Seccomp系統呼叫過濾、Apparmor的 MAC 訪問控制、ulimit限制、pid-limits的支援，映象簽名機制等。這篇文章我們就帶大家詳細瞭解一下。
Docker利用Namespace實現了6項隔離，看似完整，實際上依舊沒有完全隔離Linux資源，比如/proc 、/sys 、/dev/sd*等目錄未完全隔離，SELinux、time、syslog等所有現有Namespace之外的資訊都未隔離。 其實Docker在安全性上也做了很多工作，大致包括下面幾個方面：
1、Linux核心 Capability 能力限制
Docker支援為容器設定Capabilities，指定開放給容器的許可權。這樣在容器中的root使用者比實際的root少很多許可權。Docker 在0.6版本以後支援將容器開啟超級許可權，使容器具有宿主機的root許可權。
2、映象簽名機制
Docker 1.8版本以後提供了映象簽名機制來驗證映象的來源和完整性，這個功能需要手動開啟，這樣映象製作者可以在push映象前對映象進行簽名，在映象pull的時候，Docker不會pull驗證失敗或者沒有簽名的映象標籤。
3、Apparmor的MAC訪問控制
Apparmor可以將程序的許可權與程序Capabilities能力聯絡在一起，實現對程序的強制性訪問控制（MAC）。在Docker中，我們可以使用Apparmor來限制使用者只能執行某些特定命令、限制容器網路、檔案讀寫許可權等功能。
4、Seccomp系統呼叫過濾
使用Seccomp可以限制程序能夠呼叫的系統呼叫（system call）的範圍，Docker提供的預設Seccomp配置檔案已經禁用了大約44個超過300+的系統呼叫，滿足大多數容器的系統呼叫訴求。
5、User Namespace隔離
Namespace為執行中程序提供了隔離，限制他們對系統資源的訪問，而程序沒有意識到這些限制，為防止容器內的特權升級攻擊的最佳方法是將容器的應用程式配置為作為非特權使用者執行，對於其程序必須作為容器中的root使用者執行的容器，可以將此使用者重新對映到Docker主機上許可權較低的使用者。對映的使用者被分配了一系列UID，這些UID在名稱空間內作為從0到65536的普通UID執行，但在主機上沒有特權。
6、SELinux
SELinux主要提供了強制訪問控制（MAC），即不再是僅依據程序的所有者與檔案資源的rwx許可權來決定有無訪問能力。能在攻擊者實施了容器突破攻擊後增加一層壁壘。Docker提供了對SELinux的支援。
7、pid-limits的支援
在說pid-limits前，需要說一下什麼是fork炸彈（fork bomb），fork炸彈就是以極快的速度建立大量程序，並以此消耗系統分配予程序的可用空間使程序表飽和，從而使系統無法執行新程式。說起程序數限制，大家可能都知道ulimit的nproc這個配置，nproc是存在坑的，與其他ulimit選項不同的是，nproc是一個以使用者為管理單位的設定選項，即他調節的是屬於一個使用者UID的最大程序數之和。這部分內容下一篇會介紹。Docker從1.10以後，支援為容器指定--pids-limit 限制容器內程序數，使用其可以限制容器內程序數。
8、其他核心安全特性工具支援
在容器生態的周圍，還有很多工具可以為容器安全性提供支援，比如可以使用Docker bench audit tool（工具地址： ofollow,noindex" target="_blank">https://github.com/docker/docker-bench-security ）檢查你的Docker執行環境，使用Sysdig Falco（工具地址： https://sysdig.com/opensource/falco/ ）來檢測容器內是否有異常活動，可以使用GRSEC 和 PAX來加固系統核心等等。
Linux核心Capability能力限制
Capabilities簡單來說，就是指開放給程序的許可權，比如允許程序可以訪問網路、讀取檔案等。Docker容器本質上就是一個程序，預設情況下，Docker會刪除必須的Capabilities外的所有Capabilities，可以在Linux手冊頁 中看到完整的可用Capabilities列表。Docker 0.6版本以後支援在啟動引數中增加--privileged選項為容器開啟超級許可權。
Docker支援Capabilities對於容器安全意義重大，因為在容器中我們經常會以root使用者來執行，使用Capability限制後，容器中的root比真正的root使用者許可權少得多。這就意味著，即使入侵者設法在容器內獲取了root許可權，也難以做到嚴重破壞或獲得主機root許可權。
當我們在docker run時指定了--privileded選項，Docker其實會完成兩件事情：
- 獲取系統root使用者所有能力賦值給容器；
- 掃描宿主機所有裝置檔案掛載到容器內。
下面我們給大家實際演示一下：
當執行docker run 時未指定--privileded選項
lynzabo@ubuntu:~$ docker run --rm --name def-cap-con1 -d alpine /bin/sh -c "while true;do echo hello; sleep 1;done" f216f9261bb9c3c1f226c341788b97c786fa26657e18d7e52bee3c7f2eef755c lynzabo@ubuntu:~$ docker inspect def-cap-con1 -f '{{.State.Pid}}' 43482 lynzabo@ubuntu:~$ cat /proc/43482/status | grep Cap CapInh:00000000a80425fb CapPrm:00000000a80425fb CapEff:00000000a80425fb CapBnd:00000000a80425fb CapAmb:0000000000000000 lynzabo@ubuntu:~$ lynzabo@ubuntu:~$ docker exec def-cap-con1 ls /dev corefdfullmqueuenullptmxptsrandomshmstderrstdinstdoutttyurandomzero...總共15條 lynzabo@ubuntu:~$
如果指定了--privileded選項
lynzabo@ubuntu:~$ docker run --privileged --rm --name pri-cap-con1 -d alpine /bin/sh -c "while true;do echo hello; sleep 1;done" ad6bcff477fd455e73b725afe914b82c8aa6040f36326106a9a3539ad0be03d2 lynzabo@ubuntu:~$ docker inspect pri-cap-con1 -f '{{.State.Pid}}' 44312 lynzabo@ubuntu:~$ cat /proc/44312/status | grep Cap CapInh:0000003fffffffff CapPrm:0000003fffffffff CapEff:0000003fffffffff CapBnd:0000003fffffffff CapAmb:0000000000000000 lynzabo@ubuntu:~$ docker exec pri-cap-con1 ls /dev agpgartautofsbsgbtrfs-controlbuscorecpu_dma_latencycusedmmididriecryptfs ...總共186條 lynzabo@ubuntu:~$
對比/proc/$pid/status ，可以看到兩個容器程序之間能力點陣圖的差別，加上--privileged的能力點陣圖與超級使用者的能力點陣圖一樣。再對比增加--privileged後目錄/dev下檔案變化，可以看到，加了特權後，宿主機所有裝置檔案都掛載在容器內。
我們可以看到，使用--privileged引數授權給容器的許可權太多，所以需要謹慎使用。如果需要掛載某個特定的裝置，可以通過--device方式，只掛載需要使用的裝置到容器中，而不是把宿主機的全部裝置掛載到容器上。例如，為容器內掛載宿主機音效卡：
$ docker run --device=/dev/snd:/dev/snd …
此外，可以通過--add-cap和--drop-cap這兩個引數來對容器的能力進行調整，以最大限度地保證容器使用的安全。
例如，給容器增加一個修改系統時間的命令：
$ docker run --cap-drop ALL --cap-add SYS_TIME ntpd /bin/sh
檢視容器PID，執行getpcaps PID檢視程序的能力，執行結果如下：
[root@VM_0_6_centos ~]# getpcaps 652 Capabilities for `652': = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_sys_time,... [root@VM_0_6_centos ~]#
可以看到容器中已經增加了sys_time能力，可以修改系統時間了。
Docker映象簽名機制
當我們執行docker pull映象的時候，映象倉庫再驗證完使用者身份後，會先返回一個manifest.json檔案，其中包含了映象名稱、tag、所有layer層SHA256值，還有映象的簽名信息，然後docker daemon會並行的下載這些layer層檔案。Docker 1.8以後，提供了一個數字簽名機制——content trust來驗證官方倉庫映象的來源和完整性,簡單來說就是映象製作者製作映象時可以選擇對映象標籤（tag）進行簽名或者不簽名，當pull映象時，就可以通過這個簽名進行校驗，如果一致則認為資料來源可靠，並下載映象。
預設情況下，這個content trust是被關閉了的，你需要設定一個環境變數來開啟這個機制，即：
$ export DOCKER_CONTENT_TRUST=11
當content trust機制被開啟後，Docker不會pull驗證失敗或者沒有簽名的映象標籤。當然也可以通過在pull時加上--disable-content-trust來暫時取消這個限制。
Apparmor的MAC訪問控制
AppArmor和SELinux都是Linux安全模組，可以將程序的許可權與程序capabilities能力聯絡在了一起，實現對程序的強制性訪問控制（MAC）。由於SELinux有點複雜，經常都被人直接關閉，而AppArmor就相對要簡單點。Docker官方也推薦這種方式。
Docker自動為容器生成並載入名為docker-default的預設配置檔案。在 Docker 1.13.0和更高版本中，Docker二進位制檔案在tmpfs中生成該配置檔案，然後將其載入到核心中。在早於1.13.0的Docker版本上，此配置檔案將在/etc/apparmor.d/docker中生成。docker-default配置檔案是執行容器的預設配置檔案。它具有適度的保護性，同時提供廣泛的應用相容性。
注意：這個配置檔案用於容器而不是Docker守護程序。執行容器時會使用docker-default策略，除非通過security-opt選項覆蓋。
下面我們使用Nginx做演示，提供一個自定義AppArmor配置檔案：
1、建立自定義配置檔案，假設檔案路徑為 /etc/apparmor.d/containers/docker-nginx 。
#include <tunables/global> profile docker-nginx flags=(attach_disconnected,mediate_deleted) { #include <abstractions/base> ... deny network raw, ... deny /bin/** wl, deny /root/** wl, deny /bin/sh mrwklx, deny /bin/dash mrwklx, deny /usr/bin/top mrwklx, ... }
2、載入配置檔案
$ sudo apparmor_parser -r -W /etc/apparmor.d/containers/docker-nginx
3、使用這個配置檔案執行容器
$ docker run --security-opt "apparmor=docker-nginx" -p 80:80 -d --name apparmor-nginx nginx12
4、進入執行中的容器中，嘗試一些操作來測試配置是否生效：
$ docker container exec -it apparmor-nginx bash1 root@6da5a2a930b9:~# ping 8.8.8.8 ping: Lacking privilege for raw socket. root@6da5a2a930b9:/# top bash: /usr/bin/top: Permission denied root@6da5a2a930b9:~# touch ~/thing touch: cannot touch 'thing': Permission denied root@6da5a2a930b9:/# sh bash: /bin/sh: Permission denied
可以看到，我們通過AppArmor配置檔案可以對容器進行保護。
Seccomp系統呼叫過濾
Seccomp是Linux kernel從2.6.23版本開始所支援的一種安全機制，可用於限制程序能夠呼叫的系統呼叫（system call）的範圍。在Linux系統裡，大量的系統呼叫（systemcall）直接暴露給使用者態程式，但是，並不是所有的系統呼叫都被需要，而且不安全的程式碼濫用系統呼叫會對系統造成安全威脅。通過Seccomp，我們限制程式使用某些系統呼叫，這樣可以減少系統的暴露面，同時使程式進入一種“安全”的狀態。每個程序進行系統呼叫（system call）時，kernel都會檢查對應的白名單以確認該程序是否有許可權使用這個系統呼叫。從Docker 1.10版本開始，Docker安全特性中增加了對Seccomp的支援。
使用Seccomp的前提是Docker構建時已包含了Seccomp，並且核心中的CONFIG_SECCOMP已開啟。可使用如下方法檢查核心是否支援Seccomp：
$ cat /boot/config-`uname -r` | grep CONFIG_SECCOMP= CONFIG_SECCOMP=y
預設的Seccomp配置檔案為使用Seccomp執行容器提供了一個合理的設定，並禁用了大約44個超過300+的系統呼叫。它具有適度的保護性，同時提供廣泛的應用相容性。預設的Docker配置檔案可以在moby原始碼profiles/seccomp/下找到。
預設seccomp profile片段如下：
{ "defaultAction": "SCMP_ACT_ERRNO", "archMap": [ { "architecture": "SCMP_ARCH_X86_64", "subArchitectures": [ "SCMP_ARCH_X86", "SCMP_ARCH_X32" ] },= ... ], "syscalls": [ { "names": [ "reboot" ], "action": "SCMP_ACT_ALLOW", "args": [], "comment": "", "includes": { "caps": [ "CAP_SYS_BOOT" ] }, "excludes": {} }, ... ] }
seccomp profile包含3個部分：預設操作，系統呼叫所支援的Linux架構和系統呼叫具體規則（syscalls）。對於每個呼叫規則，其中name是系統呼叫的名稱，action是發生系統呼叫時Seccomp的操作，args是系統呼叫的引數限制條件。比如上面的“SCMP_ACT_ALLOW”action代表這個程序這個系統呼叫被允許，這個call，允許程序可以重啟系統。
實際上，該配置檔案是白名單，預設情況下阻止訪問所有的系統呼叫，然後將特定的系統呼叫列入白名單。
Seccomp有助於以最小許可權執行Docker容器。不建議更改預設的Seccomp配置檔案。
執行容器時，如果沒有通過--security-opt選項覆蓋容器，則會使用預設配置。例如，以下顯式指定了一個策略：
$ docker run --rm \ -it \ --security-opt seccomp=/path/to/seccomp/profile.json \ hello-seccomp
Docker的預設Seccomp配置檔案是一個白名單，它指定了允許的呼叫。Docker文件列舉了所有不在白名單而被有效阻止的重要（但不是全部）系統呼叫以及每個系統呼叫被阻止的原因。
User Namespace隔離
Linux名稱空間為執行中的程序提供了隔離，限制他們對系統資源的訪問，而程序沒有意識到這些限制。為防止容器內的特權升級攻擊的最佳方法是將容器的應用程式配置為非特權使用者執行，對於其程序必須作為容器中的root使用者執行的容器，可以將此使用者重新對映到Docker主機上許可權較低的使用者。對映的使用者被分配了一系列UID，這些UID在名稱空間內作為從0到65536的普通UID執行，但在主機上沒有特權。
重新對映由兩個檔案處理：/etc/subuid 和 /etc/subgid，其中前者關注使用者ID範圍，後者關注使用者組ID範圍。
例如，如下/etc/subuid中的條目：
testuser:231072:65536
這意味著testuser將從231072開始，在後面的65536個整數中按順序為使用者分配一個ID。例如，名稱空間中的UID 231072對映到容器中的UID 0（root），UID 231073對映為UID 1，依此類推。如果某個程序嘗試提升特權到名稱空間外部，則該程序將作為主機上無特權的高數字UID執行，該UID甚至不對映到真實使用者，這意味著該程序完全沒有主機系統的許可權。
在Docker 1.10以後，可以通過在Dockerd啟動引數中指定userns-remap來啟用這個功能。
下面我們做一下演示：
1、檢視Docker Daemon是否以root使用者身份執行
lynzabo@ubuntu:~$ ps -ef | grep dockerd root 1557 1 0 12:54 ? 00:05:08 /usr/bin/dockerd -H fd:// lynzabo 36398 23696 0 21:41 pts/1 00:00:00 grep --color=auto dockerd lynzabo@ubuntu:~$
2、執行容器，指定ID命令
lynzabo@ubuntu:~$ docker run --rm alpine id Unable to find image 'alpine:latest' locally latest: Pulling from library/alpine 4fe2ade4980c: Pull complete Digest: sha256:621c2f39f8133acb8e64023a94dbdf0d5ca81896102b9e57c0dc184cadaf5528 Status: Downloaded newer image for alpine:latest uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon)... lynzabo@ubuntu:~$
上面輸出的最後一行顯示容器以root身份執行：uid = 0（root）和gid = 0（root）。
3、執行docker run指定引數--user ，指定容器以當前使用者身份來執行
lynzabo@ubuntu:~$ id uid=1000(lynzabo) gid=1000(lynzabo) groups=1000(lynzabo)... lynzabo@ubuntu:~$ docker run --rm --user 1000:1000 alpine id uid=1000 gid=1000 lynzabo@ubuntu:~$
可以看到容器使用的我們設定的使用者和組來執行。
有時候，我們更希望容器裡面是以root使用者來執行，但是並不需要具有宿主機上root許可權，可以使用User Namespace做到這些。使用User Namespace，容器中的root使用者會被重新對映到宿主機上一個非特權使用者，這意味著該程序完全沒有主機系統的許可權。
下面我們帶大家一起演示一下：
1、停止Docker Daemon
lynzabo@ubuntu:~$ sudo systemctl stop docker lynzabo@ubuntu:~$
2、指定在User Namespace模式下執行Docker Daemon
lynzabo@ubuntu:~$ sudo dockerd --userns-remap=default & lynzabo@ubuntu:~$
當你將Docker配置為使用userns-remap功能時，可以指定為現有使用者或組，也可以指定為default。如果指定為default，則會為此建立並使用使用者和組dockremap 。也可以在daemon.json配置檔案中指定。
通過ID命令驗證Docker已經建立了這個使用者。
lynzabo@ubuntu:~$ id dockremap uid=123(dockremap) gid=132(dockremap) groups=132(dockremap) lynzabo@ubuntu:~$
驗證條目已經新增到了/etc/subuid和/etc/subgid檔案中。
lynzabo@ubuntu:~$ grep dockremap /etc/subuid dockremap:165536:65536 lynzabo@ubuntu:~$ grep dockremap /etc/subgid dockremap:165536:65536 lynzabo@ubuntu:~$
如果這些條目不存在，需要以root使用者身份編輯檔案，並且分配起始的UID和GID（在最高的已經分配的值的基礎上加上偏移，65536）。注意不要使範圍重疊。
3、使用docker info命令驗證Docker是否正確啟用了使用者名稱空間支援
lynzabo@ubuntu:~$ docker info ... Docker Root Dir: /home/docker/165536.165536 ... lynzabo@ubuntu:~$ lynzabo@ubuntu:~$ ls -ld /home/docker/165536.165536 drwx------ 14 165536 165536 4096 Sep 17 21:44 /home/docker/165536.165536 lynzabo@ubuntu:~$ sudo ls -l /home/docker/165536.165536/ total 48 drwx------ 2 165536 165536 4096 Sep 17 21:44 volumes drwx--x--x 3 root root 4096 Sep 17 21:44 containerd drwx------ 2 165536 165536 4096 Sep 17 21:44 containers drwx------ 3 root root 4096 Sep 17 21:44 image drwxr-x--- 3 root root 4096 Sep 17 21:44 network drwx------ 4 165536 165536 4096 Sep 17 21:44 overlay2 ... lynzabo@ubuntu:~$
可以看到Docker工作目錄在原有/var/lib/docker/ 目錄下多了一層以“使用者UID.GID”命名的目錄。檢視該目錄下各個子目錄許可權，有些子目錄仍有root擁有，有些子目錄已經繼承了上級目錄許可權。
4、檢視本地映象
lynzabo@ubuntu:~$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE lynzabo@ubuntu:~$
可以看到本地沒有任何映象，很奇怪，我們在上面使用的alpine映象消失了。
5、下面我們以互動模式執行一個容器，將宿主機的/bin目錄掛載到容器中
lynzabo@ubuntu:~$ docker run -it --rm -v /bin:/host/bin busybox /bin/sh Unable to find image 'busybox:latest' locally latest: Pulling from library/busybox 8c5a7da1afbc: Pull complete Digest: sha256:cb63aa0641a885f54de20f61d152187419e8f6b159ed11a251a09d115fdff9bd Status: Downloaded newer image for busybox:latest / # id uid=0(root) gid=0(root) groups=10(wheel) / #
上面的輸出顯示容器內部是以root使用者的安全上下文下執行。
6、下面我們嘗試執行命令
/ # rm /host/bin/sh rm: can't remove 'sh': Permission denied
操作失敗並顯示許可權被拒絕，這是因為要刪除的檔案存在於Docker宿主機的本地檔案系統中，並且容器在其所在的名稱空間之外沒有root訪問許可權。如果未啟用User Namespace，執行相同的操作，操作將成功。
SELinux支援
我們知道系統的使用者主要分為系統管理員與一般使用者，而這兩種身份能否使用系統檔案資源與rwx的許可權設定有關，這種存取檔案系統的方式被稱為“自主式存取控制（DAC）”。不過你要注意的是，各種許可權設定對 root 是無效的，這個時候就可以使用委任式存取控制（MAC）了，使用MAC可以針對特定的程式與特定的檔案資源來進行許可權的控管，也就是說，即使是root使用者，那麼在使用不同的程式時，你所能取得的許可權並不一定是root，而要根據當時程式的設定而定。
SELinux 就是通過 MAC 的方式來控管程式，他控制的主體是程式， 而目標則是該程式能否讀寫的“檔案資源”。下面是使用SeLinux基本流程：
由上圖我們可以發現：
(1) 主體程式必須要通過 SELinux 政策內的規則放行後，就可以與目標資源進行安全性本文的比對。
(2) 比對安全性本文，比對成功就可以訪問目標，比對失敗，記錄拒絕資訊。
SELinux的工作模式一共有三種Enforcing、Permissive和Disabled：
- Enforcing模式：將受限主體進入規則比對、安全本文比對，如果失敗，抵擋主體程式的讀寫行為，並且記錄這一行為。 如果成功，這才進入到rwx許可權的判斷。
- Permissive模式：不會抵擋主體程式讀寫行為，只是將該動作記錄下來。
- Disabled的模式：禁用SELinux，直接去判斷rwx。
Docker守護程序的SELinux功能預設是禁用的，需要使用--selinux-enabled來啟用，容器的標籤限制可使用-security-opt載入SELinux或者AppArmor的策略進行配置。
下面演示使用SELinux：
1、我們在宿主機上開啟 SELinux，嘗試啟動一個 Nginx 容器並將 nginx.conf 掛載到容器內。
# 檢視系統Selinux是否開啟，及當前模式，policy [lynzabo@localhost ~]$ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 28 [lynzabo@localhost ~]$
Docker開啟Selinux
[root@localhost conf]# ps -ef|grep dockerd
root 4401 1 0 08:15 ? 00:00:00 /usr/bin/dockerd --selinux-enabled
root 4549 3117 0 08:15 pts/0 00:00:00 grep --color=auto dockerd
[root@localhost conf]#
執行一個容器，將本地nginx.conf檔案掛載到容器中
[root@localhost conf]# docker run --name test-selinux-nginx -v /root/nginx/conf/nginx.conf:/etc/nginx/nginx.conf -d nginx
bbef34e4caa4e8c3a19f9eae5859691e3504731568e7e585108e26aade95be76
[root@localhost conf]#
使用docker ps檢視容器狀態，容器已經退出，退出日誌為“Permission denied”
[root@localhost conf]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES bbef34e4caa4 nginx "nginx -g 'daemon of…" 15 seconds ago Exited (1) 13 seconds ago test-selinux-nginx [root@localhost conf]# docker logs -f bbef34e4caa4 2018/09/17 15:16:02 [emerg] 1#1: open() "/etc/nginx/nginx.conf" failed (13: Permission denied) nginx: [emerg] open() "/etc/nginx/nginx.conf" failed (13: Permission denied) [root@localhost conf]#
可以看到錯誤資訊好像是許可權被拒絕，那麼我們檢查一下nginx.conf 的許可權是否符合我們的要求。
使用 ls -Z 檢視 nginx.conf的 DAC 與 MAC 許可權資訊。
[root@localhost conf]# ls -Z -rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 nginx.conf [root@localhost conf]#
檔案的許可權為644。我們在上面檢視Docker程序，Docker程序的許可權為root，對於644的許可權檔案是可讀可寫的。 看來，問題應該是出在MAC許可權上。
分析ls -Z的結果，nginx.conf對應的安全性文字的型別為admin_home_t:s0，在啟用SELinux後，我們的主體是無法操作這種型別的object的，所以無論Docker容器的許可權是否是root，Docker容器程序都沒有許可權讀取宿主上的nginx.conf。
Docker官方提供了一種解決方案專門用來解決與SELinux相關的許可權問題，在將SELinux上的檔案掛載到容器中時，在掛載的路徑最後加上:z。如：
docker run -v /var/db:/var/db:z rhel7 /bin/sh
Docker會自動將被掛載的宿主目錄的安全性文字配置為目標可讀。
[root@localhost conf]# docker run --name test-selinux-z-nginx -v /root/nginx/conf/nginx.conf:/etc/nginx/nginx.conf:z -d nginx db49bbe352ff1ab800274a17fd18f9c7d86c281e60ac3ffa36ba14e12949285d [root@localhost conf]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES db49bbe352ff nginx "nginx -g 'daemon of…" 5 seconds ago Up 2 seconds 80/tcp test-selinux-z-nginx [root@localhost conf]#
這個時候看到Nginx正常啟動了，說明SELinux稽核通過了。
pid-limits的支援
Linux核心會限制所有程序可以開啟的檔案總數，同時為了防止某個程序消耗過多檔案資源，也會對單個程序設定限制，這個時候ulimit就派上了用場，使用ulimit命令可以限制程序最多開啟檔案控制代碼數、最多開啟程序數、執行緒棧大小等等。Docker對ulimit也提供了支援，Docker 1.6之前，Docker容器的ulimit設定，繼承自Docker daemon，Docker 1.6之後，既可以設定全域性預設的ulimit，也可以對單個容器指定ulimit。
如下，指定容器最多可開啟檔案控制代碼數為2048，最多開啟100個程序。
[lynzabo@VM_0_6_centos ~]$ docker run -it --ulimit nofile=2048 --ulimit nproc=100 busybox sh / # ulimit -a -f: file size (blocks) unlimited -t: cpu time (seconds) unlimited -d: data seg size (kb) unlimited -s: stack size (kb) 8192 -c: core file size (blocks) unlimited -m: resident set size (kb) unlimited -l: locked memory (kb) 64 -p: processes 100 -n: file descriptors 2048 -v: address space (kb) unlimited -w: locks unlimited -e: scheduling priority 0 -r: real-time priority 0 / #
容器程序數限制坑介紹
說起程序數限制，大家可能都知道ulimit的nproc這個配置，nproc是存在坑的，與其他ulimit選項不同的是，nproc是一個以使用者為管理單位的設定選項，即他調節的是屬於一個使用者UID的最大程序數之和。如下面輸出：
# 我們使用daemon使用者啟動4個容器，並設定允許的最大程序數為3 $ docker run -d -u daemon --ulimit nproc=3 busybox top $ docker run -d -u daemon --ulimit nproc=3 busybox top $ docker run -d -u daemon --ulimit nproc=3 busybox top # 這個容器會失敗並報錯，資源不足 $ docker run -d -u daemon --ulimit nproc=3 busybox top
我們指定使用daemon使用者來在容器中啟動top程序，結果啟動到第4個容器的時候就報錯了。而實際上，我們本來是想限制每個容器裡使用者最多隻能建立3個程序。另外，預設情況下，Docker在容器中啟動程序是以root使用者身份啟動的，而ulimit的nproc引數是無法對root使用者進行限制。
Docker從1.10以後，支援為容器指定--pids-limit 限制容器內程序數，和容器裡使用者無關。如下面例子：
[lynzabo@VM_0_6_centos ~]$ docker run -d --name test-pids-limit --pids-limit=5 busybox top 5693c8c31284b0f3cb4eb10d4f67e13ad98d1972a27dab094f0ad96154a5ce6a [lynzabo@VM_0_6_centos ~]$ docker exec -ti test-pids-limit sh / # ps -ef PID USER TIME COMMAND 1 root 0:00 top 5 root 0:00 sh 9 root 0:00 ps -ef / # nohup top & / # nohup: appending output to nohup.out / # nohup top & / # nohup: appending output to nohup.out / # nohup top & / # nohup: appending output to nohup.out / # nohup top & sh: can't fork: Resource temporarily unavailable / #
容器啟動引數中，我們通過--pids-limit設定容器裡最多隻能執行5個程序，可以看到，當程序數達到5個後，在啟動程序時就提示can't fork: Resource temporarily unavailable。
其他核心安全特性工具支援
在容器生態的周圍，還有很多工具可以為容器安全性提供支援。
- 可以使用docker-bench-security檢查你的Docker執行環境，如Docker daemon配置，宿主機配置
- 使用Sysdig Falco（地址： https://sysdig.com/opensource/falco/ ）可以監視容器的行為，檢測容器中是否有異常活動。
- 使用GRSEC 和 PAX來加固系統核心，還可以使用GRSecurity為系統提供更豐富的安全限制。等等。
原文連結： https://mp.weixin.qq.com/s/-fzrhcbbrAl0OYvQIaQmEA ， https://mp.weixin.qq.com/s/nXtpvV0byDHyLpXD8aFWcg