Resumé

Med overgangen til et cloud-native miljø er traditionelle sikkerhedskontroller som firewalls, IDS og IPS, utilstrækkelige til at beskytte en virksomheds særegne netværk. I en cloud-native kontekst er applikationer og data ofte spredt på tværs af forskellige servere, cloud-leverandører eller Kubernetes clusters, hvilket udfordrer etableringen af en stabil sikkerhedsperimeter for virksomhedens netværk.

Denne blog dykker ned i sikkerhedsaspekterne af Kubernetes og de overvejelser, der er udmærket for at implementere applikationer i et Kubernetes cluster. At gøre Kubernetes sikker indebærer udfordringer på grund af dets komplekse arkitektur, dynamiske natur og distribuerede setup. Effektiv sikkerhedsstyring kræver, at der navigeres gennem forskellige konfigurationslag, at der er dyp forståelse af den cloud shared-responsibility model og at man holder sig ajour med hensyn til fremtidige sikkerhedspraksisser.

Det kræver en multifacetteret tilgang at håndtere Kubernetes’ usikre default tilstand og at forbedre systemets sikkerhedstransparens. De strategier, der bliver udforsket i denne blog, omfatter system- og cluster hardening, supply chain sikkerhed, minimering af microservice sårbarheder, bekæmpelse af lateral-movement, netværkssikkerhed samt implementering af effektiv overvågning, lognings- og runtime-sikkerhedskontroller.

Miljøopsætning

Kubernetes er det mest populære system til orkestrering af containers og et af de hurtigst voksende open-source projekter i historien. I denne blog vil vi fokusere på Kubernetes med det formål at beskytte både cluster konfigurationsdataene og brugerdata, der krydser cluster netværket. Derudover ønsker vi at forhindre, at cluster-hukommelsen og CPU-ressourcer misbruges af hackerne. Vores mål er at beskytte mod en ”active, probabilistic, polynomial-time attacker”, der udnytter sårbarheder i det cloud-native miljø.

For eksempel kan en hacker installere malware for at få fat på virksomhedens data, kryptere dem og kræveen løsesum for dekrypteringsnøglen. Alternativt kan hackeren køre kryptovaluta-minedrift på virksomhedens infrastruktur med en regning at betale efterfølgende.

Uanset hostingmiljøer – om virksomheden kører sit cluster i cloud, i det lokale miljø eller i et hybridmiljø – er det i virksomhedens interesse at bruge tid og kræfter på at holde det sikkert. Denne blog sætter fokus på, hvor virksomheden skal fokusere, og hvordan den kan beskytte sit cluster uanset hostingmiljø.

Konventioner

I hele denne blog angiver følgende formatkonventioner tekst til særlig brug:

• Rammer og modeller: Denne blog følger faserne i cyber kill chain-modellen udviklet af Lockheed Martin og stemmer overens med den terminologi, der bruges i MITRE ATT&CK Framework. Desuden er terminologien, der bruges i hele denne blog, i overensstemmelse med kildedokumentationen for de relaterede emner.
• Værktøjer: Ethvert værktøj, der bruges til at demonstrere et koncept eller nå et specifikt mål, antages at være sikkert, korrekt implementeret og tilpasset bedste praksis for dets domæner. Det er imidlertid vigtigt at præcisere, at fokus er på at præsentere koncepter og idéer snarere end at fremme specifikke produkter eller teknologier.

Ved at overholde disse konventioner tilstræber vi at give en klar og konsistent læseoplevelse, der sikrer, at alle refererede materialer og værktøjer er let identificerbare og tilgængelige.

Containeres og virtuelle maskiners forskellige egenskaber

