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

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

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

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

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

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

Стигане до основите

Основният профил на seccomp включва три елемента: defaultAction, architectures (Or 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"
        }
    ]
}

(среден основен-seccomp.json)

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

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

В раздел architectures изброени са целевите архитектури. Това е важно, тъй като самият филтър, приложен на ниво ядро, зависи от идентификаторите на системните извиквания, а не от техните имена, посочени в профила. Времето за изпълнение на контейнера ще ги съпостави с идентификатори преди употреба. Идеята е, че системните повиквания могат да имат напълно различни идентификатори в зависимост от системната архитектура. Например системно повикване 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 в самото начало на процеса на стартиране. Следователно всички системни повиквания, необходими за изпълнение на вътрешни процеси по време на изпълнение (напр. задаване на идентификатори на потребители/групи, премахване на определени възможности), трябва да бъдат активирани в профила.

Към контейнер, който прави тривиални неща 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 да бъдат приложени към пауза контейнер. Средата за изпълнение частично компенсира този недостатък, но този контейнер не изчезва от подовете, тъй като се използва за конфигуриране на тяхната инфраструктура.

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

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

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

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

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

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

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

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

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

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

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

4. Без ограничения НЕ е опция.

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

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

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

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

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

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

След пускането на ядрото на 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"
        }
    ]
}

(средно-смесен-seccomp.json)

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

Има обаче една уловка. Макар че 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",n" .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 обесете гоo за неопределено време. В резултат на това ще получите високо използване на процесора в клъстера:

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

sudo strace -c -p 9331

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

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

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

PS от преводача

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

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

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