Docker可以通過AppArmor或者SELinux進(jìn)行訪問控制，既然是訪問控制的過程中難免需要進(jìn)行對其的配置。此項目是通過AppArmor進(jìn)行防護(hù)的，在配置時遇到了許多問題，在此記錄。

1.如何調(diào)用AppArmor進(jìn)行Docker的權(quán)限控制

這一項在官方文檔中有記載。在啟動或者運行docker通過參數(shù)"--security-opt"加入訪問控制的配置文件。--security-opt的默認(rèn)參數(shù)為docker-default。docker-default并非一個實際的配置文件，而是由執(zhí)行時由GO語言運行的配置模板自動生成并寫入AppArmor緩存。(Docker versions 1.13.0 and later)

2.為Docker配置權(quán)限文件

由于是為docker的container進(jìn)行安全配置，我們將配置文件放置于/etc/containers/目錄下。為方便管理配置文件的命名與配置名同名。官方列舉了一個Nginx 的docker配置文件
#include <tunables/global>

profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  network inet tcp,
  network inet udp,
  network inet icmp,

  deny network raw,

  deny network packet,

  file,
  umount,

  deny /bin/** wl,
  deny /boot/** wl,
  deny /dev/** wl,
  deny /etc/** wl,
  deny /home/** wl,
  deny /lib/** wl,
  deny /lib64/** wl,
  deny /media/** wl,
  deny /mnt/** wl,
  deny /opt/** wl,
  deny /proc/** wl,
  deny /root/** wl,
  deny /sbin/** wl,
  deny /srv/** wl,
  deny /tmp/** wl,
  deny /sys/** wl,
  deny /usr/** wl,

  audit /** w,

  /var/run/nginx.pid w,

  /usr/sbin/nginx ix,

  deny /bin/dash mrwklx,
  deny /bin/sh mrwklx,
  deny /usr/bin/top mrwklx,


  capability chown,
  capability dac_override,
  capability setuid,
  capability setgid,
  capability net_bind_service,

  deny @{PROC}/* w,   # deny write for all files directly in /proc (not in a subdir)
  # deny write to files not in /proc/<number>/** or /proc/sys/**
  deny @{PROC}/{[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9]*}/** w,
  deny @{PROC}/sys/[^k]** w,  # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel)
  deny @{PROC}/sys/kernel/{?,??,[^s][^h][^m]**} w,  # deny everything except shm* in /proc/sys/kernel/
  deny @{PROC}/sysrq-trigger rwklx,
  deny @{PROC}/mem rwklx,
  deny @{PROC}/kmem rwklx,
  deny @{PROC}/kcore rwklx,

  deny mount,

  deny /sys/[^f]*/** wklx,
  deny /sys/f[^s]*/** wklx,
  deny /sys/fs/[^c]*/** wklx,
  deny /sys/fs/c[^g]*/** wklx,
  deny /sys/fs/cg[^r]*/** wklx,
  deny /sys/firmware/** rwklx,
  deny /sys/kernel/security/** rwklx,
}

其中配置標(biāo)簽需要以profile <name>的方式進(jìn)行，以便通過--security-opt參數(shù)的形式被調(diào)用。flags=(attach_disconnected)似乎是必要的。
attach_disconnected，設(shè)定配置文件的名稱解析為相對路徑，不設(shè)置無法找到對應(yīng)的配置。
mediate_deleted，中介刪除？

為Docker內(nèi)應(yīng)用配置權(quán)限文件

上述方式可以對Docker內(nèi)文件的使用權(quán)限進(jìn)行配置。但是，在對Docker內(nèi)某一應(yīng)用進(jìn)行配置時卻是區(qū)別于原本AppArmor對主機(jī)應(yīng)用的配置。其權(quán)限配置主要是通過子配置實現(xiàn)的。
比如對/usr/bin/python3.5限制不允許訪問/etc文件夾下的內(nèi)容。
#include <tunables/global>
profile docker-profile flags=(attach_disconnected,mediate_deleted) {
#include <abstractions/base>
network,
capability,
file,
umount,
...
/usr/bin/python3.5 cx -> python_profile,
profile python_profile flags=(mediate_deleted,attach_disconnected) {
file,
deny /etc/** rwklx,
deny /etc/ rwklx,
network inet tcp,
}
...
}
AppArmor對于Docker內(nèi)應(yīng)用的限制似乎只能通過黑名單的形式，即使用允許file權(quán)限即允許所有docker內(nèi)文件的權(quán)限。之后只能通過deny逐一禁止。