🥇Seccomp в Kubernetes: 7 неща, които трябва да знаете от самото начало

Прим. прев.: Представяме вниманието на превода на статията на старши инженер по сигурност на приложенията в британската компания ASOS.com. С нея той започва цикъл от публикации, посветени на повишаване на сигурността в Kubernetes чрез използване на seccomp. Ако интродукцията хареса на читателите, ще последваме автора и ще продължим с бъдещи материали по тази тема.

Seccomp в Kubernetes: 7 неща, които трябва да знаете от самото начало

Тази статия е първата от серия публикации за това как да създаваме профили seccomp в духа на SecDevOps, без да прибягваме до магия и колдовство. В първата част ще разкажа за основите и вътрешните детайли на реализирането на seccomp в Kubernetes.

Екосистемата Kubernetes предлага достатъчно разнообразие от начини за осигуряване на сигурност и изолация на контейнери. Статията е посветена на Secure Computing Mode, известен още като seccomp. Неговата същност е филтрирането на системни повиквания, достъпни за изпълнение от контейнерите.

Защо е важно? Контейнерът е просто определен процес, стартиран на определена машина. И той използва ядрото наравно с другите приложения. Ако контейнерите можеха да изпълняват каквито и да било системни повиквания, много скоро зловредни програми биха се възползвали от това, за да заобиколят изолацията на контейнера и да повлияят на други приложения: да прихващат информация, да променят системни настройки и т.н.

Профилите seccomp определят кои системни повиквания трябва да бъдат разрешени или забранени. Средата за изпълнение на контейнера активира тях по време на стартирането му, така че ядрото да може да контролира тяхното изпълнение. Приложението на подобни профили позволява ограничаване на вектора на атака и намаляване на щетите, ако някоя програма вътре в контейнера (т.е. вашите зависимости или зависимостите на техните зависимости) започне да прави нещо, което не ѝ е разрешено.

Разглеждаме основите

Основният профил seccomp включва три елемента: defaultAction, architectures (или archMap) и syscalls.:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "sched_yield",
                "futex",
                "write",
                "mmap",
                "exit_group",
                "madvise",
                "rt_sigprocmask",
                "getpid",
                "gettid",
                "tgkill",
                "rt_sigaction",
                "read",
                "getpgrp"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(medium-basic-seccomp.json)

defaultAction определя съдбата по подразбиране на всяко системно повикване, което не е посочено в раздела syscalls.. За да опростим задачата, ще се фокусираме върху две основни стойности, които ще бъдат използвани:

SCMP_ACT_ERRNO — блокира изпълнението на системно повикване,
SCMP_ACT_ALLOW — разрешава.

В секцията architectures перечисляют целеви архитектури. Това е важно, тъй като самият филтър, прилаган на ниво ядро, зависи от идентификаторите на системните повиквания, а не от имената им, записани в профила. Преди прилагане средата на изпълнение на контейнера ще ги съпостави с идентификаторите. Идеята е, че системните повиквания могат да имат напълно различни идентификатори в зависимост от архитектурата на системата. Например, системното повикване recvfrom (използва се за получения информация от сокета) има идентификатор = 64 в x64-системи и идентификатор = 517 в x86. Тук можете да намерите списък на всички системни повиквания за архитектури x86-x64.

В секцията syscalls. перечисляют всички системни повиквания и указват какво трябва да се направи с тях. Например, можете да създадете бял списък, като зададете defaultAction на SCMP_ACT_ERRNO, а на повикванията в секцията syscalls. да присвоите SCMP_ACT_ALLOW. По този начин разрешавате само повикванията, записани в раздела syscalls., и забранявате всички останали. За черния списък трябва да смените стойностите defaultAction и действията на противоположни.

Сега трябва да кажем няколко думи за нюансите, които не са толкова очевидни. Обърнете внимание, че препоръките по-долу изхождат от това, че развивате набор от бизнес приложения в Kubernetes и е важно те да работят с най-ниски привилегии.

1. AllowPrivilegeEscalation=false

В securityContext в контейнера има параметър AllowPrivilegeEscalation. Ако е зададен на неверно, контейнерите ще се стартират с зададена (включено) бит no_new_priv. Същността на този параметър е очевидна от името: той не позволява на контейнера да стартира нови процеси с привилегии, по-големи от тези, които вече има.

Страничният ефект на този параметър, зададен на истинно (стойност по подразбиране), е, че средата на изпълнение на контейнера прилага профила seccomp в самото начало на процеса на стартиране. По този начин всички системни повиквания, необходими за стартиране на вътрешните процеси на средата на изпълнение (например, задаване на идентификаторите на потребителя/групата, отхвърляне на някои capabilities), трябва да бъдат разрешени в профила.

Контейнеру, который выполняет банальное echo hi, потребуются следующие разрешения:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "brk",
                "capget",
                "capset",
                "chdir",
                "close",
                "execve",
                "exit_group",
                "fstat",
                "fstatfs",
                "futex",
                "getdents64",
                "getppid",
                "lstat",
                "mprotect",
                "nanosleep",
                "newfstatat",
                "openat",
                "prctl",
                "read",
                "rt_sigaction",
                "statfs",
                "setgid",
                "setgroups",
                "setuid",
                "stat",
                "uname",
                "write"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(hi-pod-seccomp.json)

… вместо тези:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "brk",
                "close",
                "execve",
                "exit_group",
                "futex",
                "mprotect",
                "nanosleep",
                "stat",
                "write"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(hi-container-seccomp.json)

Но отново, защо е проблем това? Лично аз бих избегнал да добавям в белия списък следните системни повиквания (освен ако не е наистина необходимо): capset, set_tid_address, setgid, setgroups и setuid. Въпреки това, истинската сложност е в това, че разрешаването на процеси, които абсолютно не контролирате, обвързва профилите с изпълнението на средата на контейнерите. С други думи, един ден можете да се окажете, че след ъпдейт на средата на контейнера (от вас или, по-вероятно, от доставчика на облачни услуги), контейнерите изведнъж спират да работят.

Съвет №1: Стартирайте контейнерите с AllowPrivilegeEscaltion=false. Това ще намали размерът на seccomp профилите и ще ги направи по-малко чувствителни към промените в средата на изпълнение на контейнера.

2. Задаване на seccomp профили на ниво контейнер

Seccomp профил може да се задава на ниво pod:

annotations:
  seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json"

… или на ниво контейнер:

annotations:
  container.security.alpha.kubernetes.io/<container-name>: "localhost/profile.json"

Обърнете внимание, че горепосоченият синтаксис ще се промени, когато Kubernetes seccomp стана GA (това събитие се очаква в следващото издание на Kubernetes — 1.18 — бел. прев.)

Малцина знаят, че в Kubernetes винаги е имало баг, поради което seccomp профилите се прилагаха към pause-контейнераИзпълнителната среда частично компенсира този недостатък, но този контейнер не изчезва от pod-овете, тъй като се използва за настройка на тяхната инфраструктура.

Проблемът е, че този контейнер винаги стартира с AllowPrivilegeEscalation=true, което води до проблеми, посочени в точка 1, и не може да бъде променено.

Като прилагате seccomp профили на ниво контейнер, избягвате този капан и можете да създадете профил, който е «настроен» за конкретен контейнер. Това ще трябва да се прави, докато разработчиците не отстранят грешката и новата версия (може би 1.18?) не стане на разположение за всички желаещи.

Съвет №2: Задавайте seccomp профили на ниво контейнер.

В практически смисъл това правило обикновено служи като универсален отговор на въпроса: «Защо моят seccomp профил работи с docker run, но не работи след разгръщането в кластера Kubernetes?».

3. Използвайте runtime/default само в краен случай

В Kubernetes има два варианта на вградени профили: runtime/default и docker/default. И двата се реализират от средата за изпълнение на контейнера, а не от Kubernetes. Следователно могат да се различават в зависимост от използваната среда за изпълнение и нейната версия.

С други думи, в резултат на смяната на runtime, контейнерът може да получи достъп до друг набор от системни повици, които може да използва или не. Повечето среди за изпълнение използват реализацията на Docker. Ако желаете да използвате този профил, уверете се, че е подходящ за вас.

Профилът docker/default се счита за остарял с Kubernetes 1.11, затова избягвайте неговото използване.

По мое мнение, профилът runtime/default перфектно подхожда за целите, за които е създаден: защита на потребителите от рисковете, свързани с изпълнението на команда docker run на техните машини. Въпреки това, що се отнася до бизнес приложенията, работещи в кластери Kubernetes, бих си позволил да твърдя, че такъв профил е твърде отворен и разработчиците трябва да се съсредоточат върху създаването на профили за техните приложения (или типове приложения).

Съвет №3: Създавайте seccomp профили за конкретни приложения. Ако това не е възможно, работете по профили за видове приложения, например, създайте разширен профил, който да включва всички уеб-API на приложението на Golang. Използвайте runtime/default само като крайна мярка.

В бъдещите публикации ще представя как да създаваме seccomp профили в духа на SecDevOps, да ги автоматизираме и тестваме в пайплайни. С други думи, няма да имате извинения да не преминете на профили за конкретни приложения.

4. Unconfined — това НЕ е вариант

От първия одит на сигурността на Kubernetes се установи, че по подразбиране seccomp е деактивиран. Това означава, че ако не зададете PodSecurityPolicy, който да го активира в клъстера, всички pod’ове, за които не е определен seccomp профил, ще работят в режим seccomp=unconfined.

Работата в този режим означава, че се губи цял слой изолация, осигуряващ защита на клъстера. Подобен подход не се препоръчва от специалисти по сигурност.

Съвет №4: Никакъв контейнер в клъстера не трябва да работи в режим seccomp=unconfined, особено в production среди.

5. „Режим на одит“

Тази точка не е уникална за Kubernetes, но все пак попада в категорията „неща, които трябва да знаете още преди да започнете“.

Традиционно, създаването на seccomp профили винаги е било сложно начинание и в значителна степен зависеше от метода на пробите и грешките. Работата е там, че потребителите просто нямат възможност да ги тестват в production среди, без да рискуват да „срутят“ приложението.

След появата на ядрото на Linux 4.14, стана възможно да се стартират части от профила в режим на одит, записвайки в syslog информация за всички системни повиквания, без да блокират техния процес. Активирането на този режим става чрез параметъра SCMT_ACT_LOG:

SCMP_ACT_LOG: seccomp няма да влияе на работата на потока, който прави системното повикване, ако не попада под някое от правилата на филтъра, но информацията за системното повикване ще бъде записана в журнала.

Ето типичната стратегия за използване на тази възможност:

Разрешаване на системни повиквания, които са необходими.
Блокиране на системни повиквания, за които знаем, че няма да бъдат полезни.
Записване на информация за всички останали повиквания в журнала.

Опростен пример изглежда по следния начин:

{
    "defaultAction": "SCMP_ACT_LOG",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "sched_yield",
                "futex",
                "write",
                "mmap",
                "exit_group",
                "madvise",
                "rt_sigprocmask",
                "getpid",
                "gettid",
                "tgkill",
                "rt_sigaction",
                "read",
                "getpgrp"
            ],
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": [
                "add_key",
                "keyctl",
                "ptrace"
            ],
            "action": "SCMP_ACT_ERRNO"
        }
    ]
}

(medium-mixed-seccomp.json)

Но помнете, че е необходимо да блокирате всички извиквания, за които знаете, че няма да бъдат използвани, и които потенциално могат да навредят на кластера. Добра основа за съставяне на списъка е официалната документация на Docker. В нея подробно се обяснява кои системни извиквания са блокирани по подразбиране и защо.

Въпреки това, има един недостатък. Макар SCMT_ACT_LOG да се поддържа от ядро на Linux от края на 2017 година, той влезе в екосистемата на Kubernetes сравнително скоро. Следователно, за да използвате този метод, ще са необходими ядро на Linux 4.14 и версия на runC не по-ниска от v1.0.0-rc9.

Съвет №5: Профилът на режима на аудит за тестване в продукционна среда може да бъде създаден, комбинирайки черни и бели списъци, а всички изключения да се записват в журнал.

6. Използвайте бели списъци

Създаването на бели списъци изисква допълнителни усилия, тъй като трябва да се идентифицира всяко извикване, което може да е необходимо на приложението, обаче този подход значително увеличава сигурността:

Настоятелно се препоръчва да се използва подходът на базата на бели списъци, тъй като той е по-прост и надежден. Черният списък трябва да се актуализира всеки път, когато се добави потенциално опасно системно извикване (или опасен флаг/опция, ако те са в черния списък). Освен това, често може да се промени представянето на параметъра, без да се променя неговата същност и по този начин да се заобиколят ограниченията на черния списък.

За приложения на езика Go разработих специален инструмент, който следва приложението и събира всички извиквания, извършени по време на изпълнение. Например, за следното приложение:

package main

import "fmt"

func main() {
	fmt.Println("test")
}

… ще стартираме gosystract така:

go install https://github.com/pjbgf/gosystract
gosystract --template='{{- range . }}{{printf "%s", .Name}}{{- end}}' application-path

… и ще получим следния резултат:

"sched_yield",
"futex",
"write",
"mmap",
"exit_group",
"madvise",
"rt_sigprocmask",
"getpid",
"gettid",
"tgkill",
"rt_sigaction",
"read",
"getpgrp",
"arch_prctl",

В момента това е само пример — детайли относно инструментите ще бъдат по-нататък.

Съвет №6: Позволявайте само онези повиквания, които наистина са ви необходими, и блокирайте всички останали.

7. Положете правилните основи (или се подгответе за неочаквано поведение)

Ядрото ще следи за спазването на профила независимо от това, което сте задали. Дори и ако това не е точно това, което искате. Например, ако забраните достъп до повиквания като exit или exit_group, контейнерът няма да може да приключи правилно и дори простата команда тип echo hi може да гоокачи за неопределен период от време. В резултат на това ще получите висока натовареност на CPU в клъстера:

Seccomp в Kubernetes: 7 неща, които трябва да знаете от самото начало

В такива случаи утилитата strace може да ви помогне — тя ще покаже в какво може да е проблемът:

Seccomp в Kubernetes: 7 неща, които трябва да знаете от самото начало
sudo strace -c -p 9331

Уверете се, че профилите съдържат всички системни повиквания, нужни на приложението по време на работа.

Съвет №7: Внимавайте с детайлите и проверявайте дали всички необходими системни повиквания са включени в бял списък.

Тази първа част от цикъла статии за използването на seccomp в Kubernetes в духа на SecDevOps завършва тук. В следващите части ще говорим за това защо това е важно и как да автоматизираме процеса.

P.S. от преводача

Прочетете също в нашия блог:

Източник: habr.com