Обмеження системних викликів контейнера за допомогою seccomp
Kubernetes v1.19 [stable]
Seccomp походить від secure computing mode (безпечний режим обчислення) і є функцією ядра Linux з версії 2.6.12. Його можна використовувати для ізоляції привілеїв процесу, обмежуючи виклики, які він може здійснювати з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів та контейнерів.
Визначення необхідних привілеїв для ваших робочих навантажень може бути важким завданням. У цьому посібнику ви дізнаєтеся, як завантажувати профілі seccomp в локальний кластер Kubernetes, як застосовувати їх до Podʼа та як ви можете почати створювати профілі, які надають лише необхідні привілеї процесам вашого контейнера.
Цілі
- Навчитися завантажувати профілі seccomp на вузол
- Навчитися застосовувати профіль seccomp до контейнера
- Спостерігати за аудитом системних викликів, здійснюваних процесом контейнера
- Спостерігати поведінку при відсутності вказаного профілю
- Спостерігати порушення профілю seccomp
- Навчитися створювати деталізовані профілі seccomp
- Навчитися застосовувати стандартний профіль seccomp для контейнера
Перш ніж ви розпочнете
Для завершення всіх кроків у цьому посібнику вам потрібно встановити kind та kubectl.
Команди, які використовуються в посібнику, передбачають, що ви використовуєте Docker як ваше середовище для виконання контейнерів. (Кластер, який створює kind
, може використовувати інше контейнерне середовище також). Ви також можете використовувати Podman, але у цьому випадку вам доведеться дотримуватися відповідних інструкцій, щоб успішно виконати завдання.
У цьому посібнику показано деякі приклади, які є бета-версією (починаючи з v1.25) і інші, які використовують лише загальнодоступну функціональність seccomp. Вам слід переконатися, що ваш кластер правильно налаштований для версії, яку ви використовуєте.
У посібнику також використовується інструмент curl
для завантаження прикладів на ваш компʼютер. Ви можете адаптувати кроки, щоб використовувати інший інструмент, якщо вам це зручно.
Примітка:
Неможливо застосувати профіль seccomp до контейнера, який працює з параметромprivileged: true
, встановленим в securityContext
контейнера. Привілейовані контейнери завжди виконуються як Unconfined
.Завантаження прикладів профілів seccomp
Вміст цих профілів буде досліджено пізніше, але наразі продовжте та завантажте їх у каталог з назвою profiles/
, щоб їх можна було завантажити в кластер.
{
"defaultAction": "SCMP_ACT_LOG"
}
{
"defaultAction": "SCMP_ACT_ERRNO"
}
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"accept4",
"epoll_wait",
"pselect6",
"futex",
"madvise",
"epoll_ctl",
"getsockname",
"setsockopt",
"vfork",
"mmap",
"read",
"write",
"close",
"arch_prctl",
"sched_getaffinity",
"munmap",
"brk",
"rt_sigaction",
"rt_sigprocmask",
"sigaltstack",
"gettid",
"clone",
"bind",
"socket",
"openat",
"readlinkat",
"exit_group",
"epoll_create1",
"listen",
"rt_sigreturn",
"sched_yield",
"clock_gettime",
"connect",
"dup2",
"epoll_pwait",
"execve",
"exit",
"fcntl",
"getpid",
"getuid",
"ioctl",
"mprotect",
"nanosleep",
"open",
"poll",
"recvfrom",
"sendto",
"set_tid_address",
"setitimer",
"writev",
"fstatfs",
"getdents64",
"pipe2",
"getrlimit"
],
"action": "SCMP_ACT_ALLOW"
}
]
}
Виконайте ці команди:
mkdir ./profiles
curl -L -o profiles/audit.json https://k8s.io/examples/pods/security/seccomp/profiles/audit.json
curl -L -o profiles/violation.json https://k8s.io/examples/pods/security/seccomp/profiles/violation.json
curl -L -o profiles/fine-grained.json https://k8s.io/examples/pods/security/seccomp/profiles/fine-grained.json
ls profiles
Ви повинні побачити три профілі, перераховані в кінці останнього кроку:
audit.json fine-grained.json violation.json
Створення локального кластера Kubernetes за допомогою kind
Для спрощення можна використовувати kind, щоб створити одновузловий кластер з завантаженими профілями seccomp. Kind запускає Kubernetes в Docker, тому кожен вузол кластера є контейнером. Це дозволяє монтувати файли в файлову систему кожного контейнера, схоже на завантаження файлів на вузол.
apiVersion: kind.x-k8s.io/v1alpha4
kind: Cluster
nodes:
- role: control-plane
extraMounts:
- hostPath: "./profiles"
containerPath: "/var/lib/kubelet/seccomp/profiles"
Завантажте цей приклад конфігурації kind та збережіть його у файлі з назвою kind.yaml
:
curl -L -O https://k8s.io/examples/pods/security/seccomp/kind.yaml
Ви можете встановити конкретну версію Kubernetes, встановивши образ контейнера вузла. Дивіться Вузли в документації kind щодо конфігурації для отримання більш детальної інформації з цього питання. Цей посібник передбачає, що ви використовуєте Kubernetes v1.32.
Як бета-функція, ви можете налаштувати Kubernetes на використання профілю, який обирає стандартне середовище виконання контейнерів, замість того, щоб використовувати Unconfined
. Якщо ви хочете спробувати це, дивіться
увімкнення використання RuntimeDefault
як типового профілю за замовчуванням для всіх завдань перш ніж продовжувати.
Як тільки у вас буде конфігурація kind, створіть кластер kind з цією конфігурацією:
kind create cluster --config=kind.yaml
Після створення нового кластера Kubernetes ідентифікуйте контейнер Docker, що працює як одновузловий кластер:
docker ps
Ви повинні побачити вивід, який вказує на те, що контейнер працює з назвою kind-control-plane
, подібний до:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6a96207fed4b kindest/node:v1.18.2 "/usr/local/bin/entr…" 27 seconds ago Up 24 seconds 127.0.0.1:42223->6443/tcp kind-control-plane
Якщо спостерігати файлову систему цього контейнера, ви побачите, що тека profiles/
була успішно завантажена в стандартний шлях seccomp з kubelet. Використовуйте docker exec
, щоб виконати команду в Podʼі:
# Змініть 6a96207fed4b на ідентифікатор контейнера, який ви знайдете в результаті "docker ps"
docker exec -it 6a96207fed4b ls /var/lib/kubelet/seccomp/profiles
audit.json fine-grained.json violation.json
Ви перевірили, що ці профілі seccomp доступні для kubelet, що працює всередині kind.
Створення Pod, що використовує стандартний профіль seccomp середовища виконання контейнерів
Більшість контейнерних середовищ надають типовий перелік системних викликів, які дозволені або заборонені. Ви можете використовувати ці стандартні налаштування для вашого робочого навантаження, встановивши тип seccomp у контексті безпеки Pod або контейнера на RuntimeDefault
.
Примітка:
Якщо у вас увімкнуто параметр конфігураціїseccompDefault
, то Podʼи використовують профіль seccomp RuntimeDefault
, якщо не вказано жодного іншого профілю seccomp. В іншому випадку, використовується Unconfined
.Ось маніфест Podʼа, який запитує профіль seccomp RuntimeDefault
для всіх своїх контейнерів:
apiVersion: v1
kind: Pod
metadata:
name: default-pod
labels:
app: default-pod
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: test-container
image: hashicorp/http-echo:1.0
args:
- "-text=just made some more syscalls!"
securityContext:
allowPrivilegeEscalation: false
Створіть цей Pod:
kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/default-pod.yaml
kubectl get pod default-pod
Под повинен бути запущений успішно:
NAME READY STATUS RESTARTS AGE
default-pod 1/1 Running 0 20s
Видаліть Pod перед переходом до наступного розділу:
kubectl delete pod default-pod --wait --now
Створення Podʼа з профілем seccomp для аудиту системних викликів
Для початку, застосуйте профіль audit.json
, який буде записувати всі системні виклики процесу, до нового Podʼа.
Ось маніфест для цього Podʼа:
apiVersion: v1
kind: Pod
metadata:
name: audit-pod
labels:
app: audit-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/audit.json
containers:
- name: test-container
image: hashicorp/http-echo:1.0
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false
Примітка:
Старі версії Kubernetes дозволяли налаштовувати поведінку seccomp за допомогою анотацій. Kubernetes 1.32 підтримує лише використання полів у межах.spec.securityContext
для налаштування seccomp, і цей посібник пояснює саме цей підхід.Створіть Pod у кластері:
kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/audit-pod.yaml
Цей профіль не обмежує жодні системні виклики, тому Pod повинен успішно запуститися.
kubectl get pod audit-pod
NAME READY STATUS RESTARTS AGE
audit-pod 1/1 Running 0 30s
Щоб мати можливість взаємодіяти з цим точкою доступу, створіть Service NodePort, який дозволяє доступ до точки доступу зсередини контейнера панелі управління kind.
kubectl expose pod audit-pod --type NodePort --port 5678
Перевірте, який порт було призначено Service на вузлі.
kubectl get service audit-pod
Вивід буде схожим на:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
audit-pod NodePort 10.111.36.142 <none> 5678:32373/TCP 72s
Тепер ви можете використовувати curl
, щоб отримати доступ до цієї точки доступу зсередини контейнера панелі управління kind на порту, який було відкрито цим Service. Використовуйте docker exec
, щоб виконати команду curl
всередині контейнера панелі управління:
# Змініть 6a96207fed4b на ідентифікатор контейнера панелі управління та 32373 на номер порту, який ви побачили у "docker ps"
docker exec -it 6a96207fed4b curl localhost:32373
just made some syscalls!
Ви можете бачити, що процес працює, але які саме системні виклики він робить? Оскільки цей Pod працює у локальному кластері, ви повинні бачити їх у /var/log/syslog
у вашій локальній системі. Відкрийте нове вікно термінала та використовуйте команду tail
, щоб переглянути виклики від http-echo
:
# Шлях до логу на вашому компʼютері може відрізнятися від "/var/log/syslog"
tail -f /var/log/syslog | grep 'http-echo'
Ви вже повинні бачити деякі логи системних викликів, зроблених http-echo
, і якщо ви знову запустите curl
всередині контейнера панелі управління, ви побачите більше записів у лозі.
Наприклад:
Jul 6 15:37:40 my-machine kernel: [369128.669452] audit: type=1326 audit(1594067860.484:14536): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=51 compat=0 ip=0x46fe1f code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669453] audit: type=1326 audit(1594067860.484:14537): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=54 compat=0 ip=0x46fdba code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669455] audit: type=1326 audit(1594067860.484:14538): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669456] audit: type=1326 audit(1594067860.484:14539): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=288 compat=0 ip=0x46fdba code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669517] audit: type=1326 audit(1594067860.484:14540): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=0 compat=0 ip=0x46fd44 code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669519] audit: type=1326 audit(1594067860.484:14541): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
Jul 6 15:38:40 my-machine kernel: [369188.671648] audit: type=1326 audit(1594067920.488:14559): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
Jul 6 15:38:40 my-machine kernel: [369188.671726] audit: type=1326 audit(1594067920.488:14560): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000
Ви можете почати розуміти системні виклики, необхідні для процесу http-echo
, переглядаючи запис syscall=
на кожному рядку. Хоча ці виклики навряд чи охоплюють усі системні виклики, які він використовує, це може слугувати основою для профілю seccomp для цього контейнера.
Видаліть Service та Pod перед переходом до наступного розділу:
kubectl delete service audit-pod --wait
kubectl delete pod audit-pod --wait --now
Створення Podʼа з профілем seccomp, що спричиняє порушення правил
Для демонстрації застосуйте до Podʼа профіль, який не дозволяє жодних системних викликів.
Ось маніфест для цієї демонстрації:
apiVersion: v1
kind: Pod
metadata:
name: violation-pod
labels:
app: violation-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/violation.json
containers:
- name: test-container
image: hashicorp/http-echo:1.0
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false
Спробуйте створити Pod у кластері:
kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/violation-pod.yaml
Pod буде створено, але виникне проблема. Якщо ви перевірите стан Podʼа, ви побачите, що його не вдалося запустити.
kubectl get pod violation-pod
NAME READY STATUS RESTARTS AGE
violation-pod 0/1 CrashLoopBackOff 1 6s
Як видно з попереднього прикладу, процес http-echo
потребує досить багато системних викликів. У цьому випадку seccomp було налаштовано на помилку при будь-якому системному виклику, встановивши "defaultAction": "SCMP_ACT_ERRNO"
. Це надзвичайно безпечно, але робить неможливим виконання будь-яких значущих дій. Насправді ви хочете надати робочим навантаженням тільки ті привілеї, які їм потрібні.
Видаліть Pod перед переходом до наступного розділу:
kubectl delete pod violation-pod --wait --now
Створення Podʼа з профілем seccomp, що дозволяє лише необхідні системні виклики
Якщо ви подивитеся на профіль fine-grained.json
, ви помітите деякі з системних викликів, які спостерігалися в syslog у першому прикладі, де профіль встановлював "defaultAction": "SCMP_ACT_LOG"
. Тепер профіль встановлює "defaultAction": "SCMP_ACT_ERRNO"
, але явно дозволяє набір системних викликів у блоці "action": "SCMP_ACT_ALLOW"
. Ідеально, якщо контейнер буде успішно працювати, і ви не побачите жодних повідомлень у syslog
.
Маніфест для цього прикладу:
apiVersion: v1
kind: Pod
metadata:
name: fine-pod
labels:
app: fine-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/fine-grained.json
containers:
- name: test-container
image: hashicorp/http-echo:1.0
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false
Створіть Pod у вашому кластері:
kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/fine-pod.yaml
kubectl get pod fine-pod
Pod має успішно запуститися:
NAME READY STATUS RESTARTS AGE
fine-pod 1/1 Running 0 30s
Відкрийте нове вікно термінала і використовуйте tail
для моніторингу записів лога, які згадують виклики від http-echo
:
# Шлях до лога на вашому компʼютері може відрізнятися від "/var/log/syslog"
tail -f /var/log/syslog | grep 'http-echo'
Далі, опублікуйте Pod за допомогою Service NodePort:
kubectl expose pod fine-pod --type NodePort --port 5678
Перевірте, який порт було призначено для цього сервісу на вузлі:
kubectl get service fine-pod
Вихідні дані можуть виглядати приблизно так:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
fine-pod NodePort 10.111.36.142 <none> 5678:32373/TCP 72s
Використовуйте curl
для доступу до цієї точки доступу з контейнера панелі управління kind:
# Змініть 6a96207fed4b на ID контейнера панелі управління і 32373 на номер порту, який ви побачили у "docker ps"
docker exec -it 6a96207fed4b curl localhost:32373
just made some syscalls!
Ви не повинні побачити жодних записів у syslog
. Це тому, що профіль дозволив усі необхідні системні виклики та вказав, що повинна статися помилка, якщо буде викликано виклик, який не входить до списку. Це ідеальна ситуація з погляду безпеки, але потребує певних зусиль для аналізу програми. Було б добре, якби існував простий спосіб наблизитися до такої безпеки без стількох зусиль.
Видаліть Service і Pod перед переходом до наступного розділу:
kubectl delete service fine-pod --wait
kubectl delete pod fine-pod --wait --now
Увімкнення використання RuntimeDefault
як стандартного профілю seccomp для всіх робочих навантажень
Kubernetes v1.27 [stable]
Для використання стандартного профілю seccomp, необхідно запустити kubelet з параметром командного рядка --seccomp-default
увімкненим для кожного вузла, де ви хочете його використовувати.
Якщо ця функція увімкнена, kubelet буде використовувати як типовий профіль seccomp RuntimeDefault
, який визначений середовищем виконання контейнерів, замість використання режиму Unconfined
(seccomp вимкнений). Типові профілі прагнуть забезпечити сильний набір налаштувань безпеки, зберігаючи функціональність робочих навантажень. Можливо, типові профілі відрізняються між середовищами виконання контейнерів та їх версіями випуску, наприклад, порівнюючи профілів CRI-O та containerd.
Примітка:
Увімкнення цієї функції не змінює поле APIsecurityContext.seccompProfile
у Kubernetes і не додає застарілі анотації робочих навантажень. Це дає користувачам можливість повернутися до попереднього стану в будь-який час без фактичної зміни конфігурації робочих навантажень. Такі інструменти, як crictl inspect
, можуть бути використані для перевірки, який профіль seccomp використовується контейнером.Деякі робочі навантаження можуть вимагати меншої кількості обмежень системних викликів, ніж інші. Це означає, що вони можуть зазнати невдачі під час виконання навіть із профілем RuntimeDefault
. Для помʼякшення таких невдач можна:
- Запустити робоче навантаження явно як
Unconfined
. - Вимкнути функцію
SeccompDefault
для вузлів, забезпечуючи, щоб робочі навантаження виконувалися на вузлах, де ця функція вимкнена. - Створити власний профіль seccomp для робочого навантаження.
Якщо ви вводите цю функцію до кластера подібного до операційного, проєкт Kubernetes рекомендує увімкнути цю функцію на підмножині ваших вузлів та перевірити виконання робочих навантажень перед повсюдним впровадженням змін.
Детальнішу інформацію про можливу стратегію оновлення та відкату ви можете знайти в повʼязаній пропозиції щодо поліпшення Kubernetes (KEP): Увімкнення seccomp стандартно.
Kubernetes 1.32 дозволяє налаштувати профіль seccomp, який застосовується, коли специфікація для Podʼа не визначає конкретний профіль seccomp. Однак, вам все одно потрібно увімкнути це налаштування як типове для кожного вузла, де ви хочете його використовувати.
Якщо ви працюєте у кластері Kubernetes 1.32 і хочете увімкнути цю функцію, ви можете запустити kubelet з параметром командного рядка --seccomp-default
або увімкнути її через файл конфігурації kubelet. Щоб увімкнути цю функцію у kind, переконайтеся, що kind забезпечує мінімально необхідну версію Kubernetes і вмикає функцію SeccompDefault
у конфігурації kind:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c
kubeadmConfigPatches:
- |
kind: JoinConfiguration
nodeRegistration:
kubeletExtraArgs:
seccomp-default: "true"
- role: worker
image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c
kubeadmConfigPatches:
- |
kind: JoinConfiguration
nodeRegistration:
kubeletExtraArgs:
seccomp-default: "true"
Якщо кластер готовий, тоді запустіть Pod:
kubectl run --rm -it --restart=Never --image=alpine alpine -- sh
тепер він повинен мати прикріплений типовий профіль seccomp. Це можна перевірити, використовуючи docker exec
для запуску crictl inspect
для контейнера на вузлі kind:
docker exec -it kind-worker bash -c \
'crictl inspect $(crictl ps --name=alpine -q) | jq .info.runtimeSpec.linux.seccomp'
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"],
"syscalls": [
{
"names": ["..."]
}
]
}
Що далі
Ви можете дізнатися більше про Linux seccomp: