Как мы все знаем, в облачной среде мы можем контролировать доступ приложения к ресурсам в кластере с помощью механизма RBAC, но для производственной среды этого недостаточно, когда приложение может получить доступ к ресурсам хоста (например, к ресурсам хоста). возможности Linux), доступ к сети, права доступа к файлам), хост по-прежнему подвергается риску безопасности. В этой ситуации модуль безопасности ядра Linux AppArmor дополняет стандартные разрешения пользователей и групп Linux, ограничивая программы ограниченным набором ресурсов, а также защищая модуль от нежелательных атак.

включен AppArmor В изсистеме контейнер будет использовать конфигурацию по умолчанию при запуске контейнера. Конечно, приложение также может использовать пользовательскую конфигурацию. Эта статья расскажет о том, как Использование AppArmor в контейнерах。

Как использовать AppArmor

AppArmor — это модуль безопасности ядра Linux, который позволяет системным администраторам ограничивать функциональность программы с помощью файлов конфигурации для каждой программы. Файлы конфигурации могут предоставлять такие функции, как доступ к сети, доступ к необработанным сокетам и разрешения на чтение, запись или выполнение файлов по совпадающим путям.

Однако не все системы поддерживают AppArmor. Некоторые дистрибутивы поддерживают этот модуль по умолчанию, например Ubuntu и SUSE, а многие предоставляют дополнительную поддержку. Вы можете проверить, включен ли в модуле AppArmor, с помощью следующей команды:

$ cat /sys/module/apparmor/parameters/enabled
Y

AppArmor работает в двух типах режимов профиля:

• enforce: В режиме принудительного исполнения система начинает применять правила и syslog или auditd отчеты о попытках нарушения (только если установлено auditd время) и операция не разрешена.
• complain: В режиме жалоб система не применяет никаких правил. Он будет регистрировать только попытки взлома.

Конфигурационный файл находится по адресу /etc/apparmor.d/ Текстовые файлы в каталоге. Эти файлы называются по полному пути к исполняемому файлу, который они анализируют, но / Заменить на .。Например,tcpdump Команда находится по адресу /usr/sbin/tcpdump,Эквивалент AppArmor Конфигурационный файл будет называться usr.sbin.tcpdump。

Вы также можете создать свой собственный файл конфигурации, например sample profile Установите ограничение прав на запись для всех файлов:

$ cat <<EOF >/etc/apparmor.d/containers/sample
#include <tunables/global>

