Seccom sa Kubernetes: 7 nga mga butang nga kinahanglan nimong mahibal-an gikan sa sinugdanan

Nota. transl.: Gipresentar namo sa imong pagtagad ang paghubad sa usa ka artikulo sa usa ka senior application security engineer sa British nga kompanya nga ASOS.com. Uban niini, nagsugod siya usa ka serye sa mga publikasyon nga gipahinungod sa pagpauswag sa seguridad sa Kubernetes pinaagi sa paggamit sa seccom. Kung gusto sa mga magbabasa ang pasiuna, sundon namon ang tagsulat ug magpadayon sa iyang umaabot nga mga materyal sa kini nga hilisgutan.

Seccom sa Kubernetes: 7 nga mga butang nga kinahanglan nimong mahibal-an gikan sa sinugdanan

Kini nga artikulo mao ang una sa sunod-sunod nga mga post kung giunsa paghimo ang mga profile sa seccom sa diwa sa SecDevOps, nga wala mogamit sa salamangka ug salamangka. Sa Bahin XNUMX, akong tabonan ang mga sukaranan ug internal nga mga detalye sa pagpatuman sa seccom sa Kubernetes.

Ang ecosystem sa Kubernetes nagtanyag og lain-laing mga paagi sa pag-secure ug pag-isolate sa mga sudlanan. Ang artikulo bahin sa Secure Computing Mode, nailhan usab nga seccom. Ang esensya niini mao ang pagsala sa mga tawag sa sistema nga magamit alang sa pagpatuman sa mga sudlanan.

Nganong importante kini? Ang usa ka sudlanan usa lamang ka proseso nga nagdagan sa usa ka piho nga makina. Ug kini naggamit sa kernel sama sa ubang mga aplikasyon. Kung ang mga sudlanan makahimo sa bisan unsang mga tawag sa sistema, sa dili madugay mapahimuslan kini sa malware aron malaktawan ang pagkalainlain sa sulud ug makaapekto sa ubang mga aplikasyon: pag-intercept sa impormasyon, pagbag-o sa mga setting sa sistema, ug uban pa.

Ang mga profile sa seccom nagtino kung unsang mga tawag sa sistema ang kinahanglan tugutan o dili pag-disable. Ang container runtime nagpalihok kanila sa diha nga kini magsugod aron ang kernel makamonitor sa ilang pagpatuman. Ang paggamit sa ingon nga mga profile nagtugot kanimo nga limitahan ang vector sa pag-atake ug makunhuran ang kadaot kung adunay bisan unsang programa sa sulod sa sudlanan (nga mao, ang imong mga dependency, o ang ilang mga dependency) magsugod sa pagbuhat sa usa ka butang nga dili gitugotan nga buhaton.

Pagsabot sa mga sukaranan

Ang sukaranan nga profile sa seccom naglakip sa tulo ka mga elemento: defaultAction, architectures (o archMap) ug 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-seccom.json)

defaultAction nagtino sa default nga kapalaran sa bisan unsang tawag sa sistema nga wala gipiho sa seksyon syscalls. Aron mapasayon ​​ang mga butang, ipunting nato ang duha ka nag-unang mga bili nga gamiton:

  • SCMP_ACT_ERRNO - gibabagan ang pagpatuman sa usa ka tawag sa sistema,
  • SCMP_ACT_ALLOW - nagtugot.

seksyon architectures gilista ang mga target nga arkitektura. Importante kini tungod kay ang filter mismo, nga gigamit sa lebel sa kernel, nagdepende sa mga identifier sa tawag sa sistema, ug dili sa ilang mga ngalan nga gipiho sa profile. Ang container runtime motakdo kanila sa mga identifier sa dili pa gamiton. Ang ideya mao nga ang mga tawag sa sistema mahimong adunay hingpit nga lainlaing mga ID depende sa arkitektura sa sistema. Pananglitan, ang tawag sa sistema recvfrom (nga gigamit sa pagdawat sa impormasyon gikan sa socket) adunay ID = 64 sa x64 sistema ug ID = 517 sa x86. kini mao ang makit-an nimo ang usa ka lista sa tanan nga mga tawag sa sistema alang sa x86-x64 nga mga arkitektura.

Sa seksyon syscalls naglista sa tanan nga mga tawag sa sistema ug nagtino kung unsa ang buhaton niini. Pananglitan, makahimo ka og whitelist pinaagi sa pag-set defaultAction sa SCMP_ACT_ERRNO, ug mga tawag sa seksyon syscalls assign SCMP_ACT_ALLOW. Sa ingon, gitugotan nimo ang mga tawag nga gitakda sa seksyon syscalls, ug idili ang tanan nga uban pa. Alang sa blacklist kinahanglan nimo nga usbon ang mga kantidad defaultAction ug mga aksyon sa atbang.