Før vi går i dybden med Kubernetes, lad os se på, hvordan containerne adskiller sig fra de virtuelle maskiner (VM’er), som engang udgjorde fundamentet i vores infrastruktur. VM’er tilbyder robust isolering via hypervisorbaseret drift, hvor hver VM er udstyret med sit eget, dedikerede OS. Denne effektive adskillelse komplicerer angribernes forsøg på at overskride VM-grænserne. Containere deler derimod OS værtskernen, hvilket kan føre til svagere isolation sammenlignet med VM’er. Et indbrud i kernen kan potentielt påvirke alle containere, der kører på samme vært. Containeren er afhængig af Linux-namespaces og cgroups til isolering og ressourcestyring. Namespaces sikrer, at hver container har sin egen oversigt over systemressourcer, mens grupper administrerer ressourceallokering. Containerssikkerhed er en tilgang i flere lag, der kombinerer isolationsmekanismer, ressourcestyring og runtimefunktioner for at skabe sikre og effektive containermiljøer. Og for en god ordens skyld, kører containere ofte på en VM, så det er vigtigt at have forståelse for begge systemers sikkerheds best practices.

Angrebsfladen

Vores mål er at minimere sandsynligheden for angreb og gøre det tilstrækkeligt udfordrende for angribere, så de ser efter lettere mål et andet sted hen. Absolut sikkerhed er uopnåelig, men vi tilstræber at reducere vores blast radius for et angreb til et håndterbart niveau. Man skal altid huske, at inden for sikkerhed skal fokus kun være på at beskytte to væsentlige ting: data og regnekraft. Hvis data forbliver sikre i et sårbart miljø, er virksomheden på rette spor. Selvom det kan virke indlysende, er det afgørende at huske dette princip for at undgå unødvendig kompleksitet og unødvendige udgifter. Dette gælder især for public cloud, at data forbliver sikre, selvom cloududbyderen oplever et brud.

Traditionel netværkssikkerhed er afhængig af firewalls og andre værktøjer til at sikre netværksperimeteren, som fungerer som din forsvarslinje. Dette kan sammenlignes med en fæstning med vægge, en voldgrav og bevogtede ind- / udgangspunkter. Denne model forudsætter, at der er tillid til alt inden for væggene, mens det modsatte er tilfældet udenfor. Fæstningsmodellen har imidlertid et enkelt iboende fejlpunkt: indgangspunktet. Når en ubuden gæst overtræder dette punkt, kan de bevæge sig sideværts inden for netværket og angribe ressourcer undervejs.

I forbindelse med Kubernetes har containerised microservices arkitekturen yderligere kompliceret netværksperimetersikkerheden ved at øge antallet af netværksindgangspunkter. Hvert endpoint repræsenterer en potentiel trussel. Kubernetes kører på en åben netværkstopologi som standard, hvilket gør det mere udfordrende at isolere et angrebs radius.

Selvom IPsec- og VPN-protokoller kan sikre forbindelser til virksomhedens netværk, løser de ikke fuldt ud de sikkerhedsudfordringer, der er forbundet med Kubernetes-miljø. Specifikt mangler de at forhindre lateral movement og intern ”network sniffing” i et cluster, hvilket er særdeles alvorligt for Kubernetes-sikkerhed.

I de følgende afsnit vil vi fokusere på nøgleaspekter, der vil gøre dit cluster stærkere, give et mere robust sikkerhedsmiljø og reducere potentielle angrebsvektorer.

Netværkspolitikker og segmentering

Sikring af cluster i Kubernetes kræver mere end bare perimeterbeskyttelse. Et afgørende skridt indebærer at begrænse adgangen til den standardåbne netværkspolitik. Som standard tillader Kubernetes default netværkspolitik, at alle pods kommunikerer på en åben netværkstopologi, hvilket udgør en betydelig sikkerhedsrisiko. Implementeringen af netværkspolitikker er afgørende for at kontrollere og begrænse adgangen til denne åbne kommunikationsmodel.