profile sample flags=(attach_disconnected) {
  #include <abstractions/base>
  file,
  # Deny all file writes.
  deny /** w,
}
EOF

Примените приведенную выше конфигурацию:

$ apparmor_parser /etc/apparmor.d/containers/sample
$ apparmor_status
apparmor module is loaded.
35 profiles are loaded.
35 profiles are in enforce mode.
   ...
   sample
   ...

AppArmor в основном поддерживает три правила: Возможности, Файл и Сеть:

• Capability：Linux Процесс из Возможность здесь не будет предоставлена. Возможность действует только на набор возможностей процесса. mask。например,capability sys_admin, Указывает разрешение на выполнение задач управления системой.
• File：
  • Чтение и запись файлов исполнения и т. д. Разрешения. нравиться /home/** rw, выражает право /home Файл, находящийся в наличии, имеет возможность чтения и записи Разрешения;
  • Файловая системаиз правил монтирования,В том числе есть ли у него возможность монтировать и удалять Разрешения,документсистематип、Параметры монтирования и путь монтирования。нравиться mount options=ro /dev/foo, Указывает, что подключение только для чтения к /dev/foo путь;
  • chmod、chown、setuid и т. д. правила.
• Network：
  • верносеть socket из Разрешения, в том числе create、accept、bind и т. д., а также тип, адрес и т. д., например network tcp, Демонстрируйте поддержку во всем tcp Тип операции иссеть;
  • DBUS、IPC、Signals и т. д. правила.

Определение файла конфигурации AppArmor очень гибкое. Для более подробной информации обратитесь к документации AppArmor.

Использование AppArmor в контейнерах

После настройки файла конфигурации AppArmor на хосте давайте посмотрим, как использовать его в контейнере.

Движок — Docker.

когдаконтейнер Движок — Docker. Когда для сравнения сначала запустим нормальный nginx контейнер и создайте test документ:

$ docker run --rm -it nginx /bin/bash
root@45bf95280766:/# cd
root@45bf95280766:~# touch test
root@45bf95280766:~# ls
test

Далее запустите AppArmor Конфигурационный файл sample изконтейнер и создайте test документ:

$ docker run --rm -it --security-opt "apparmor=sample" nginx /bin/bash
root@1d1d8f6b1aa0:/# cd ~
root@1d1d8f6b1aa0:~# touch test
touch: cannot touch 'test': Permission denied

мы можем видеть AppArmor Конфигурационный файл阻止了创建документ操作。

Движок контейнерный.

когдаконтейнер Движок контейнерный. , проделайте тот же тест:

$ nerdctl run --rm -it docker.io/library/nginx:latest /bin/bash
root@09e6c02616a7:/# cd ~
root@09e6c02616a7:~# touch test
root@09e6c02616a7:~#
root@09e6c02616a7:~# ls
test

Использование в контейнере sample Конфигурациядокумент:

$ nerdctl run --rm -it --security-opt "apparmor=sample" docker.io/library/nginx:latest /bin/bash
root@8be22275bc9d:/# cd
root@8be22275bc9d:~# touch test
touch: cannot touch 'test': Permission denied

Операции создания файлов также блокируются Аналогично, AppArmor Конфигурационный файл.

Использование AppArmor в Kubernetes

как Kubernetes А как насчет его использования? Путь в Pod из annotation Какой контейнер использует какую Конфигурацию в операторе файл,Что key для container.apparmor.security.beta.kubernetes.io/<container_name>,value иметь 3 разные значения:

• время выполнения/по умолчанию: использовать конфигурацию среды выполнения контейнера по умолчанию (например, docker-default ）；
• localhost/<profile_name>：Это вступает в силу на узле, используяиз Конфигурационный файл,<profile_name> для имени файла;
• неограниченный: не используйте никаких AppArmor Конфигурационный файл。

Создан с помощью приведенной выше конфигурации. файл sample дляпример：

apiVersion: v1
kind: Pod
metadata:
  name: test
  annotations:
    container.apparmor.security.beta.kubernetes.io/app: localhost/sample
spec:
  containers:
  - args:
    - -c
    - sleep 1000000
    command:
    - /bin/sh
    image: ubuntu
    name: app

Тот же тест pod будь то виметь创建документиз Разрешения：

$ kubectl exec -it test -- bash
root@test:/# cd
root@test:~# touch test
touch: cannot touch 'test': Permission denied

Подвести итог

включен AppArmor В изсистеме используйте AppArmor Для узлов и Pod защита очень нужна, но AppArmor Из Конфигурация также более сложна. Однако в сообществе уже есть более зрелые решения, например, для быстрой генерации AppArmor Конфигурационный файл, вы можете использовать инструменты проклятие. Для каждого узла Конфигурация также из Конфигурационная файл, можно использовать DaemonSet Для реализации обратитесь к кейсу также можно использовать скрипты инициализации узлов (например; Salt、Ansible и т. д.) или зеркало, вы также можете использовать Конфигурационный; файлкопировать в каждый узел и передать SSH Загрузите их, обратитесь к примеру.

Справочные ссылки:

• Документация AppArmor: https://gitlab.com/apparmor/apparmor/-/wikis/Documentation.
• bane：https://github.com/genuinetools/bane
• apparmor-loader：https://github.com/kubernetes/kubernetes/tree/master/test/images/apparmor-loader
• Загрузите пример файла конфигурации: https://kubernetes.io/zh-cn/docs/tutorials/security/apparmor/#example.