Nota. transl.: Presentemu à a vostra attenzione a traduzzione di un articulu da un ingegnere senior di sicurezza di l'applicazioni in a cumpagnia britannica ASOS.com. Cun ella, principia una seria di publicazioni dedicate à migliurà a sicurità in Kubernetes per mezu di l'usu di seccomp. Se i lettori piace l'intruduzione, seguiteremu l'autore è cuntinuemu cù i so futuri materiali nantu à questu tema.
Questu articulu hè u primu in una seria di posti nantu à cumu creà profili seccomp in u spiritu di SecDevOps, senza ricorrere à a magia è a stregoneria. In a Parte 1, copreraghju i principii è i dettagli interni di l'implementazione di seccomp in Kubernetes.
L'ecosistema Kubernetes offre una larga varietà di modi per assicurà è isolà i cuntenituri. L'articulu hè nantu à u Modu Secure Computing, cunnisciutu ancu seccomp. A so essenza hè di filtrà e chjama di u sistema dispunibuli per l'esekzione da cuntenituri.
Perchè hè impurtante? Un containeru hè solu un prucessu in esecuzione nantu à una macchina specifica. È usa u kernel cum'è altre applicazioni. Se i cuntenituri puderanu eseguisce qualsiasi chjama di u sistema, assai prestu u malware apprufittassi di questu per scaccià l'isolamentu di u containeru è affettà altre applicazioni: intercepte l'infurmazioni, cambià i paràmetri di u sistema, etc.
I profili seccomp definenu quale chjama di u sistema deve esse permessa o disattivata. U cuntainer runtime li attiva quandu principia per chì u kernel pò monitorà a so esecuzione. Utilizà tali profili permette di limità u vettore d'attaccu è riduce u dannu se qualsiasi prugramma in u cuntinuu (vale à dì, e vostre dipendenze, o e so dipendenze) cumencia à fà qualcosa chì ùn hè micca permessu di fà.
Arrivà à i principii
U prufilu di basa di seccomp include trè elementi: defaultAction, architectures (o 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"
}
]
}()
defaultAction determina u destinu predeterminatu di qualsiasi chjama di u sistema micca specificatu in a sezione syscalls. Per fà e cose più faciule, fighjemu nantu à i dui valori principali chì seranu utilizati:
-
SCMP_ACT_ERRNO- blucca l'esekzione di una chjama di u sistema, -
SCMP_ACT_ALLOW- permette.
rùbbrica architectures architetture di destinazione sò listate. Questu hè impurtante perchè u filtru stessu, appiicatu à u nivellu di u kernel, dipende di l'identificatori di u sistema, è micca di i so nomi specificati in u prufilu. U runtime di u containeru li currisponde à l'identificatori prima di l'usu. L'idea hè chì e chjama di u sistema ponu avè ID completamente differenti secondu l'architettura di u sistema. Per esempiu, u sistema chjamatu recvfrom (adupratu per riceve infurmazioni da u socket) hà ID = 64 in sistemi x64 è ID = 517 in x86. pudete truvà una lista di tutte e chjama di u sistema per l'architettura x86-x64.
In a rùbbrica syscalls elenca tutte e chjama di u sistema è specifica ciò chì deve fà cun elli. Per esempiu, pudete creà una lista bianca da mette defaultAction nantu SCMP_ACT_ERRNO, è chjama in a rùbbrica syscalls assignà SCMP_ACT_ALLOW. Cusì, permette solu chjamati specificati in a sezione syscalls, è pruibisce tutti l'altri. Per a lista negra, duvete cambià i valori defaultAction è azzione à u cuntrariu.
Avà duvemu dì uni pochi di parolle nantu à sfumature chì ùn sò micca cusì evidenti. Per piacè nutate chì i cunsiglii quì sottu assumenu chì site implementà una linea di applicazioni di cummerciale nantu à Kubernetes è vulete ch'elli vanu cù u minimu quantità di privilegi pussibule.
1. AllowPrivilegeEscalation=false
В securityContext cuntainer hà un paràmetru AllowPrivilegeEscalation. S'ellu hè stallatu in false, i cuntenituri cumincianu cù (on) pocu . U significatu di stu paràmetru hè ovviamente da u nome: impedisce à u cuntinuu di lancià novi prucessi cù più privilegii di quellu stessu.
Un effettu secundariu di sta opzione hè stata stabilita true (default) hè chì u cuntainer runtime applicà u prufilu seccomp à u principiu di u prucessu di startup. Cusì, tutte e chjama di u sistema necessariu per eseguisce i prucessi di runtime internu (per esempiu, stabilisce l'ID d'utilizatori / gruppu, abbandunà certe capacità) deve esse attivatu in u prufilu.
À un cuntainer chì faci cose triviali echo hi, i seguenti permessi seranu richiesti:
{
"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"
}
]
}()
... invece di questi:
{
"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"
}
]
}()
Ma dinò, perchè hè questu un prublema? In modu persunale, eviteraghju a lista bianca di e seguenti chjamate di u sistema (a menu chì ùn ci hè un veru bisognu di elli): capset, set_tid_address, setgid, setgroups и setuid. Tuttavia, u veru sfida hè chì, permettendu prucessi chì ùn avete assolutamente micca cuntrollu, vi liganu i profili à l'implementazione di u cuntainer runtime. In altri palori, un ghjornu pudete truvà chì dopu avè aghjurnatu l'ambiente di runtime di u containeru (sia da voi, sia, più prubabilmente, da u fornitore di servizii di nuvola), i cuntenituri si fermanu di colpu.
Cunsigliu # 1: Run containers cun AllowPrivilegeEscaltion=false. Questu riducerà a dimensione di i profili seccomp è li rende menu sensibili à i cambiamenti in l'ambiente di runtime di u containeru.
2. Stabbilimentu di profili seccomp à u livellu di u containeru
U prufilu seccomp pò esse stabilitu à u nivellu di pod:
annotations:
seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json"... o à u livellu di u containeru :
annotations:
container.security.alpha.kubernetes.io/<container-name>: "localhost/profile.json"Per piacè nutate chì a sintassi sopra cambierà quandu Kubernetes seccomp (Stu avvenimentu hè previstu in a prossima versione di Kubernetes - 1.18 - approx. transl.).
Pocu persone sanu chì Kubernetes hà sempre avutu chì hà causatu i profili seccomp per esse applicati . L'ambiente di runtime cumpensu parzialmente per questa mancanza, ma questu cuntinuu ùn sparisce micca da i podi, postu chì hè utilizatu per cunfigurà a so infrastruttura.
U prublema hè chì stu cuntinuu sempre principia cù AllowPrivilegeEscalation=true, chì porta à i prublemi espressi in u paràgrafu 1, è questu ùn pò micca esse cambiatu.
Utilizendu i profili seccomp à u livellu di u cuntinuu, eviterete questa trappula è pudete creà un prufilu adattatu à un containeru specificu. Questu duverà esse fattu finu à chì i sviluppatori risolvenu u bug è a nova versione (forse 1.18?) diventa dispunibule per tutti.
Cunsigliu # 2: Definite i profili seccomp à u livellu di u containeru.
In un sensu praticu, sta regula generalmente serve cum'è una risposta universale à a quistione: "Perchè u mo prufilu seccomp funziona cù docker runma ùn funziona micca dopu a distribuzione in un cluster Kubernetes?
3. Aduprate runtime/default solu cum'è l'ultimu risorsu
Kubernetes hà duie opzioni per i profili integrati: runtime/default и docker/default. Tutti dui sò implementati da u cuntainer runtime, micca Kubernetes. Dunque, ponu differisce secondu l'ambiente runtime utilizatu è a so versione.
In altri palori, in u risultatu di u cambiamentu di runtime, u cuntinuu pò avè accessu à un altru settore di chjama di u sistema, chì pò esse o ùn pò micca aduprà. A maiò parte di i runtimes usanu . Se vulete usà stu prufilu, assicuratevi chì hè adattatu per voi.
Profile docker/default hè stata obsoleta da Kubernetes 1.11, cusì evite micca aduprà.
In u mo parè, prufilu runtime/default perfettamente adattatu per u scopu per quale hè statu creatu: prutezzione di l'utilizatori da i risichi assuciati à l'esecuzione di un cumandamentu docker run nantu à e so vitture. In ogni casu, quandu si tratta di l'applicazioni cummerciale in esecuzione nantu à i clusters Kubernetes, mi piacerebbe argumentà chì un tali prufilu hè troppu apertu è i sviluppatori anu da fucalizza nantu à creà profili per e so applicazioni (o tippi d'applicazioni).
Cunsigliu # 3: Crea profili seccomp per applicazioni specifiche. Se ùn hè micca pussibule, create profili per i tipi di applicazione, per esempiu, creanu un prufilu avanzatu chì include tutte l'API web di l'applicazione Golang. Aduprate solu runtime/default cum'è l'ultimu risorsu.
In i posti futuri, copreraghju cumu creà profili seccomp inspirati da SecDevOps, automatizàli è pruvà in pipeline. In altre parolle, ùn avete micca scusa per ùn aghjurnà à profili specifichi di l'applicazione.
4. Unconfined ùn hè micca una opzione.
Da hè risultatu chì per difettu . Questu significa chì sè ùn avete micca stabilitu PodSecurityPolicy, chì permetterà in u cluster, tutti i podi per i quali u prufilu seccomp ùn hè micca definitu travaglià seccomp=unconfined.
Operatu in questu modu significa chì una capa sana d'insulazione hè persa chì prutegge u cluster. Stu approcciu ùn hè micca cunsigliatu da i sperti di sicurità.
Cunsigliu # 4: Nisun cuntainer in u cluster ùn deve esse in esecuzione seccomp=unconfined, in particulare in ambienti di pruduzzione.
5. "Mode Audit"
Stu puntu ùn hè micca unicu à Kubernetes, ma hè sempre in a categuria "cose da sapè prima di principià".
Cum'è succede, a creazione di profili seccomp hè sempre stata sfida è si basa assai in prova è errore. U fattu hè chì l'utilizatori simpricimenti ùn anu micca l'uppurtunità di pruvà in l'ambienti di produzzione senza risicà "lascià" l'applicazione.
Dopu à a liberazione di u kernel Linux 4.14, hè diventatu pussibule di eseguisce parti di un prufilu in modu di auditu, registrandu l'infurmazioni nantu à tutte e chjama di u sistema in syslog, ma senza bluccà. Pudete attivà stu modu cù u paràmetru SCMT_ACT_LOG:
SCMP_ACT_LOG: seccomp ùn affetterà micca u filu chì face a chjama di u sistema s'ellu ùn currisponde à alcuna regula in u filtru, ma l'infurmazione nantu à a chjama di u sistema serà registrata.
Eccu una strategia tipica per aduprà sta funzione:
- Permette e chjama di u sistema chì sò necessarii.
- Block calls da u sistema chì sapete ùn serà micca utile.
- Registra infurmazione nantu à tutte e altre chjama in u log.
Un esempiu simplificatu pare cusì:
{
"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"
}
]
}()
Ma ricordate chì avete bisognu di bluccà tutte e chjama chì sapete chì ùn saranu micca aduprate è chì puderanu dannà u cluster. Una bona basa per a compilazione di una lista hè l'ufficiale . Spiega in dettagliu chì e chjama di u sistema sò bluccati in u prufilu predeterminatu è perchè.
Tuttavia, ci hè una cattura. Eppuru SCMT_ACT_LOG supportatu da u kernel Linux da a fine di u 2017, hè intrutu in l'ecosistema Kubernetes solu pocu pocu tempu. Per quessa, per utilizà stu metudu avete bisognu di un kernel Linux 4.14 è di una versione runC micca più bassa .
Cunsigliu # 5: Un prufilu di modu di auditu per a prova in a produzzione pò esse creatu cumminendu listi neri è bianchi, è tutte l'eccezzioni ponu esse registrate.
6. Aduprà whitelists
A lista bianca richiede un sforzu supplementu perchè duvete identificà ogni chjama chì l'applicazione puderia avè bisognu, ma questu approcciu migliurà assai a sicurità:
Hè assai ricumandemu di utilizà l'approcciu di lista bianca perchè hè più simplice è affidabile. A lista nera deve esse aghjurnata ogni volta chì una chjama di u sistema potenzialmente periculosa (o una bandiera / opzione periculosa si hè in a lista negra) hè aghjuntu. Inoltre, hè spessu pussibule di cambià a rapprisintazioni di un paràmetru senza cambià a so essenza, è cusì sguassate e restrizioni di a lista negra.
Per l'applicazioni Go, aghju sviluppatu un strumentu speciale chì accumpagna l'applicazione è raccoglie tutte e chjamate durante l'esekzione. Per esempiu, per l'applicazione seguente:
package main
import "fmt"
func main() {
fmt.Println("test")
} ... lanciamu gosystract cum'è questa:
go install https://github.com/pjbgf/gosystract
gosystract --template='{{- range . }}{{printf ""%s",n" .Name}}{{- end}}' application-path... è avemu u risultatu seguente:
"sched_yield",
"futex",
"write",
"mmap",
"exit_group",
"madvise",
"rt_sigprocmask",
"getpid",
"gettid",
"tgkill",
"rt_sigaction",
"read",
"getpgrp",
"arch_prctl",Per avà, questu hè solu un esempiu - più dettagli nantu à l'arnesi seguitaranu.
Cunsigliu # 6: Permette solu quelli chjamati chì avete veramente bisognu è bluccà tutti l'altri.
7. Pone i fundamenti ghjusti (o preparate per un cumpurtamentu inespettatu)
U kernel rinfurzà u prufilu indipendentemente da ciò chì scrive in ellu. Ancu s'ellu ùn hè micca esattamente ciò chì vulete. Per esempiu, s'è vo bluccà accessu à chiama cum'è exit o exit_group, u cuntinuu ùn serà micca capaci di chjude currettamente è ancu un cumandamentu simplice cum'è echo hi o per un periodu indefinitu. In u risultatu, uttene un altu usu di CPU in u cluster:
In tali casi, una utilità pò vene à u salvamentu strace - mostrarà ciò chì u prublema pò esse:
sudo strace -c -p 9331
Assicuratevi chì i profili cuntenenu tutte e chjama di u sistema chì l'applicazione necessita in runtime.
Cunsigliu # 7: Prestate attenzione à i dettagli è assicuratevi chì tutte e chjama di u sistema necessariu sò in lista bianca.
Questu cuncludi a prima parte di una seria d'articuli nantu à l'usu di seccomp in Kubernetes in u spiritu di SecDevOps. In i seguenti parti avemu da parlà perchè questu hè impurtante è cumu per automatizà u prucessu.
PS da u traduttore
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «";
- «».
Source: www.habr.com