For at løse dette problem, så begynd med at segmentere arbejdsbelastninger baseret på funktion og sensitivitet. Brug labels og selectors til at definere tilladte trafikruter og sørg for, at der kun foregår nødvendig kommunikation mellem pods. Implementer desuden en least privilege access model i clusteret for at minimere uautoriseret adgang. Stol kun på verificerbare identiteter for autentificeringen. Segmentering og mikrosegmentering af netværket i mindre, isolerede segmenter reducerer effekten af et angreb på clusteret.

Segmentering af netværket alene forhindrer ikke lateral movement mellem segmenter. Det gør det dog ved at sikre grænserne for hvert segment med netværkspolitikker. I kritiske systemer kan vi tage et ekstra skridt og oprette en blind netværkstopologi mellem segmenter eller før netværksindgangspunktet for at begrænse adgangen til uautoriserede enheder. Fysisk netværkssegmentering, kendt som infrastrukturskjulning, involverer definition af portbaseret netværksadgangskontrol gennem middleware-gateways for at forhindre uautoriseret adgang. For yderligere info henvises til IEEE 802.1X-2020 [1] standarden.

Faktisk er det blinde netværk i overensstemmelse med SDP-specifikationen v1.0[2] og V.2.0 [3] for zero-trust cloud-native arkitektur, hvor kritiske segmenter er helt skjult for at forhindre uautoriseret adgang ved hjælp af single packet authorization protokollen i stedet for TCP-forbindelser. Det er vigtigt at vurdere, hvor kritisk data er, og derefter bruge passende sikkerhedsforanstaltninger. Det er også vigtigt at overveje, hvordan yderligere beskyttelsesforanstaltninger kan påvirke responstid og omkostningerne.

Sikring af intern kommunikation med TLS

Når du udsætter din applikation for internettet med Kubernetes og sikrer den med TLS-protokollen, er det vigtigt at være opmærksom på, at krypteringen afsluttes på ingress-niveauet. Det betyder, at når trafik rettet mod din applikation kommer ind i clusteret, forbliver den ukrypteret internt, hvilket potentielt gør den sårbar over for uautoriseret access. Applikationen skal ofte kommunikere med andre services i cluster for at kunne opfylde sine opgavekrav, hvilket øger risikoen og kompleksiteten.

Nu hvor vi har segmenteringen på plads, lad os se på, hvordan pods kan kommunikere sikkert inden for de samme segmentgrænser eller mellem forskellige interne segmenter ved hjælp af TLS-protokollen. Organisationer benytter ofte en sidecar med service mesh-teknologier som Istio eller Linkerd til effektiv TLS-implementering. Ved at implementere en sidecar-proxy ved siden af hver microservice er al kommunikation inden for netværket indkapslet og krypteret, hvilket sikrer end-to-end-kryptering uden behov for ændringer i programkoden.

Det er vigtigt at forstå, at selvom sidecar-tilgangen øger sikkerheden, så er der også afvejninger at tage hensyn til. Implementering af sidecar-proxyer kan påvirke responstid og kræve ekstra ressourcer. Især i mindre Kubernetes-clusters kan omkostningerne og administrationen af sidecar-løsninger være udfordrende i forhold til administrationen af selve arbejdsbelastningerne. Disse teknologier inkluderer typisk et bredt sæt af værktøjer, såsom netværksobservabilitet, trafikstyring, plugin-integration og meget mere. Det kan belaste clusteretog øge omkostningerne, da der muligvis skal betales for serviceomkostninger, som måske ikke bliver brugt til noget i clusteret.

Alternativt kan CNI-plugins som f.eks. Cilium tilbyde en identitetsbaseret implementering af NetworkPolicy-ressourcer ved hjælp af eBPF uden sidecar-proxy. Dette gør det muligt at isolere forbindelser mellem pods på lag 3 og 4 samt med politikker på lag 7 for forskellige applikationsprotokoller som f.eks. HTTP og Kafka. Derfor er det afgørende at identificere, hvad der nøjagtigt er brug for, før sidecar-tilgangen vælges.

Beskyttelse af namespaces

