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

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

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

Екосистемата на Kubernetes предлага достатъчно разнообразие от начини за осигуряване на сигурност и изолация на контейнерите. Статията е посветена на Режимът на Сигурно Изчисление, известен също като 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 се изброяват целевите архитектури. Важно е, защото самият филтър, приложен на ниво ядро, зависи от идентификаторите на системните извиквания, а не от имената им, посочени в профила. Преди прилагане средата за изпълнение на контейнера ще ги сопостави с идентификаторите. Идеята е, че системните извиквания може да имат напълно различни ID в зависимост от архитектурата на системата. Например, системното извикване recvfrom (използва се за получаване на информация от сокет) има ID = 64 в x64 системи и ID = 517 в x86. Тук можете да намерите списък на всичките системни извиквания за архитектурите x86-x64.

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

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

1. AllowPrivilegeEscalation=false

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

Нежелан ефект от задаването на този параметър на true (стойност по подразбиране) е, че средата за изпълнение на контейнера прилага профила 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/: "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, особено в производствени среди.

5. «Режим на одит»

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

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

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

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

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

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

Простият пример изглежда така:

{
    "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 натовареност в клъстера:

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

sudo strace -c -p 9331

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

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

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

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

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

• «Сигурност за Docker контейнери»;
• «33+ инструмента за сигурност на Kubernetes»;
• «Docker и Kubernetes в среди с високи изисквания за сигурност»;
• «9 най-добри практики за осигуряване на сигурност в Kubernetes».

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