Karon kinahanglan naton isulti ang pipila ka mga pulong bahin sa mga nuances nga dili kaayo klaro. Palihug timan-i nga ang mga rekomendasyon sa ubos nagtuo nga nag-deploy ka usa ka linya sa mga aplikasyon sa negosyo sa Kubernetes ug gusto nimo nga kini modagan nga adunay labing gamay nga kantidad nga posible nga mga pribilehiyo.

1. AllowPrivilegeEscalation=false

В securityContext Ang sudlanan adunay parameter AllowPrivilegeEscalation. Kung kini na-install sa false, ang mga sudlanan magsugod sa (on) gamay no_new_priv. Ang kahulogan sa kini nga parameter klaro gikan sa ngalan: gipugngan niini ang sudlanan gikan sa paglansad sa mga bag-ong proseso nga adunay daghang mga pribilehiyo kaysa kini mismo.

Usa ka side effect niini nga opsyon nga gitakda sa true (default) mao nga ang container runtime magamit ang seccom profile sa sinugdanan sa proseso sa pagsugod. Sa ingon, ang tanan nga mga tawag sa sistema nga gikinahanglan sa pagpadagan sa internal nga mga proseso sa runtime (pananglitan ang pagbutang sa mga ID sa user/grupo, pagtangtang sa pipila ka mga kapabilidad) kinahanglan nga magamit sa profile.

Ngadto sa usa ka sudlanan nga naghimo sa mga butang nga walay hinungdan echo hi, ang mosunod nga mga pagtugot gikinahanglan:

{
    "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-seccom.json)

...imbes niini:

{
    "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-seccom.json)

Apan pag-usab, nganong kini usa ka problema? Sa personal, likayan nako ang pag-whitelist sa mosunod nga mga tawag sa sistema (gawas kung adunay tinuod nga panginahanglan alang kanila): capset, set_tid_address, setgid, setgroups и setuid. Bisan pa, ang tinuud nga hagit mao nga pinaagi sa pagtugot sa mga proseso nga wala nimo kontrolado, imong gihigot ang mga profile sa pagpatuman sa runtime sa container. Sa laing pagkasulti, usa ka adlaw mahimo nimong makita nga pagkahuman sa pag-update sa container runtime environment (bisan pinaagi kanimo o, lagmit, sa cloud service provider), ang mga sudlanan kalit nga mihunong sa pagdagan.

Tip # 1: Pagdalag mga sudlanan nga adunay AllowPrivilegeEscaltion=false. Kini makapakunhod sa gidak-on sa mga profile sa seccom ug maghimo kanila nga dili kaayo sensitibo sa mga kausaban sa container runtime environment.

2. Pagbutang sa mga profile sa seccom sa lebel sa sudlanan

Ang profile sa seccom mahimong ibutang sa lebel sa pod:

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

...o sa lebel sa sudlanan:

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

Palihug timan-i nga ang syntax sa ibabaw mausab kung ang Kubernetes seccomp mahimong GA (kini nga panghitabo gilauman sa sunod nga pagpagawas sa Kubernetes - 1.18 - gibanabana nga transl.).

Pipila ka mga tawo ang nahibal-an nga kanunay adunay Kubernetes bugnga hinungdan nga ang mga profile sa seccom magamit sa paghunong sa sudlanan. Ang runtime nga palibot partially compensate alang niini nga kakulangan, apan kini nga sudlanan dili mawala gikan sa pods, tungod kay kini gigamit sa pag-configure sa ilang mga imprastraktura.

Ang problema mao nga kini nga sudlanan kanunay nagsugod sa AllowPrivilegeEscalation=true, nga motultol sa mga problema nga gipahayag sa parapo 1, ug kini dili mausab.

Pinaagi sa paggamit sa mga profile sa seccomp sa lebel sa sudlanan, malikayan nimo kini nga lit-ag ug makahimo usa ka profile nga gipahaum sa usa ka piho nga sudlanan. Kinahanglang buhaton kini hangtod nga ayohon sa mga developer ang bug ug ang bag-ong bersyon (tingali 1.18?) mahimong magamit sa tanan.

Tip # 2: Ibutang ang mga profile sa seccom sa lebel sa sudlanan.

Sa praktikal nga diwa, kini nga lagda kasagaran nagsilbing usa ka unibersal nga tubag sa pangutana: "Ngano nga ang akong seccom profile nagtrabaho sa docker runapan dili molihok human sa pag-deploy sa usa ka Kubernetes cluster?

3. Gamita ang runtime/default lamang isip kataposang paagi

Ang Kubernetes adunay duha ka kapilian alang sa mga built-in nga profile: runtime/default и docker/default. Ang duha gipatuman sa container runtime, dili sa Kubernetes. Busa, sila mahimong magkalainlain depende sa runtime nga palibot nga gigamit ug ang bersyon niini.

Sa laing pagkasulti, isip usa ka resulta sa pagbag-o sa runtime, ang sudlanan mahimong adunay access sa lain nga hugpong sa mga tawag sa sistema, nga mahimo o dili gamiton. Kadaghanan sa mga runtime gigamit Implementasyon sa Docker. Kung gusto nimo gamiton kini nga profile, palihug siguroha nga kini angay alang kanimo.

Профиль docker/default wala na gamita sukad sa Kubernetes 1.11, busa likayi ang paggamit niini.

Sa akong hunahuna, profile runtime/default hingpit nga haum alang sa katuyoan diin kini gimugna: pagpanalipod sa mga tiggamit gikan sa mga risgo nga nalangkit sa pagpatuman sa usa ka sugo docker run sa ilang mga sakyanan. Bisan pa, kung bahin sa mga aplikasyon sa negosyo nga nagdagan sa mga kumpol sa Kubernetes, mangahas ako nga makiglalis nga ang ingon nga profile bukas kaayo ug ang mga developer kinahanglan nga magpunting sa paghimo og mga profile alang sa ilang mga aplikasyon (o mga tipo sa aplikasyon).

Tip # 3: Paghimo og mga profile sa seccom para sa piho nga mga aplikasyon. Kung dili kini mahimo, paghimo og mga profile alang sa mga tipo sa aplikasyon, pananglitan, paghimo usa ka advanced profile nga naglakip sa tanan nga mga web API sa aplikasyon sa Golang. Gamita lang ang runtime/default isip kataposang paagi.

Sa umaabot nga mga post, tabonan nako kung giunsa paghimo ang mga profile sa seccomp nga dinasig sa SecDevOps, i-automate kini, ug sulayan kini sa mga pipeline. Sa laing pagkasulti, wala ka'y ​​hinungdan nga dili mag-upgrade sa mga profile nga piho sa aplikasyon.

4. Ang dili ma-confined DILI kapilian.

Gikan unang Kubernetes security audit kini nahimo nga pinaagi sa default seccom disabled. Kini nagpasabot nga kung dili nimo ibutang PodSecurityPolicy, nga makapahimo niini sa cluster, ang tanan nga mga pod diin ang profile sa seccom wala gihubit magamit seccomp=unconfined.

Ang pag-opera niini nga mode nagpasabot nga ang tibuok layer sa insulasyon nawala nga nanalipod sa cluster. Kini nga pamaagi wala girekomenda sa mga eksperto sa seguridad.

Tip # 4: Walay sudlanan sa cluster ang kinahanglang mosulod seccomp=unconfined, labi na sa mga palibot sa produksiyon.

5. "Mode sa pag-audit"

Kini nga punto dili talagsaon sa Kubernetes, apan nahulog gihapon sa kategorya nga "mga butang nga mahibal-an sa dili ka pa magsugod".

Ingon nga kini mahitabo, ang paghimo sa mga profile sa seccom kanunay nga mahagiton ug nagsalig pag-ayo sa pagsulay ug sayup. Ang tinuod mao nga ang mga tiggamit wala’y higayon nga sulayan sila sa mga palibot sa produksiyon nga wala’y peligro nga "ihulog" ang aplikasyon.

Pagkahuman sa pagpagawas sa Linux kernel 4.14, nahimo’g posible ang pagpadagan sa mga bahin sa usa ka profile sa mode sa pag-audit, pagrekord sa kasayuran bahin sa tanan nga mga tawag sa sistema sa syslog, apan nga wala kini gibabagan. Mahimo nimong ma-aktibo kini nga mode gamit ang parameter SCMT_ACT_LOG:

SCMP_ACT_LOG: Ang seccom dili makaapekto sa hilo nga naghimo sa sistema sa tawag kung kini dili motakdo sa bisan unsang lagda sa filter, apan ang impormasyon mahitungod sa sistema sa tawag ma-log.

Ania ang usa ka tipikal nga estratehiya sa paggamit niini nga bahin:

  1. Tugoti ang mga tawag sa sistema nga gikinahanglan.
  2. I-block ang mga tawag gikan sa sistema nga nahibal-an nimo nga dili magamit.
  3. Irekord ang kasayuran bahin sa tanan nga ubang mga tawag sa log.

Ang usa ka gipasimple nga pananglitan ingon niini:

{
    "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-seccom.json)

Apan hinumdomi nga kinahanglan nimo nga babagan ang tanan nga mga tawag nga nahibal-an nimo nga dili magamit ug mahimo’g makadaot sa cluster. Ang usa ka maayong basehan sa pag-compile og listahan mao ang opisyal Dokumentasyon sa Docker. Gipatin-aw niini sa detalye kung unsang mga tawag sa sistema ang gibabagan sa default nga profile ug ngano.

Bisan pa, adunay usa nga nakuha. Bisan pa SCMT_ACT_LOG gisuportahan sa Linux kernel sukad sa katapusan sa 2017, kini misulod sa Kubernetes ecosystem bag-o lang. Busa, aron magamit kini nga pamaagi kinahanglan nimo ang usa ka Linux kernel 4.14 ug runC nga bersyon nga dili ubos v1.0.0-rc9.

Tip # 5: Ang profile sa audit mode para sa pagsulay sa produksiyon mahimong mamugna pinaagi sa paghiusa sa itom ug puti nga mga lista, ug ang tanang eksepsiyon mahimong ma-log.

6. Gamita ang mga whitelist

Ang pag-whitelist nanginahanglan dugang nga paningkamot tungod kay kinahanglan nimo nga mailhan ang matag tawag nga mahimo’g kinahanglan sa aplikasyon, apan kini nga pamaagi labi nga nagpauswag sa seguridad:

Girekomendar kaayo nga gamiton ang whitelist approach kay mas simple ug mas kasaligan. Ang blacklist kinahanglan nga i-update sa matag higayon nga ang usa ka posible nga peligro nga tawag sa sistema (o usa ka peligro nga bandila / kapilian kung kini naa sa blacklist) idugang. Dugang pa, kanunay nga posible nga usbon ang representasyon sa usa ka parameter nga dili usbon ang esensya niini ug sa ingon makalikay sa mga pagdili sa blacklist.

Alang sa mga aplikasyon sa Go, naghimo ako usa ka espesyal nga himan nga nag-uban sa aplikasyon ug gikolekta ang tanan nga mga tawag nga gihimo sa panahon sa pagpatuman. Pananglitan, alang sa mosunod nga aplikasyon:

package main

import "fmt"

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

... maglansad ta gosystract busa:

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

... ug makuha namo ang mosunod nga resulta:

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

Sa pagkakaron, kini usa lamang ka pananglitan-dugang nga mga detalye mahitungod sa mga himan ang mosunod.

Tip # 6: Tugoti lamang kadtong mga tawag nga imong gikinahanglan ug i-block ang tanan.

7. Ibutang ang husto nga pundasyon (o pag-andam alang sa wala damha nga kinaiya)

Ipatuman sa kernel ang profile bisan unsa pa ang imong isulat niini. Bisan kung dili kini eksakto kung unsa ang imong gusto. Pananglitan, kung imong gibabagan ang pag-access sa mga tawag sama sa exit o exit_group, ang sudlanan dili makahimo sa pagsira sa husto ug bisan sa usa ka yano nga sugo sama sa echo hi bitayon siyao alang sa usa ka walay tino nga panahon. Ingon usa ka sangputanan, makakuha ka taas nga paggamit sa CPU sa cluster:

Seccom sa Kubernetes: 7 nga mga butang nga kinahanglan nimong mahibal-an gikan sa sinugdanan

Sa ingon nga mga kaso, ang usa ka utility mahimong makaluwas strace - kini magpakita kung unsa ang problema:

Seccom sa Kubernetes: 7 nga mga butang nga kinahanglan nimong mahibal-an gikan sa sinugdanan
sudo strace -c -p 9331

Siguroha nga ang mga profile naglangkob sa tanan nga mga tawag sa sistema nga gikinahanglan sa aplikasyon sa runtime.

Tip # 7: Hatagi'g pagtagad ang detalye ug siguruha nga ang tanan nga gikinahanglan nga mga tawag sa sistema gi-whitelist.

Kini nagtapos sa unang bahin sa serye sa mga artikulo sa paggamit sa seccomp sa Kubernetes sa diwa sa SecDevOps. Sa mosunod nga mga bahin atong hisgutan kung nganong importante kini ug unsaon pag-automate ang proseso.

PS gikan sa tighubad

Basaha usab sa among blog:

Source: www.habr.com

Idugang sa usa ka comment