Linux-containere konstrueres gennem Linux-namespaces, cgroups og user-groups. Disse namespaces, herunder netværks- og proces-namespaces, sikrer, at containers forbliver adskilt fra hinanden og host-systemet. Containere kan dog konfigureres/fejlkonfigureres til at bruge host-namespaces. Selvom dette kan være nødvendigt for nogle opgaver, som kræver direkte adgang til host-namespaces, reducerer det isolationen betydeligt og forøger sikkerhedsrisici.

Ved hjælp af Kubernetes security-context kan workload-adgangen til din host, og hvad de kan gøre i systemet, begrænses. Et scenarie kunne være: en pod, som er konfigureret med forkerte rettigheder, og en root-bruger, i tilfælde af et sikkerhedsbrud i den pod kan en hacker bryde ud af containeren og få kontrol over hele noden. Noden indeholder typisk adgangsoplysninger til at kommunikere med API-serveren, som er clusterets ‘hjerne’. En kompromitteret node kan køre statiske pods og misbruge nodens ressourcer til hackingaktiviteter.

Security-contexten giver mulighed for at kontrollere forskellige aspekter af pod-sikkerhed, såsom at køre som en ikke-privilegeret container, køre containers med read-only root filesystem og andre sikkerhedsforanstaltninger. Disse konfigurationer hjælper med at mindske risikoen for brud og uautoriseret adgang, hvilket forbedrer den overordnede sikkerhedstilstand for Kubernetes-clusteret.

I et kritisk system vil man kunne opnå et mere begrænset miljø ved at køre containers i et sandboxingmiljø ved hjælp af f.eks. gvisor runtime eller andre tilsvarende sandboxing produkter. Fordelen ved at køre Kubernetes i et sandbox-miljø som gvisor er øget sikkerhed gennem bedre isolation, hvilket hjælper med at beskytte host-systemet mod potentielle sårbarheder og udnyttelser inden i containerne.

Least Privilege er den hellige gral

Det er hensigtsmæssigt at anvende least privilege konceptet for at minimere angrebsoverfladen. Faktisk er det kernen i næsten enhver sikkerhedsmodel. Hele arkitektoniske designs og principper kan skræddersys til dette koncept; for eksempel fokuserer zero-trust arkitekturen på at give de mindste privilegietilladelser og at kontrollere adgangen til kun det, der er nødvendigt. Det kontrollerer løbende behovet for adgang og gyldigheden af brugers identitet..

Implementering af en sådan tilgang til Kubernetes reducerer angrebsoverfladen betydeligt. Her er, hvad vi sigter mod at kontrollere:

Tilladelser: Sørg for, at dit cluster fungerer med det absolutte minimum af tilladelser, der er nødvendige. Uanset om det er en service-principal, der godkender container pull-images, eller får adgang til et vigtigt cloud-key-store, skal hver komponent kun have de tilladelser, den nødvendigvis har brug for. Dette minimerer risikoen for, at infrastrukturen kompromitteres under et angreb.

Policy-enforcement-engine: Open Policy Agent, for eksempel, muliggør oprettelse af fintmaskede politikker for at begrænse uønskede aktiviteter i clusteret. For eksempel kan det forhindre, at containeren kører images fra ikke-godkendte registre, eller det kan scanne images for sårbarheder før produktionsbrug. I bund og grund, så verificerer det legitime aktiviteter i clusteret.

Linux-sikkerhedsmoduler: Brug af Linux-sikkerhedsmoduler som AppArmor eller SELinux giver mulighed for at definere regler, der begrænser containernes muligheder og kapaciteter. Med AppArmor kan der for eksempel oprettes profiler, der angiver, hvilke filer en container kan få adgang til, eller hvilke netværksressourcer den kan nå. Dette sikrer præcis kontrol over interaktioner med host-systemet.

eBPF-understøttede teknologier: Brug af eBPF-understøttede teknologier som Falco til sporing og overvågning af hændelser på kerneniveau forbedrer sikkerheden. Det registrerer unormal adfærd på kerneniveau, som kan blokeres hvis nødvendigt, hvilket giver et ekstra lag af forsvar og mere kontrol over miljøet.

