Seccomp Kubernetes'is: 7 asja, mida alates algusest teadma peab

Märkus tõlke kohta.: Esitleme Briti firma ASOS.com'i vanema rakendusohutuse inseneri artikli tõlget. Alustame sarja avaldusi, mis käsitlevad Kubernetes'e turvalisuse tõstmiseks seccomp'i kasutamist. Kui sissejuhatus lugejatele meeldib, järgime autorit ja jätkame tema tulevaste materjalidega selle teema kohta.

See artikkel on esimene osa seeriast, mis käsitleb seccomp'i profiilide loomise protsessi SecDevOps'i vaimus, ilma igasuguste nõiduse ja võludeta. Esimeses osas räägin seccomp'i põhialustest ja rakendamise sisemistest detailidest Kubernetes'es.

Kubernetes'e ökosüsteem pakub piisavat mitmekesisust konteinerite turvalisuse ja isoleerimise tagamiseks. Artikkel käsitleb Secure Computing Mode'i, tuntud ka kui seccomp. Selle olemus seisneb konteinerite teostamiseks lubatud süsteemikõnede filtreerimises.

Miks see on oluline? Kood on lihtsalt protsess, mis töötab teatud masinas. Ja see jagab tuuma teiste rakendustega. Kui konteinerid saaksid teha igasuguseid süsteemikõnesid, kasutaksid pahavara seda peagi ära, et mööda minna konteineri isoleerimisest ja mõjutada teisi rakendusi: teavet hõivata, süsteemi seadeid muuta jne.

Seccomp'i profiilid määravad, milliseid süsteemikõnesid tohib lubada või keelata. Konteineri täitmisvõime aktiveerib need selle käivitamise ajal, et tuum saaks nende täitmisprotsessi jälgida. Selliste profiilide rakendamine aitab piirata ründevektoreid ja vähendada kahjusid, kui mõni programm konteineris (st teie sõltuvused või nende sõltuvused) hakkab tegema seda, mida talle ei lubata.

Tuleme põhialuste juurde

Seccomp'i põhiprofiil sisaldab kolme elementi: defaultAction, architectures (või archMap) ja 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 määrab vaikimisi tegevuse iga süsteemikõne puhul, mis ei ole esitatud syscalls. Ette lihtsustada, keskendume kahele põhiväärtusele, mida kasutatakse:

• SCMP_ACT_ERRNO — blokeerib süsteemikõne täitmise,
• SCMP_ACT_ALLOW — lubab.

Jaotises architectures loetletakse sihtarchitectuurid. See on oluline, kuna ise filter, mida rakendatakse kerneli tasemel, sõltub süsteemikõnede identifikaatoritest, mitte nende nimedest, mis on määratud profiilis. Enne rakendamist kaasvastav keskkond seondab need identifikaatoridega. Tähendus on see, et süsteemikõned võivad olla erinevate ID-dega sõltuvalt süsteemi arhitektuurist. Näiteks süsteemikõne recvfrom (kasutatakse teabe saamiseks soketilt) on ID = 64 x64-süsteemides ja ID = 517 x86. Siin saate leida kogu süsteemikõnede nimekirja x86-x64 arhitektuuride jaoks.

Jaotises syscalls loetletakse kõik süsteemikõned ja näidatakse, mida nendega teha. Näiteks saab luua lubatud nimekirja, seadistades defaultAction . Tundub, et SCMP_ACT_ERRNO, ja süsteemikõnedele sektsioonis syscalls andma SCMP_ACT_ALLOW. Niimoodi lubate ainult kõnesid, mis on määratud jaotises syscalls, ja keelate kõik ülejäänud. Musta nimekirja jaoks tuleks väärtused defaultAction ja tegevused vahetada vastupidiseks.

Nüüd tuleks öelda paar sõna nüanssidest, mis ei ole nii ilmsed. Pange tähele, et allpool toodud soovitused lähtuvad sellest, et arendate Kuberneteses ärianalüüse ja on oluline, et need töötaksid võimalikult madalate õigustega.

1. AllowPrivilegeEscalation=false

Uues securityContext konteineril on parameeter AllowPrivilegeEscalation. Kui see on seatud false, käivituvad konteinerid seatud (on) bitiga no_new_priv. Selle parameetri tähendus on ilmselge tema nimest: see ei luba konteineril käivitada uusi protsesse õigustega, mis on suuremad kui tal endal.

Selle parameetri, mis on seatud true vaikimisi väärtusena, kõrvalmõjuks on see, et konteineri käitusaeg rakendab seccomp profiili protsessi käivitamise alguses. Seega peavad kõik süsteemikõned, mis on vajalikud keskkonna sisesüsteemide käivitamiseks (nt kasutaja/grupi identifikaatorite seadmine, mõnede õiguste eemaldamine), olema lubatud profiilis.

Konteiner, mis täidab lihtsat echo hi, vajab järgmisi õigusi:

{
    "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)

… selle asemel,

{
    "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)

Kuid miks see probleem on? Isiklikult vältiksin järgmiste süsteemikutsungite lubamist (kui need ei ole tõeliselt vajalikud): capset, set_tid_address, setgid, setgroups ja setuid. Kuid tegelikult on raskus selles, et lubades protsesse, mida te absoluutselt ei kontrolli, seote te profiilid konteinerite täitmisvõimekuse rakenduste implementeerimisega. Teisisõnu, võite ühel hetkel avastada, et pärast konteineri täitmisvõimekuse värskendamist (kas teie poolt või, mis tõenäolisem, pilveteenuse pakkuja poolt) võivad konteinerid ühel hetkel enam ei käivituda.

Nõuanne nr 1: Käivitage konteinerid väärtusega AllowPrivilegeEscalation=false. See vähendab seccomp'i profiilide suurust ja muudab need keskkonna muutustele vähem tundlikuks.

2. Seccomp'i profiilide määramine konteineri tasemel

Seccomp'i profiili saab määrata pod'i tasemel:

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

… või konteineri tasemel:

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

Pange tähele, et ülaltoodud süntaks muutub, kui Kubernetes seccomp saab GA (see sündmus on oodata juba järgmises Kubernetes'i väljalaskes — 1.18 — tõlkija märkus).

Vähe teada, et Kubernetes'is on alati olnud viga, mille tõttu rakendati seccomp'i profiile pause-konteinerileToimivuskeskkond osaliselt kompenseerib selle puuduse, kuid see konteiner ei kao pod'idest kuhugi, kuna seda kasutatakse nende infrastruktuuri seadistamiseks.

Probleem on selles, et see konteiner käivitatakse alati koos AllowPrivilegeEscalation=true, mis toob kaasa punkti 1-s nimetatud probleemid, ja seda ei saa muuta.

Kasutades seccomp-profiile konteineri tasemel, väldite seda lõkse ja saate luua profiili, mis on „jõhkralt” kohandatud konkreetse konteineri jaoks. Nii tuleb jätkata, kuni arendajad vead parandavad ja uus versioon (võib-olla 1.18?) on kõigile soovijatele saadaval.

Nõuanne nr 2: Määrake seccomp-profiilid konteineri tasemel.

Praktilises mõttes on see reegel tavaliselt universaalne vastus küsimusele: „Miks minu seccomp-profiil töötab koos docker run, kuid ei toimi pärast Kubernetes'e klastrisse juurutamist?".

3. Kasutage runtime/default ainult äärmuslikel juhtudel

Kuberneteses on kaks sisseehitatud profiili varianti: runtime/default ja docker/default. Mõlemad rakendab konteineri täitmise keskkond, mitte Kubernetes. Seetõttu võivad need erineda sõltuvalt kasutatavast täitmise keskkonnast ja selle versioonist.

Teisisõnu, konteineri täitmise keskkonna vahetamise tagajärjel võib konteiner saada juurdepääsu teisele komplektile süsteemikutsest, mida ta võib kasutada või mitte. Enamik täitmise keskkondi kasutab Docker'i implementeerimist.Kui soovite seda profiili kasutada, veenduge, et see sobib teile.

Profiil docker/default peetakse aegunuks alates Kubernetes 1.11-st, seetõttu vältige selle kasutamist.

Minu arvates sobib profiil runtime/default ideaalselt neiteks, milleks see loodi: kaitsta kasutajaid käivitamisega seotud riskide eest docker run oma masinates. Kuid kui rääkida äri rakendustest, mis töötavad Kubernetes'e klastrites, siis julgeksin väita, et selline profiil on liiga avatud ja arendajad peaksid keskenduma oma rakendustele (või rakenduste tüüpidele) kohandatud profiilide loomisele.

Nõuanne nr 3: Looge seccomp-profiilid konkreetsete rakenduste jaoks. Kui see pole võimalik, tegelege rakenduste liikide profiilidega, näiteks looge ulatuslik profiil, mis hõlmab kõiki Golangi rakenduse veeb-API-sid. Kasutage runtime/default vaid viimase võimalusena.

Tulevastes publikatsioonides räägin, kuidas luua seccomp profiile SecDevOps vaimus, automatiseerida ja testida neid torustikes. Teisisõnu, teil ei jää muud valikut, kui liikuda konkreetselt rakenduste jaoks mõeldud profiilide kasutamisele.

4. Unconfined — see EI OLE valik

Kuna esimesest Kubernetes’i turbeauditi selgus, et vaikimisi seccomp on välja lülitatud. See tähendab, et kui te ei määra PodSecurityPolicy, mis aktiveerib selle klastris, töötavad kõik pod'id, millele seccomp profiili ei ole määratud, režiimis seccomp=unconfined.

Töötamine sellises režiimis tähendab, et kogu isoleerimise kiht, mis tagab klastrikaitse, kaob. Sellist lähenemist ei soovita turbeeksperdid.

Nõuanne №4: Ükski konteiner klastris ei tohiks töötada režiimis seccomp=unconfined, eriti tootmiskeskkondades.

5. „Auditirežiim“

See punkt ei ole unikaalne Kubernetes’ile, kuid kuulub siiski kategooriasse „mida tuleks teada enne alustamist“.

On kujunenud, et seccomp profiilide loomine on alati olnud keeruline tegevus ning selles on suures osas tuginedud katse-eksitusmeetodile. Asi on selles, et kasutajatel pole lihtsalt võimalust neid tootmis keskkondades testida, kartmata rakenduse „maha kukutamist“.

Linuxi 4.14 koodi ilmus võimalus käivitada profiili osi auditi režiimis, salvestades syslog'i teavet kõigi süsteemikutsude kohta, kuid neid ei blokeerita. Selle režiimi saab aktiveerida parameetriga SCMT_ACT_LOG:

SCMP_ACT_LOG: seccomp ei mõjuta süsteemikutsu ja tööd, kui see ei kuulu alla mingisse reegli filtrisse, kuid süsteemikutsumise teave kantakse ajaloosse.

Siin on tüüpiline strateegia selle võimaluse kasutamiseks:

1. Luba vajalikud süsteemikutsed.
2. Blokeeri süsteemikutsed, mille kohta on teada, et need ei ole vajalikud.
3. Salvesta teave kõigi teiste kutsude kohta ajaloos.

Lihtne näide näeb välja järgmine:

{
    "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)

Kuidagi pidage meeles, et kõik kutsed, mille kohta on teada, et neid ei kasutata ja mis võivad potentsiaalselt klastrile kahju teha, tuleb blokeerida. Hea alus nimekirja koostamiseks on ametlik Docker dokumentatsioon. Seal selgitatakse üksikasjalikult, millised süsteemikutsed on vaikeprofiilis blokeeritud ja miks.

Siiski on üks nüanss. Kuigi SCMT_ACT_LOG on Linuxi tuuma poolt toetatud alates 2017. aastast, on see Kubernetes'e ökosüsteemi jõudnud alles suhteliselt hiljuti. Seetõttu vajate selle meetodi kasutamiseks Linuxi tuuma versiooni 4.14 ja runC versiooni mitte madalamat kui v1.0.0-rc9.

Nõuanne nr 5: Audit režiimi profiil, et testida tootmises, saab luua mustade ja valgete loendite kombinatsiooni teel ning kõik erandid tuleks logida.

6. Kasutage valgeid loendeid

Valgete loendite koostamine nõuab täiendavaid jõupingutusi, kuna tuleb tuvastada iga kutsung, mis võib rakendusele vajalik olla, kuid see lähenemine suurendab oluliselt turvalisust:

Soovitatav on kasutada valgeliste lähenemist, kuna see on lihtsam ja usaldusväärsem. Musta nimekirja tuleb värskendada iga kord, kui lisatakse potentsiaalselt ohtlik süsteemikutsung (või ohtlik lipp/valik, kui need on mustas nimekirjas). Lisaks saab sageli muuta parameetri esitusviisi, muutmata selle sisu ja seeläbi ületada musta nimekirja piiranguid.

Go keeles rakenduste jaoks olen välja töötanud spetsiaalse tööriista, mis jälgib rakendust ja kogub kõik kutsed, mis teostati täitmise ajal. Näiteks järgmise rakenduse jaoks:

package main

import "fmt"

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

… käivitame gosystract nii:

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

… ja saame järgmise tulemuse:

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

Praegu on see lihtsalt näide – tööriistade üksikasjad tulevad hiljem.

Nõuanne nr 6: Luba ainult need kutsed, mis on tõeliselt vajalikud, ja blokeeri kõik teised.

7. Pane paika õiged alused (või ole valmis ettearvamatuks käitumiseks)

Tuuma jälgib profiili järgimist, sõltumata sellest, mida sa seal määranud oled. Isegi kui see pole täpselt see, mida soovid. Näiteks kui blokeerida ligipääs sellistele kutsungitele nagu exit või exit_group, ei suuda konteiner korralikult sulgeda ja isegi lihtne käsk nagu echo hi peatub sellejuhul määramatuks ajaks. Tulemuseks on kõrge CPU koormus klastris:

Sellistel juhtudel võib appi tulla utiliit strace – see näitab, milles võib probleem olla:

sudo strace -c -p 9331

Veenduge, et profiilid sisaldavad kõiki süsteemikutsungite, mida rakendus vajab töötamise ajal.

Nõuanne nr 7: Ole tähelepanelik detailide suhtes ja kontrolli, et kõik vajalikud süsteemikutsungid on lubatud.

Selle esimene osa artiklite tsüklist seccomp'i kasutamisest Kuberneteses, vaimus SecDevOps lõpeb. Järgmistes osades räägime, miks see on oluline ja kuidas automatiseerida protsessi.

P.S. tõlkijalt

Lugege ka meie blogist:

• «Dockeri konteinerite turvalisus»;
• «33+ Kubernetesi turvalisuse tööriista»;
• «Docker ja Kubernetes turvalisust nõudvates keskkondades»;
• «9 parimat praktikat Kubernetes'e turvalisuse tagamiseks».

Allikas: habr.com