Note. iwwersat.: Mir presentéieren Iech d'Iwwersetzung vun engem Artikel vun engem Senior Application Security Engineer bei der britescher Firma ASOS.com. Mat et fänkt hien eng Serie vu Publikatiounen un, gewidmet fir d'Sécherheet zu Kubernetes ze verbesseren duerch d'Benotzung vu seccomp. Wann d'Lieser d'Aféierung gär hunn, wäerte mir den Auteur verfollegen a weider mat sengem zukünftege Material iwwer dëst Thema weiderféieren.
Dësen Artikel ass deen éischten an enger Serie vu Posts iwwer wéi een Seccomp Profiler am Geescht vu SecDevOps erstellt, ouni op Magie an Hexerei ze huelen. Am Deel XNUMX wäert ech d'Basis an d'intern Detailer iwwer d'Ëmsetzung vun seccomp zu Kubernetes ofdecken.
De Kubernetes Ökosystem bitt eng grouss Varietéit vu Weeër fir Container ze sécheren an ze isoléieren. Den Artikel handelt iwwer Secure Computing Mode, och bekannt als secomp. Seng Essenz ass d'System Uruff ze filteren déi verfügbar ass fir Ausféierung vu Container.
Firwat ass et wichteg? E Container ass just e Prozess deen op enger spezifescher Maschinn leeft. An et benotzt de Kernel grad wéi aner Uwendungen. Wann Container all System Uruff kéinte maachen, géif ganz séier Malware dovun profitéieren fir d'Containerisolatioun ëmzegoen an aner Uwendungen ze beaflossen: Informatioun offangen, Systemastellungen änneren, etc.
seccomp Profiler definéieren wéi eng System Uriff soll erlaabt oder behënnert ginn. De Container Runtime aktivéiert se wann et ufänkt, sou datt de Kernel hir Ausféierung iwwerwaache kann. D'Benotzung vun esou Profiler erlaabt Iech den Attackvektor ze limitéieren a Schued ze reduzéieren wann e Programm am Container (dat ass Är Ofhängegkeeten oder hir Ofhängegkeeten) ufänkt eppes ze maachen wat et net erlaabt ass ze maachen.
D'Grondlage verstoen
De Basis Secomp Profil enthält dräi Elementer: defaultAction, architectures (oder archMap) an 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"
}
]
}()
defaultAction bestëmmt d'Default Schicksal vun all System Uruff net an der Rubrik uginn syscalls. Fir d'Saache méi einfach ze maachen, loosst eis op déi zwee Haaptwäerter fokusséieren déi benotzt ginn:
-
SCMP_ACT_ERRNO- blockéiert d'Ausféierung vun engem Systemruff, -
SCMP_ACT_ALLOW- erlaabt.
Sektioun architectures Zilarchitekturen sinn opgezielt. Dëst ass wichteg, well de Filter selwer, deen um Kernelniveau ugewannt gëtt, hänkt vu Systemruffidentifizéierer of, an net vun hiren Nimm, déi am Profil spezifizéiert sinn. D'Container Runtime passt hinnen un Identifizéierer virum Gebrauch. D'Iddi ass datt System Uriff komplett verschidden IDen kënnen hunn ofhängeg vun der Systemarchitektur. Zum Beispill, System Opruff recvfrom (benotzt fir Informatioun aus dem Socket ze kréien) huet ID = 64 op x64 Systemer an ID = 517 op x86. Dir kënnt eng Lëscht vun all System rifft fir x86-x64 Architekturen fannen.
An der Rubrik syscalls Lëscht all System Appellen a spezifizéiert wat mat hinnen ze maachen. Zum Beispill kënnt Dir eng Whitelist erstellen andeems Dir setzt defaultAction op SCMP_ACT_ERRNO, an rifft an der Rubrik syscalls zouzeschreiwen SCMP_ACT_ALLOW. Sou erlaabt Dir nëmmen Uriff an der Rubrik spezifizéiert syscalls, an all aner verbidden. Fir d'Schwaarzlëscht sollt Dir d'Wäerter änneren defaultAction an Aktiounen op de Géigendeel.
Elo solle mir e puer Wierder soen iwwer Nuancen déi net sou evident sinn. Notéiert w.e.g. datt d'Empfehlungen hei drënner ugeholl datt Dir eng Linn vu Geschäftsapplikatiounen op Kubernetes ofsetzt an Dir wëllt datt se mat der mannst méiglech Privilegien lafen.
1. AllowPrivilegeEscalation=falsch
В securityContext Container huet e Parameter AllowPrivilegeEscalation. Wann et installéiert ass false, Container fänken mat (on) bëssen . D'Bedeitung vun dësem Parameter ass offensichtlech vum Numm: et verhënnert datt de Container nei Prozesser mat méi Privilegien lancéiert wéi et selwer huet.
Eng Nebenwirkung vun dëser Optioun gëtt agestallt true (Standard) ass datt d'Container Runtime de seccomp Profil ganz am Ufank vum Startupprozess applizéiert. Also, all System Uruff néideg fir intern Runtime Prozesser ze lafen (zB Benotzer-/Grupp IDs astellen, bestëmmte Fäegkeeten erofzesetzen) mussen am Profil aktivéiert ginn.
Zu engem Container deen trivial Saachen mécht echo hi, sinn déi folgend Permissiounen erfuerderlech:
{
"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"
}
]
}()
... amplaz vun dësen:
{
"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"
}
]
}()
Awer erëm, firwat ass dëst e Problem? Perséinlech géif ech vermeiden déi folgend Systemruffen op Whitelist ze setzen (ausser et gëtt e reelle Bedierfnes fir si): capset, set_tid_address, setgid, setgroups и setuid. Wéi och ëmmer, déi richteg Erausfuerderung ass datt andeems Dir Prozesser erlaabt iwwer déi Dir absolut keng Kontroll hutt, verbënnt Dir Profiler un d'Container Runtime Implementatioun. An anere Wierder, enges Daags kënnt Dir feststellen datt nom Update vum Container Runtime Ëmfeld (entweder vun Iech oder, méi wahrscheinlech, vum Cloud Service Provider), d'Container op eemol ophalen.
Tipp # 1: Laf Container mat AllowPrivilegeEscaltion=false. Dëst wäert d'Gréisst vun de seccomp Profiler reduzéieren an se manner sensibel fir Ännerungen am Container Runtime Ëmfeld maachen.
2. Seccomp Profiler um Container Niveau Kader
De secomp Profil kann um Podniveau gesat ginn:
annotations:
seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json"... oder um Containerniveau:
annotations:
container.security.alpha.kubernetes.io/<container-name>: "localhost/profile.json"Maacht weg datt déi uewe genannte Syntax ännert wann Kubernetes seccomp (Dëst Event gëtt an der nächster Verëffentlechung vu Kubernetes erwaart - 1.18 - ongeféier Iwwersetzung).
Puer Leit wëssen, datt Kubernetes ëmmer haten déi verursaacht secomp Profiler applizéiert ginn . D'Runtime-Ëmfeld kompenséiert deelweis fir dësen Defizit, awer dëse Container verschwënnt net aus de Pods, well et benotzt gëtt fir hir Infrastruktur ze konfiguréieren.
De Problem ass, datt dëst Container ëmmer fänkt mat AllowPrivilegeEscalation=true, déi zu de Problemer, déi am Paragraf 1 gestëmmt sinn, féieren, an dëst kann net geännert ginn.
Andeems Dir seccomp Profiler um Containerniveau benotzt, vermeit Dir dëse Fall a kënnt e Profil erstellen deen op e spezifesche Container ugepasst ass. Dëst muss gemaach ginn bis d'Entwéckler de Feeler fixen an déi nei Versioun (vläicht 1.18?) fir jiddereen verfügbar ass.
Tipp # 2: Set secomp Profiler um Container Niveau.
An engem praktesche Sënn déngt dës Regel normalerweis als eng universell Äntwert op d'Fro: "Firwat funktionnéiert mäi Seccomp Profil mat docker runawer funktionnéiert net nom Ofbau op e Kubernetes Cluster?
3. Benotzt Runtime / Standard nëmmen als leschten Auswee
Kubernetes huet zwou Méiglechkeeten fir agebaute Profiler: runtime/default и docker/default. Béid gi vun der Container Runtime implementéiert, net Kubernetes. Dofir kënne se ënnerscheeden ofhängeg vum benotzte Runtime Ëmfeld a senger Versioun.
An anere Wierder, als Resultat vun der Ännerung vun der Runtime, kann de Container Zougang zu engem anere Set vu Systemruffen hunn, déi et ka benotzen oder net. Déi meescht Runtime benotzen . Wann Dir dëse Profil benotze wëllt, gitt sécher datt et fir Iech gëeegent ass.
Profil docker/default gouf zënter Kubernetes 1.11 ofgeschaaft, also vermeit se ze benotzen.
Menger Meenung no, Profil runtime/default perfekt gëeegent fir den Zweck fir deen et erstallt gouf: d'Benotzer schützen géint de Risiken verbonne mat der Ausféierung vun engem Kommando docker run op hiren Autoen. Wéi och ëmmer, wann et ëm d'Geschäftsapplikatioune geet, déi op Kubernetes Cluster lafen, géif ech trauen ze streiden datt esou e Profil ze oppen ass an d'Entwéckler sech op d'Schafe vu Profiler fir hir Applikatiounen (oder Aarte vun Applikatiounen) solle fokusséieren.
Tipp # 3: Erstellt secomp Profiler fir spezifesch Uwendungen. Wann dat net méiglech ass, erstellt Profiler fir Applikatiounstypen, zum Beispill, erstellt en fortgeschrattene Profil deen all d'Web APIen vun der Golang Applikatioun enthält. Benotzt nëmmen Runtime / Standard als leschten Auswee.
An zukünfteg Posts wäert ech iwwerdecken wéi SecDevOps-inspiréiert seccomp Profiler erstellen, se automatiséieren an se a Pipelines testen. An anere Wierder, Dir hutt keng Excuse fir net op Applikatiounsspezifesch Profiler ze upgrade.
4. Unconfined ass NET eng Optioun.
Vun et huet sech erausgestallt, datt Par défaut . Dëst bedeit datt wann Dir net setzt PodSecurityPolicy, wat et am Cluster aktivéiert, all Pods fir déi de seccomp Profil net definéiert ass funktionnéieren an seccomp=unconfined.
D'Operatioun an dësem Modus bedeit datt eng ganz Schicht vun Isolatioun verluer ass, déi de Stärekoup schützt. Dës Approche gëtt net vu Sécherheetsexperten recommandéiert.
Tipp # 4: Kee Container am Stärekoup soll eran lafen seccomp=unconfined, besonnesch an Produktioun Ëmfeld.
5. "Audit Modus"
Dëse Punkt ass net eenzegaarteg fir Kubernetes, awer fällt nach ëmmer an d'Kategorie "Saachen ze wëssen ier Dir ufänkt".
Wéi et geschitt, Seccomp Profiler erstellen war ëmmer Erausfuerderung a hänkt staark op Versuch a Feeler of. D'Tatsaach ass datt d'Benotzer einfach net d'Méiglechkeet hunn se a Produktiounsëmfeld ze testen ouni d'Applikatioun ze riskéieren ze "droen".
No der Verëffentlechung vum Linux Kernel 4.14 gouf et méiglech Deeler vun engem Profil am Auditmodus auszeféieren, Informatioun iwwer all Systemappellen am Syslog opzehuelen, awer ouni se ze blockéieren. Dir kënnt dëse Modus mat dem Parameter aktivéieren SCMT_ACT_LOG:
SCMP_ACT_LOG: seccomp beaflosst net de Fuedem deen de System Uruff mécht wann et keng Regel am Filter entsprécht, awer Informatioun iwwer de System Uruff gëtt protokolléiert.
Hei ass eng typesch Strategie fir dës Feature ze benotzen:
- Erlaabt System Uriff déi néideg sinn.
- Block Uriff vum System, deen Dir wësst, wäert net nëtzlech sinn.
- Notéiert Informatiounen iwwer all aner Uriff am Logbuch.
E vereinfacht Beispill gesäit esou aus:
{
"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"
}
]
}()
Awer denkt drun datt Dir all Uruff blockéiere musst, déi Dir wësst net benotzt ginn an déi potenziell de Stärekoup schuede kënnen. Eng gutt Basis fir eng Lëscht opzestellen ass déi offiziell . Et erkläert am Detail wéi eng Systemriff am Standardprofil blockéiert sinn a firwat.
Allerdéngs gëtt et ee Fang. Obwuel SCMT_ACT_LOG ënnerstëtzt vum Linux Kernel zënter Enn 2017, ass et an de Kubernetes Ökosystem eréischt relativ viru kuerzem agaangen. Dofir, fir dës Method ze benotzen, brauch Dir e Linux Kernel 4.14 a runC Versioun net méi niddereg .
Tipp # 5: En Audit Modus Profil fir Testen an Produktioun kann duerch eng Kombinatioun vun schwaarz a wäiss Lëschte geschaf ginn, an all Ausnahmen kann aloggen ginn.
6. Benotzt Whitelists
Whitelisting erfuerdert zousätzlech Effort, well Dir musst all Uruff identifizéieren, deen d'Applikatioun brauch, awer dës Approche verbessert d'Sécherheet staark:
Et ass héich recommandéiert d'Whitelist Approche ze benotzen well et méi einfach a méi zouverlässeg ass. D'Schwaarzlëscht muss aktualiséiert ginn wann e potenziell geféierleche Systemruff (oder e geféierleche Fändel / Optioun wann et op der Schwaarzlëscht ass) bäigefüügt gëtt. Zousätzlech ass et dacks méiglech d'Representatioun vun engem Parameter z'änneren ouni seng Essenz z'änneren an doduerch d'Restriktiounen vun der Blacklist ëmzegoen.
Fir Go Uwendungen hunn ech e speziellen Tool entwéckelt deen d'Applikatioun begleet an all Uruff sammelt, déi während der Ausféierung gemaach goufen. Zum Beispill, fir déi folgend Applikatioun:
package main
import "fmt"
func main() {
fmt.Println("test")
}
... loosst eis starten gosystract sou:
go install https://github.com/pjbgf/gosystract
gosystract --template='{{- range . }}{{printf ""%s",n" .Name}}{{- end}}' application-path... a mir kréien folgend Resultat:
"sched_yield",
"futex",
"write",
"mmap",
"exit_group",
"madvise",
"rt_sigprocmask",
"getpid",
"gettid",
"tgkill",
"rt_sigaction",
"read",
"getpgrp",
"arch_prctl",Fir de Moment ass dëst just e Beispill - méi Detailer iwwer d'Tools wäerte verfollegen.
Tipp # 6: Erlaabt nëmmen déi Uriff déi Dir wierklech braucht a blockéiert all déi aner.
7. Déi richteg Fundamenter leeën (oder op onerwaart Verhalen virbereeden)
De Kärel wäert de Profil duerchsetzen egal wat Dir dran schreift. Och wann et net genau ass wat Dir wollt. Zum Beispill, wann Dir den Zougang zu Uriff blockéiert wéi exit oder exit_group, de Container wäert net fäeg sinn richteg auszeschalten a souguer en einfache Kommando wéi echo hi o fir eng onbestëmmten Zäit. Als Resultat kritt Dir héich CPU Notzung am Cluster:
An esou Fäll kann en Utility zur Rettung kommen strace - et wäert weisen wat de Problem ka sinn:
sudo strace -c -p 9331
Vergewëssert Iech datt d'Profiler all d'Systemappellen enthalen déi d'Applikatioun während der Runtime brauch.
Tipp # 7: Opgepasst op Detailer a gitt sécher datt all néideg Systemappellen op d'Whitelist sinn.
Dëst schléisst den éischten Deel vun enger Serie vun Artikelen iwwer d'Benotzung vu seccomp a Kubernetes am Geescht vu SecDevOps of. An de folgenden Deeler wäerte mir schwätzen iwwer firwat dëst wichteg ass a wéi de Prozess automatiséiert.
PS vum Iwwersetzer
Liest och op eisem Blog:
- «";
- «";
- «";
- «".
Source: will.com