Integrering af disse forholdsregler begrænser misbrug af clusteret og sikrer, at legitime brugere har kun de absolut nødvendige privilegier i clusteret. jo klarere reglernes defines, jo sikrere og mere modstandsdygtigt bliver miljøet over for potentielle brud.

Administration af regnekraft i Kubernetes

Administration af regnekraft i dit Kubernetes-cluster er afgørende, ikke kun for effektiviteten, men også for sikkerheden. Ved at sikre at arbejdsbelastningerne kun har de nødvendige ressourcer, forhindres spild af computerkraft, og omkostningerne reduceres.

Selvom det kan virke uden for det direkte sikkerhedsområde, er administrationen af clusterregnekraften afgørende for at afbøde potentielle risici såsom krypto-minedrift, misbrug af cluster-ressourcer eller skjulte servere, der lancerer DDoS-angreb fra clusteret. Ved at forstå og overvåge regnekraftforbruget kan stigninger i ressourceforbruget hurtigt identificeres, og uautoriserede aktiviteter kan dermed forhindres.

Sådan kan en god regnekraftsstrategi i Kubernetes clusteret designes:

1. Ressourceanmodninger og -grænser: Angiv minimum- og maksimumressourcekrav for hver pod for at forhindre ressourcemisbrug og sikre en retfærdig pod fordeling på noderne.
2. QoS-klasser (Quality of Service): Kategoriser pods baseret på ressourceforbrugsmønstre for at prioritere kritiske arbejdsbelastninger og opretholde driftssikkerhed.
3. Horizontal Pod Autoscaling (HPA): Skaler automatisk antallet af pod-replicas baseret på målepunkter for ressourceudnyttelse for at håndtere fluktuerende efterspørgsel.
4. Ressourcekvoter: Overhold grænserne for CPU- og hukommelsesressourcer for at forhindre at individuelle arbejdsbelastninger lægger beslag på cluster-ressourcer, og mindsk risikoen for dræn af ressourcerne.
5. Overvågning og alarmering: Implementer robuste overvågningsværktøjer til at spore ressourceudnyttelse i realtid og at modtage advarsler om unormal adfærd, hvilket muliggør proaktive reaktioner på potentielle sikkerhedstrusler.

Ved at bruge disse metoder i Kubernetes-miljøet kan regnekraften administreres effektivt samtidig med, at sikkerheden forbedres, og risikoen for uautoriseret ressourceforbrug mindskes.

Nytænkning af Kubernetes-secrets

I Kubernetes kan udtrykket “secrets” være misvisende, da det i det væsentlige er base 64-encoded værdier og ikke bør bruges til at gemme følsomme oplysninger. Vælg i stedet dedikerede ”secrets” administrationsløsninger til sikker opbevaring og hentning af følsomme data. Håndhæv desuden adgangen til dine hemmeligheder ved hjælp af RBAC for at sikre, at kun autoriserede enheder kan læse dem.

Overvej f.eks. at bruge Azure Key Vault som Secrets Store CSI Driver. Denne integration muliggør kontrolleret adgang via Azure Key Vaults adgangspolitikker og RBAC, hvilket sikrer, at hver bruger eller hvert program kun har adgang til de secrets, de har brug for.

Kryptering i rest

Etcd-serveren er en vigtig komponent i clusteret, der opbevarer kritiske data til distribuerede systemer eller applikationer, herunder konfigurationsindstillinger, oplysninger om service-discovery m.m. Kommunikation med etcd sker via HTTPS, men data, der er gemt i det, er ikke sikret som standard, hvilket kræver kryptering i resten og begrænset adgang ved hjælp af RBAC. For at opnå dette, kan en Key Management Service (KMS) anvendes ved hjælp af en envelop-encryption-scheme til kryptering af data inden for etcd. Dette indebærer kryptering af dataene med en datakrypteringsnøgle (Data Encryption Key), som yderligere krypteres med en nøglekrypteringsnøgle (Key Encryption Key), der administreres i en ekstern KMS. Adgang til KMS bør kontrolleres omhyggeligt ved hjælp af RBAC og adgangspolitikker, med overvågning. Rotation og sletning af nøgler skal ske automatisk og løbende så ofte som kan give mening, men ikke mere end 30 dage.

Overvejelser i forbindelse med sikkerhed i software lifecycle

Det er afgørende at implementere strategier som shift left og DevSecOps for at opdage og håndtere trusler proaktivt. Her er de vigtigste overvejelser inden for Kubernetes:

White-listing af image registre:

• Brug politikker til at whiteliste specifikke registre for ”base” og ”parent” images i dine Dockerfiler
• Tillad cluster at kun hente images fra autoriserede registre.

Sørg for image-verifikation og scanning:

• Alle importerede images, fra eksterne registre, skal gennemgå grundig verifikation og scanning, før de kommer ind i dit image register.
• Opdater regelmæssigt virksomhedens imageregistre, og vedligehold ikke mere end to eller tre versioner for hvert image for at forhindre falske positive scanningsrapporter om sårbarheder.

Image- signering: 

• Signer container-images ved hjælp af en hash, der er genereret ud fra image unikke indhold.
• Brug kun pålidelige kilder til base-images.
• Kontroller image-signatur for at sikre integritet og forhindre manipulation.

Sårbarhedsscanning:

• Brug værktøjer som Trivy til at scanne images for kendte sårbarheder i CVE-databasen.
• Opret politikker for at acceptere images baseret på bestemte trusselsniveauer, før de tillades at køre i produktionen. For eks., man kan acceptere at kun images med en lave trusselsniveauscore må køre i produktionen.
• Integrer image-scanning i cluster som admission-controller for proaktiv sikkerhed.

Overvågning og trusselshåndtering i Kubernetes

Overvågning i realtid og trusselshåndtering udgør betydelige udfordringer i Kubernetes af flere årsager. En udfordring stammer fra de forskellige omfang og lag, der omfatter opsætningen, herunder containere, OS, cloud/on-premises infrastruktur, netværkskonfigurationer m.m. Et andet aspekt er den dynamiske karakter af Kubernetes, hvor Kubernetes controllers løbende overvåger cluster-tilstanden og afstemmer eventuelle afvigelser med den ønskede tilstand, der er gemt i etcd.

Hvis man f.eks. for sikkerhed skyld sletter en sårbar pod, der administreres af et ReplicaSet, vil ReplicaSet controlleren genskabe poden igen . Hvis man bare sletter en pod fra en ReplicaSet controlleren, bliver den ikke automatisk genskabt, men man mister den resiliens, som Kubernetes-cluster giver. Målet er at kunne fjerne trusler fra clusteren uden at have nogen nedetid.

Standardmetoden vs. Kubernetes dynamics

I en traditionel VM-opsætning installerer man en agent, der indsamler oplysninger direkte fra kernen og overvåger forskellige processer og netværkstrafik, rapporterer tilbage efter behov og håndterer trusseler direkte i VMen. I Kubernetes kører pods på en worker-node, men administreres af master-noden. Det betyder, at hvis man installerer en agent i worker-node og sletter en pod manuelt fra worker-noden, vil den blive genskabt af master-noden, som tidligere nævnt i forbindelse med ReplicaSet. Man kan vælgere at installere en agent med specifikke rettigheder rettigheder til at kommunikere direkte med API-serveren og derfra slette poden. Tildeling af en agent med signifikante privilegier udgøre en sikkerhedsrisiko, husk least privileges. Derudover skal API-serveren i nogle tilfælde muligvis udsættes for internettet for at agenten kan tilgå dette, hvilket ikke tilrådes.

Alternativt er der en agentfri tilgang, som har adgang til containerspecifikke aktiviteter, primært med fokus på cluster-niveau events. Den løsning har begrænset overvågningsevner, da den ikke kan se noget fra host-kernel. Selvom man med denne fremgangsmåde undgår behovet for .en agent med høje, specifikke privilegier, kan det resultere i manglende detaljerede indsigter, som netop kræves for at genkende og reagere på trusler i individuelle containere. Hvad gør vi så?

Lad os forstå problemet yderligere og udforske nogle af de tilgængelige løsninger på markedet til at tackle Kubernetes sikkerhedsudfordringerne.

Cortex XDR og XSIAM

Cortex XDR og XSIAM er et eksempel på at løse disse udfordringer i et cloud-baseret miljø ved at kombinere både agent- og agentløse tilgange for at få synlighed og kontrol over clusteret. Det integrerer direkte med cloud-providers for at få de nødvendige rettigheder uden at udsætte API-serveren for public-access. Det kommunikerer direkte med clusteret, afbøder trusler på cluster-niveau, anvender avanceret analyse til trusselsdetektion og tilbyder automatiserede responsmuligheder gennem playbooks.

Kilde: https://www.paloaltonetworks.com/blog/security-operations/securing-kubernetes-clusters-the-cortex-xdr-and-xsiam-approach/

Sådan fungerer det:

1. Integration af begge tilgange: Cortex XDR og XSIAM integrerer både agentbaserede og agentløse tilgange for at give omfattende synlighed og kontrol over Kubernetes-clusters. Denne integration giver organisationer mulighed for at drage fordel af styrkerne ved hver tilgang.
   
2. Det kører på hver node: agenten fungerer som et DaemonSet og implementerer en agent-pod på hver node i clusteren, hvilket sikrer, at alle noder er beskyttet af Cortex.
   
3. Direkte kommunikation med clusteret: Cortex kommunikerer direkte med Kubernetes-cluster, så den kan få indsigt fra containeraktiviteter og events på cluster-niveau. Dette sikrer, at sikkerhedsanalytikere har et holistisk overblik over hele Kubernetes-miljøet, hvilket muliggør en effektiv trusselhåndteringsproces.
4. Forbedring af event data: Cortex XDR og XSIAM forbedrer event-data med relevante oplysninger om host, containers og Kubernetes. Data kan bruges til at forbedre nøjagtigheden af trusselsregistrering og muliggør proaktiv reaktion på trusler.
5. Afbødning af trusler på cluster-niveau: Løsningen er udstyret til at mindske trusler på cluster-niveauet, herunder udnyttelser, der er rettet mod programmer i containeren, uautoriseret adgang til credentials og udrulning af kompromitterede pods.
6. Avanceret analyse og automatiseret svar: Cortex XDR og XSIAM bruger avanceret analyse til trusselsdetektering og tilbyder automatiserede responsfunktioner gennem playbooks. Dette giver organisationer mulighed for at registrere og reagere på sikkerhedstrusler i realtid, hvilket reducerer risikoen for databrud.

Resumé

Sikring af Kubernetes-clusteret kræver omfattende strategier på grund af dets dynamiske karakter og kompleksitet. Denne blog har diskuteret overvejelser, herunder netværkssegmentering, kryptering og nuancerne i forskellige sikkerhedsmetoder. Bedste praksis såsom RBAC, ressourcebegrænsning og overvågning i realtid er blevet fremhævet. Desuden blev innovative løsninger som Cortex XDR og XSIAM, der integrerer både agentbaserede og agentløse tilgange, undersøgt for effektiv trusselsdetektering og respons.

Bibliografi

• 1X-2020. URL-adresse: https://ieeexplore.ieee.org/document/9018454.
• SDP v1. URL-adresse: https://cloudsecurityalliance.org/artifacts/sdp-specification-v1-0.
• SDP v2. URL-adresse: https://cloudsecurityalliance.org/artifacts/software-defined-perimeterzero-trust-specification-v2.