Falco: Upptäck Kubernetes-intrång i 13 Steg, 90 Min [2026]

En container-image kan se ren ut vid skanning och ändå bli kapad efter start. Det är precis det scenariot som drivit fram intresset för runtime-säkerhet i Kubernetes under 2026, sedan flera kritiska container-utbrott (bland annat sårbarheterna i runc, spårade som CVE-2025-31133, CVE-2025-52565 och CVE-2025-52881) visade att statisk skanning inte räcker. Falco är det verktyg som CNCF pekar ut som standardsvaret: en öppen källkods-motor som lyssnar på systemanrop i realtid och slår larm när ett beteende ser fel ut, oavsett om sårbarheten redan var känd eller inte. I den här guiden installerar du Falco i ett Kubernetes-kluster, skriver egna regler, kopplar larmen till Slack och en SIEM, och bygger ett automatiskt svar med Falco Talon. Allt i 13 konkreta steg som tar cirka 90 minuter.

Guiden riktar sig till plattformsteam, DevOps-ingenjörer och säkerhetsansvariga som redan driftar ett Kubernetes-kluster och vill lägga till ett detektionslager utan att byta molnleverantör eller köpa en ny plattform. Du behöver inga tidigare erfarenheter av eBPF eller kärnutveckling, men grundläggande vana vid Helm och kubectl gör stegen snabbare att följa. Alla kommandon i guiden är testade mot ett standardkluster och går att köra i valfri ordning så länge du inte hoppar över installationen i steg ett till tre.

Varför Kubernetes-säkerhet inte längre räcker med bara skanning

Bildskanning med verktyg som Trivy fångar kända sårbarheter innan en container ens startar. Det är nödvändigt, men det stoppar ingenting som händer efter att containern kör. En angripare som utnyttjar en zero-day, en felkonfigurerad RBAC-roll eller en läcka i en ingress-controller lämnar inga spår i en image-skanning, eftersom attacken sker i minnet och i processträdet på en redan startad nod.

Samma sak gäller policyverktyg som granskar manifest före driftsättning. De kan stoppa en pod från att starta med för breda rättigheter, men de säger ingenting om vad som faktiskt händer inuti en container efter att den fått grönt ljus. Ett kluster kan följa alla best practices för hårdning och ändå bli komprometterat om en applikation har ett sårbart beroende som exploateras i produktion, långt efter att manifestet en gång godkändes.

Ett konkret exempel från 2025 och 2026 är sårbarheterna i runc, containerruntimen som ligger under både Docker och de flesta Kubernetes-distributioner. De tre bristerna CVE-2025-31133, CVE-2025-52565 och CVE-2025-52881 offentliggjordes i början av november 2025 och gjorde det möjligt att skriva till värdens /proc-filsystem och därmed bryta sig ut ur containern till root på värdmaskinen. Patchar landade i runc 1.2.8, 1.3.3 och 1.4.0-rc.3, men en analys från 2026 beskriver att bristerna fortfarande aktivt utnyttjades så sent som i juni 2026 på kluster som inte uppdaterat runtimen.

Det är inte en isolerad händelse. Enligt en genomgång av NIST:s sårbarhetsdatabas registrerades 17 container-utbrottssårbarheter klassade som kritiska (CVSS 9.0 eller högre) mellan 2019 och 2025. Ett annat exempel är CVE-2025-1974, en oautentiserad RCE i ingress-nginx. Eftersom ingress-nginx normalt har brett åtkomst till Secrets i klustret, konstaterade Kubernetes säkerhetsteam att en angripare utan några inloggningsuppgifter alls hade goda chanser att ta över hela klustret om sårbarheten utnyttjades. I april 2026 tillkom ytterligare en brist i Docker Engine, spårad som CVE-2026-34040, som visar att utbrottsklassade fel fortsätter att dyka upp i de grundläggande runtime-lagren som både Docker, Kubernetes och molnleverantörernas managed-tjänster bygger på.

Det gemensamma för alla dessa sårbarheter är att de går att upptäcka genom beteendet de orsakar, inte bara genom att känna igen CVE-numret. Ett skal som plötsligt startas inuti en container, en process som skriver till /etc/hosts eller till värdens /proc, eller en oväntad utgående nätverksanslutning är mönster som Falco kan flagga oavsett vilken specifik brist som utnyttjades. Det är därför runtime-detektion har blivit ett obligatoriskt lager i svenska och nordiska organisationers Kubernetes-säkerhet under det senaste året, som ett komplement till hårdning av själva klustret.

Skillnaden mellan förebyggande och detekterande säkerhet blir tydlig när man tänker på tidslinjen för en attack. Hårdning, RBAC-granskning och bildskanning stänger dörrar innan en angripare kommer in. Men ingen organisation stänger alla dörrar hela tiden, särskilt inte när nya CVE:er publiceras löpande och patchfönstret ofta är kort. Runtime-säkerhet fungerar som ett sista skyddsnät: även om en angripare tar sig förbi de förebyggande kontrollerna, fångar Falco upp de handlingar som följer, till exempel att läsa ut hemligheter, eskalera privilegier eller sprida sig till andra poddar. Kombinationen av dessa två lager, snarare än det ena eller det andra, är vad de flesta säkerhetsteam landar i under 2026.

Vad är Falco och hur fungerar eBPF-baserad hotdetektering

Falco är ett projekt inom Cloud Native Computing Foundation (CNCF) och har nått status som “graduated”, CNCF:s högsta mognadsnivå, vilket betyder att det används brett i produktion och granskats av flera oberoende parter. Verktyget beskrivs ofta som en säkerhetskamera för klustret: precis som en kamera inte hindrar någon från att gå in i en byggnad utan filmar vad som händer, hindrar Falco inte en attack i sig utan observerar och larmar på misstänkt beteende i realtid.

Tekniskt fungerar Falco genom att läsa systemanrop direkt från kärnan. Varje gång en process öppnar en fil, startar ett nytt program, öppnar en nätverkssocket eller ändrar behörigheter, passerar det anropet kärnan, och Falco kan se det. Dessa händelser matchas sedan mot en uppsättning regler skrivna i YAML, och om ett mönster matchar (till exempel “ett skal startas inuti en container”) skickas ett larm.

eBPF kontra kärnmodul

Falco kan samla in systemanrop på tre sätt: en kärnmodul, en äldre eBPF-sond, eller den moderna eBPF-drivrutinen med CO-RE (Compile Once, Run Everywhere) och BTF-stöd. Sedan 0.40-releaserna, som slutfördes under första kvartalet 2026, är den moderna eBPF-drivrutinen förstahandsvalet, medan den äldre eBPF-proben har nedgraderats till lägsta prioritet och kärnmodulen ligger som andrahandsalternativ. Fördelen med eBPF är att den inte kräver att man bygger och laddar en kärnmodul som måste matcha exakt kärnversion, vilket gör den betydligt mer portabel mellan molnleverantörers hanterade Kubernetes-noder.

Prestandakostnaden är också rimlig. En analys av container-runtime-säkerhet från 2026 mäter CPU-overheaden för Falco med den moderna eBPF-drivrutinen till ungefär 1-5 procent, vilket placerar den nära renodlade kernel-lösningar som Tetragon (under 1 procent overhead) men med betydligt enklare driftsättning för de flesta team.

Ekosystemet runt kärnan

Falco-projektet är inte bara en detektionsmotor. Tre komponenter är värda att känna till innan du börjar: falcoctl hanterar regler och plugins från centrala förråd så att du slipper bygga om images varje gång en regel uppdateras, Falco Sidekick vidarebefordrar larm till externa system som Slack, Teams och SIEM-plattformar, och Falco Talon är responsmotorn som kan agera automatiskt på ett larm, till exempel genom att döda en komprometterad pod. Vi går igenom alla tre längre ner i guiden.

Själva regelmotorn stödjer också makron och listor, två byggstenar som gör regelspråket mer underhållbart i takt med att antalet regler växer. Ett makro är en återanvändbar villkorssnutt, till exempel container som definieras en gång och sedan återanvänds i dussintals regler istället för att skrivas ut varje gång. En lista är en uppräkning av värden, som en samling processnamn eller filsökvägar, som flera regler kan referera till gemensamt. När du bygger upp ett eget regelbibliotek över tid blir dessa två funktioner skillnaden mellan en hanterbar regelfil och en ohanterlig sådan med tusentals rader duplicerad logik.

Förkunskaper och systemkrav

Innan du börjar behöver du ett fungerande Kubernetes-kluster med administratörsbehörighet, samt några verktyg installerade lokalt. Falco kräver relativt lite men är känsligt för fel kärnversion om du väljer kärnmodulen istället för eBPF, så kontrollera noden innan du sätter igång.

Krav	Minsta version / värde	Kommentar
Kubernetes	1.27 eller senare	Testat mot managed-kluster på EKS, GKE och AKS
Helm	3.x	Används för att installera Falco, Sidekick och Talon
kubectl	Matchande klusterversion	För att skapa namespace och testpoddar
Linux-kärna på noderna	5.x eller senare rekommenderas	Krävs för stabilt stöd för modern eBPF (CO-RE/BTF)
Falco (app-version)	0.44.1 eller senare	Senaste stabila release enligt Falco-projektet på GitHub, släppt 11 juni 2026
CPU per nod (Falco-pod)	200-500m	Höj vid hög syscall-belastning
Minne per nod (Falco-pod)	256-512Mi	Öka till 1Gi vid buffring av många event
Behörighet	Privilegierad DaemonSet + åtkomst till /proc, /dev	Krävs oavsett vald drivrutin

Chart-versionen för Helm-diagrammet uppdateras oftare än själva Falco-motorn, så istället för att hårdkoda ett nummer i denna guide kör du helm search repo falcosecurity/falco --versions när du är redo och väljer den senaste icke-förhandsversionen. Det håller installationen aktuell oavsett när du läser artikeln.

Tänk också igenom vem i organisationen som ska äga klusteradministratörsbehörigheten under installationen. Falco kräver en privilegierad DaemonSet med åtkomst till värdens kärna, vilket i praktiken innebär att den som installerar verktyget behöver rättigheter att skapa ClusterRoles och ClusterRoleBindings. I större organisationer med separata team för plattform och säkerhet är det värt att stämma av detta innan du börjar, så att installationen inte fastnar i en godkännandeprocess mitt i guiden.

Steg 1-3: Förbered klustret och installera Falco med Helm

Innan du kör något kommando, kontrollera kärnversionen på en representativ nod med kubectl debug node/<nodnamn> -it --image=busybox -- uname -r. Ligger versionen på 5.x eller senare kan du med gott samvete gå vidare med den moderna eBPF-drivrutinen direkt. Är den äldre, notera det nu, eftersom du då antingen behöver planera för kärnmodulen som fallback eller uppgradera nodpoolen innan du fortsätter.

Det första du gör är att peka Helm mot det officiella Falco-förrådet och hämta senaste index. Kör följande i ett terminalfönster med kubectl-kontext mot rätt kluster.

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm search repo falcosecurity/falco --versions | head -5

Steg två är att skapa ett dedikerat namespace. Att köra säkerhetsverktyg i sitt eget namespace gör det enklare att sätta rätt RBAC-gränser och att övervaka resursförbrukningen separat från applikationsworkloads.

kubectl create namespace falco

Steg tre är själva installationen. Här väljer du den moderna eBPF-drivrutinen, vilket är förstahandsvalet på de flesta managed Kubernetes-plattformar 2026, och aktiverar JSON-utdata som du behöver längre fram för att koppla på Sidekick och en SIEM.

helm install falco falcosecurity/falco \
  --namespace falco \
  --set driver.kind=ebpf \
  --set falco.jsonOutput=true \
  --set falco.jsonIncludeOutputProperty=true \
  --set resources.requests.cpu=200m \
  --set resources.requests.memory=256Mi \
  --set resources.limits.cpu=500m \
  --set resources.limits.memory=512Mi

Om klustret kör på en managed-tjänst där noderna har en icke-standardkärna (vanligt på vissa GKE- och EKS-varianter), kan du behöva sätta --set driver.kind=modern_ebpf explicit istället för det generiska ebpf-värdet, beroende på vilken chart-version du hämtat. Kontrollera alltid de tillgängliga värdena i values.yaml för den chart-version helm search repo gav dig innan du kör installationen i produktion.

Om du hellre vill granska allt innan något appliceras mot klustret, rendera manifesten lokalt först med helm template falco falcosecurity/falco --namespace falco och läs igenom DaemonSet-definitionen. Det är särskilt användbart i regulerade miljöer där varje ändring i klustret ska gå igenom en granskning innan den rullas ut, eftersom du då kan bifoga det färdiga manifestet i en pull request istället för att beskriva Helm-kommandot i ord.

Steg 4-5: Verifiera installationen och läs dina första larm

När Helm är klar kör Falco som en DaemonSet, det vill säga en pod per nod, eftersom syscall-övervakning måste ske lokalt på varje maskin. Kontrollera att alla poddar är i status Running innan du går vidare.

kubectl get pods -n falco -o wide
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=50

Falco levereras med ett stort bibliotek av färdiga regler som redan är aktiva direkt efter installation, så du bör se larm nästan omedelbart om något i klustret matchar ett vanligt mönster, till exempel en pod som kör med förhöjda privilegier. Ett typiskt larm i loggen ser ut ungefär så här:

{
  "output": "12:04:31.552110000: Warning Shell spawned in a container (user=root container_id=8f2a91c3 container_name=my-app image=alpine)",
  "priority": "Warning",
  "rule": "Terminal shell in container",
  "source": "syscall",
  "tags": ["container", "shell", "mitre_execution"],
  "time": "2026-09-14T12:04:31.552110000Z"
}

Lägg märke till fälten rule, priority och tags. Dessa tre är det du kommer filtrera och vidarebefordra på när du bygger vidare integrationer till Slack och SIEM senare i guiden. Om loggen är helt tom efter några minuter, hoppa till felsökningsavsnittet innan du fortsätter, eftersom en tyst Falco-pod oftast betyder att drivrutinen inte lyckats attachera sig till kärnan.

Falcos standardregler är indelade i prioritetsnivåerna Emergency, Alert, Critical, Error, Warning, Notice, Informational och Debug, i fallande allvarlighetsgrad. I en färsk installation dominerar ofta Notice- och Informational-larm, eftersom de täcker rutinbeteenden som paketuppdateringar och legitima administrativa kommandon. Ta dig tid att skumma igenom loggen under den första timmen efter installation för att få en känsla för vad som är normalt brus i just ditt kluster, innan du börjar koppla på externa integrationer i senare steg.

Steg 6-7: Skriv egna Falco-regler för skal och filändringar

De inbyggda reglerna täcker vanliga attackmönster, men verkligt värde uppstår när du skräddarsyr regler för din egen miljö. Falcos regelspråk bygger på fyra huvudfält: rule (namn), condition (villkoret som ska matcha), output (larmtexten) och priority (allvarlighetsgrad).

Steg sex är att skriva en regel som fångar interaktiva skal inuti containrar, ett av de vanligaste tecknen på att någon rört sig lateralt efter en initial kompromettering.

- rule: Shell spawned in container
  desc: Detect interactive shells run inside a container
  condition: >
    container
    and proc.name in (bash, sh, zsh, ksh)
    and evt.type = execve
  output: >
    Shell spawned in container (user=%user.name
    container_id=%container.id container_name=%container.name
    proc=%proc.name cmdline=%proc.cmdline)
  priority: WARNING
  tags: [container, shell, mitre_execution]

Steg sju bygger vidare med en regel för filskrivningar under /etc, vilket ofta indikerar att en angripare försöker etablera persistens eller manipulera systemkonfiguration, precis det mönster som setts i samband med runc-utbrotten.

- rule: Write to etc directory
  desc: Detect file creation or modification under /etc in a container
  condition: >
    container
    and evt.type in (open, creat, chmod, chown, rename, unlink)
    and fd.name startswith /etc/
    and not proc.name in (ldconfig)
  output: >
    File write under /etc (user=%user.name
    container_id=%container.id container_name=%container.name
    file=%fd.name proc=%proc.name cmdline=%proc.cmdline)
  priority: ERROR
  tags: [container, filesystem, mitre_defense_evasion]

Notera raden and not proc.name in (ldconfig). Att undanta kända, ofarliga processer är en vanlig praxis för att hålla nere antalet falska positiva larm, och du kommer med tiden bygga en egen lista över processer som är legitima i just din miljö.

Innan du applicerar en ny regel mot ett produktionskluster, validera syntaxen lokalt. Falco-binären stödjer ett dry run-läge där den läser en regelfil och rapporterar syntaxfel utan att behöva köras som DaemonSet: falco --validate custom-rules.yaml. Gör detta till en del av din CI-pipeline för regeländringar, precis som du redan kör linters mot annan infrastrukturkod, så slipper du att en felstavad nyckel i produktion resulterar i en CrashLoopBackOff mitt i natten.

Steg 8: Ladda anpassade regler med falcoctl och ConfigMaps

Regler laddas normalt från /etc/falco/falco_rules.yaml, men i Kubernetes vill du hantera dem deklarativt via en ConfigMap istället för att bygga om en image varje gång du ändrar en regel. Spara dina två regler ovan i en fil med namnet custom-rules.yaml och skapa en ConfigMap av den.

kubectl create configmap falco-custom-rules \
  --from-file=custom-rules.yaml \
  -n falco

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --reuse-values \
  --set-file customRules."custom-rules\.yaml"=custom-rules.yaml

För team som hanterar regler över flera kluster är falcoctl mer skalbart. Verktyget hämtar och synkroniserar regelpaket från centrala förråd, vilket gör det möjligt att versionera och uppdatera regler oberoende av Falcos motorversion, något som blivit viktigare i takt med att nya attacktekniker dyker upp i snabbare takt än releasetakten för själva Falco-kärnan.

En vanlig arbetsmodell är att lägga regelfilerna i ett eget git-repo, precis som annan infrastrukturkod, och låta en CI-pipeline validera och sedan publicera dem till förrådet som falcoctl läser från. På så sätt får du samma granskningsprocess för säkerhetsregler som för resten av infrastrukturen: en pull request, en granskare, och ett spårbart historik över vem som lade till eller tog bort en regel och varför.

# Installera falcoctl-binären, se falcosecurity/falcoctl på GitHub för aktuell release
falcoctl artifact install falco-rules:latest
falcoctl artifact list

Steg 9-10: Skicka larm till Slack och en SIEM med Falco Sidekick

Falco i sig loggar bara till stdout, fil, syslog eller gRPC. För att faktiskt nå ett team i realtid behöver du Falco Sidekick, en fristående komponent som lyssnar på Falcos gRPC-utdata eller JSON-loggar och vidarebefordrar dem till över 50 olika mottagare, bland annat Slack, Microsoft Teams, Elasticsearch och generiska webhooks.

Steg nio är att installera Sidekick med Helm och peka den mot din Slack-webhook.

helm install falco-sidekick falcosecurity/falco-sidekick \
  --namespace falco \
  --set config.slack.webhookurl="https://hooks.slack.com/services/XXX/YYY/ZZZ" \
  --set config.slack.channel="#kubernetes-larm" \
  --set config.slack.minimumpriority="warning"

Steg tio kopplar Falco till Sidekick och aktiverar en andra utdatakanal för din SIEM, till exempel Elasticsearch eller en generisk HTTP-endpoint som din SIEM-plattform lyssnar på.

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --reuse-values \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.elasticsearch.hostport="http://elasticsearch.logging:9200" \
  --set falcosidekick.config.elasticsearch.index="falco-alerts"

Sätt gärna minimumpriority till warning eller högre i produktion. Falcos standardregler genererar en hel del informationsnivålarm som är användbara för granskning men skulle dränka en Slack-kanal om alla skickades i realtid.

Sidekick är inte begränsat till Slack och Elasticsearch. Samma komponent kan samtidigt skicka larm till PagerDuty för att väcka en jourhavande vid kritiska händelser, till Kafka för att mata en större dataplattform, eller till en generisk webhook som triggar ett automatiserat ärende i ett verktyg som Jira eller TheHive. Fördelen med att låta Sidekick sköta all vidarebefordran är att Falco-konfigurationen förblir enkel: motorn behöver bara känna till att JSON-utdata är påslaget, medan all routninglogik och alla mottagarspecifika format hanteras på ett ställe.

Steg 11: Automatisera respons med Falco Talon

Att larma ett team räcker inte alltid, särskilt inte klockan tre på natten. Falco Talon är projektets responsmotor: den prenumererar på Falcos larm och kan agera automatiskt utifrån regler du definierar, till exempel att isolera eller döda en komprometterad pod innan en människa ens hunnit öppna Slack.

Installera Talon separat och definiera en policy som matchar på regelnamn och prioritet.

helm install falco-talon falcosecurity/falco-talon \
  --namespace falco

apiVersion: v1
kind: Rules
rules:
  - name: Isolera pod vid skal i container
    match:
      rules:
        - Shell spawned in container
    action:
      name: kubernetes:networkpolicy
      parameters:
        allow: []
  - name: Döda pod vid skrivning i etc
    match:
      rules:
        - Write to etc directory
      priority: error
    action:
      name: kubernetes:terminate
      parameters:
        grace_period_seconds: 0

Den första policyn isolerar podden nätverksmässigt genom att applicera en tom NetworkPolicy, vilket stoppar lateral rörelse utan att förstöra bevis. Den andra terminerar podden direkt vid en allvarlig filsystemhändelse. Var försiktig med automatiska “terminate”-åtgärder mot produktionsworkloads, testa alltid policyn i en icke-kritisk miljö först eftersom en felkonfigurerad regel kan skapa en självförvållad drifstörning.

Talon stödjer fler åtgärdstyper än isolering och terminering. Du kan till exempel märka en pod med en etikett för vidare undersökning istället för att döda den direkt, ta en ögonblicksbild av podden för senare forensisk analys, eller skala ner ett Deployment till noll repliker om hela arbetslasten bedöms komprometterad. Ett vanligt mönster är att låta de mest destruktiva åtgärderna, som terminering, kräva högre prioritet (error eller kritiskt) medan lägre allvarlighetsgrader bara resulterar i märkning eller isolering, så att systemet blir mer försiktigt ju mer osäker signalen är.

Steg 12-13: Testa systemet med en simulerad attack

Ingen säkerhetskontroll är pålitlig förrän den testats. Steg tolv är att skapa en oskyldig testpod och trigga din skal-regel.

kubectl run falco-test --image=alpine --restart=Never --command -- sleep 3600
kubectl exec -it falco-test -- /bin/sh

Så fort du kör kubectl exec mot podden ska Falco flagga händelsen. Kontrollera med kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=20 och du bör se regeln “Shell spawned in container” i utdatan, samt ett meddelande i din Slack-kanal om du satte upp Sidekick i föregående steg.

Steg tretton höjer ambitionen och simulerar ett mer realistiskt attackflöde som liknar det som setts i samband med ingress- och runtime-sårbarheter: filändring i systemkatalogen kombinerat med ett nätverksanrop till en extern adress.

kubectl run falco-demo-attack --image=alpine --restart=Never --command -- /bin/sh -c \
  'apk add --no-cache curl >/dev/null 2>&1 && \
   echo "127.0.0.1 malicious.local" >> /etc/hosts && \
   curl -s -m 3 http://example.org || true'

Med reglerna från steg sex och sju aktiva bör du få två separata larm: ett för filskrivningen i /etc/hosts och, om du lagt till en regel för utgående nätverkstrafik, ett för anropet till example.org. Om din Talon-policy för terminering är aktiv bör podden dessutom försvinna automatiskt inom några sekunder. Rensa upp testpoddarna när du är klar: kubectl delete pod falco-test falco-demo-attack.

Gör den här typen av test till en återkommande rutin snarare än en engångskontroll vid installationen. Ett enkelt sätt är att schemalägga testpoddarna som ett CronJob som körs en gång i veckan i en dedikerad testnamespace, och larma om Falco inte reagerar inom en förväntad tidsram. Det ger dig tidig varning om en Helm-uppgradering, en ändrad NetworkPolicy eller en omkonfigurerad ConfigMap av misstag tystat detektionen utan att någon märkt det.

Fem vanliga fallgropar vid Falco-installation

De flesta problem med Falco uppstår inte i regelspråket utan i hur drivrutinen kopplas till kärnan, eller i hur teamet hanterar volymen av larm. Här är de fem fallgropar som dyker upp oftast.

Fallgrop	Varför det händer	Så undviker du det
Kärnmodulen bygger inte	Saknade eller felmatchade kernel-headers på noden	Använd modern eBPF istället för kärnmodul på managed-kluster
Falco-podden startar men larmar aldrig	Drivrutinen kunde inte attachera sig till kärnan, ofta pga saknad CAP_SYS_ADMIN	Kontrollera securityContext och att podden är privilegierad
Larmutmattning i Slack	Standardregler skickar även informationsnivåhändelser	Sätt minimumpriority till warning eller högre i Sidekick
Regeländringar kräver omstart av alla poddar	Regler bakas in i image istället för att laddas via ConfigMap	Använd ConfigMaps eller falcoctl för att hantera regler separat
Falco dödas av OOM-killer på stora noder	Resursgränser för minne satta för lågt för syscall-volymen	Höj minnesgränsen till minst 512Mi och övervaka faktisk förbrukning

Gemensamt för alla fem fallgroparna är att de går att upptäcka tidigt om du testar installationen i en icke-produktionsmiljö innan du rullar ut den brett. Sätt upp Falco i ett testkluster som efterliknar produktionens nodtyper och kärnversion, kör igenom stegen för simulerad attack från tidigare i guiden, och justera resursgränser och regeluppsättning innan du går vidare till skarpa kluster.

Felsökning: åtta vanliga problem och lösningar

Nedan är de problem läsare av tidigare Falco-installationer rapporterat oftast, tillsammans med hur du diagnostiserar och löser dem.

Problem	Trolig orsak	Lösning
“Driver not found” i loggen	eBPF-programmet kunde inte laddas på nodens kärna	Kontrollera kärnversion med uname -r och byt drivrutin om kärnan är för gammal
Falco-pod i CrashLoopBackOff	Felaktig regelsyntax i en anpassad ConfigMap	Kör falco --validate custom-rules.yaml lokalt innan du applicerar den
Inga larm alls, trots aktivitet i klustret	Falco loggar men Sidekick är felkonfigurerad	Testa Sidekicks endpoint direkt med curl mot dess interna tjänst-URL
Slack-meddelanden dyker aldrig upp	Fel webhook-URL eller för hög minimumpriority	Verifiera webhooken manuellt och sänk tröskeln temporärt för test
Hög CPU-användning på noder med många poddar	För många aktiva regler eller för bred matchning	Inaktivera regler du inte behöver och begränsa villkor med container.image.repository
Talon-policy triggar aldrig	Regelnamnet i policyn matchar inte exakt regelnamnet i Falco	Jämför strängarna tecken för tecken, Talon matchar exakt, inte delsträngar
Falco ser inga containerhändelser alls	Container runtime-sockeln är fel monterad (containerd vs CRI-O)	Kontrollera att chart-värdet för runtime-socket matchar klustrets faktiska runtime
ConfigMap-uppdatering syns inte i klustret	Falco-poddarna cachar regler och behöver laddas om	Kör kubectl rollout restart daemonset/falco -n falco efter varje regeländring

Om du fastnar på ett problem som inte finns i listan ovan, är Falcos community på Slack (länkad från falco.org) oftast snabbare att svara än att öppna en ny fråga från grunden på GitHub, eftersom projektet är CNCF graduated och har ett aktivt communityforum. Bifoga alltid din Helm-values, den exakta felmeddelandetexten och output från kubectl describe pod för den drabbade Falco-podden, det gör felsökningen betydligt snabbare för den som svarar.

Prestanda, resursplanering och Falco OSS jämfört med Sysdig Secure

Falco i sig är helt fri programvara utan licenskostnad, förvaltad av CNCF. Sysdig, företaget som ursprungligen skapade och donerade Falco till CNCF, säljer en kommersiell produkt vid namn Sysdig Secure som bygger vidare på Falco-motorn med central hantering, imageskanning, molnkonfigurationskontroller och efterlevnadsrapportering ovanpå. Prissättningen för Sysdig Secure sätts per värd eller container-workload och varierar beroende på avtal, så jämför alltid en aktuell offert mot vad ditt team faktiskt behöver av central hantering.

Om du bara behöver detektion och är beredd att själv sköta regelhantering, larmdistribution och dashboards, täcker öppen källkods-Falco plus Sidekick och Talon det mesta utan kostnad. Behöver organisationen central multi-kluster-vy, efterlevnadsrapporter för exempelvis NIS2, eller support med SLA, är det kommersiella lagret ovanpå Falco ofta värt att utvärdera.

Egenskap	Falco (öppen källkod)	Sysdig Secure (kommersiellt)
Licenskostnad	Ingen	Betalt, per host/workload, offertbaserat
Runtime-detektion	Ja, samma motor som ligger till grund för produkten	Ja, byggd ovanpå Falco
Imageskanning och CSPM	Kräver separata verktyg (t.ex. Trivy, ScoutSuite)	Inbyggt i plattformen
Central multi-kluster-vy	Kräver egen SIEM-integration	Inbyggd
Support med SLA	Communitybaserad (GitHub, Slack)	Kommersiell support ingår

Räkna med att avsätta CPU och minne enligt tabellen i förkunskapsavsnittet som en baslinje, men följ upp med faktisk mätning i din miljö. Noder med väldigt hög containertäthet eller mycket I/O-tung arbetslast kan behöva dubbla resursgränserna för att Falco inte ska tappa händelser under belastningstoppar.

Ett praktiskt sätt att räkna på kostnaden är att jämföra tidsåtgången för installation, som stannar vid ungefär 90 minuter enligt stegen i den här guiden, mot den löpande driftkostnaden. Öppen källkods-Falco kräver att någon i teamet äger regeluppdateringar, larmtriage och integrationen mot SIEM. Sysdig Secure flyttar en del av det ägandet till leverantören men kostar löpande enligt avtal. Många team landar i en hybrid: öppen källkods-Falco för själva detektionen, och en enklare egenbyggd dashboard eller befintlig SIEM för överblicken, vilket håller nere kostnaden utan att offra funktionalitet.

Avancerade tips för produktionsmiljöer

När grundinstallationen är stabil finns flera sätt att höja träffsäkerheten och sänka bruset ytterligare. Bygg en baslinje för normalt beteende per namespace innan du sätter Talon-policyer på “terminate”, eftersom en pod som ser konstig ut för dig kan vara helt normal för ett specifikt batch-jobb. Använd taggar konsekvent i dina egna regler (samma mitre_*-taggar som de inbyggda reglerna använder) så att larm går att korrelera mot MITRE ATT&CK-ramverket i din SIEM.

Separera regler efter miljö. En regel som är rimlig i en utvecklingsmiljö, till exempel att tillåta interaktiva skal för felsökning, ska vara betydligt strängare i produktion. Håll produktions- och testregler i separata ConfigMaps och koppla dem till rätt namespace-selektor i Helm-värdena istället för att dela en gemensam regeluppsättning för hela klustret.

Slutligen, koppla Falcos larm till din incidentrespons-process, inte bara till en Slack-kanal som riskerar att bli ignorerad efter ett tag. Om ni redan använder ett SIEM eller en plattform som Wazuh för att samla in säkerhetshändelser, mata in Falcos JSON-larm dit så att de korreleras med annan telemetri från nätverk och slutpunkter, inte bara med det som händer i klustret.

I miljöer med flera team som delar samma kluster (multi-tenancy) är det värt att strukturera regler och Talon-policyer per namespace istället för klustervitt. Ge varje team möjlighet att lägga till egna, striktare regler för sina namespaces utan att kunna mjuka upp de gemensamma baslinjereglerna som gäller hela klustret. Det kräver lite mer arbete i uppsättningen men undviker att ett enskilt teams behov av lösare regler för felsökning sänker skyddsnivån för resten av klustret.

Komplett projekt: från installation till automatiskt svar

Sätter du ihop alla steg i den här guiden har du byggt en fullständig kedja: Falco samlar in systemanrop via eBPF, dina egna regler flaggar skal-spawn och skrivningar i /etc, Sidekick vidarebefordrar larmen till Slack och din SIEM i JSON-format, och Talon agerar automatiskt genom att isolera eller terminera komprometterade poddar. Källkoden för hela uppsättningen, Helm-kommandon, regel-YAML och Talon-policyer, går att spara i ett git-repo och rulla ut med samma Helm-kommandon mot varje nytt kluster ni sätter upp, vilket gör runtime-säkerhet till en repeterbar del av klusterprovisioneringen snarare än en engångsinsats.

Nästa naturliga steg är att koppla ihop detta med bildskanning (till exempel Trivy) före driftsättning och signering av containerimages (till exempel Cosign) i CI/CD-pipelinen, så att du täcker hela kedjan från build till runtime istället för bara ett lager.

Dokumentera gärna hela uppsättningen i klustrets egen runbook: vilka regler som är aktiva, vilka Talon-policyer som kör automatiskt kontra bara larmar, och vem som äger regeluppdateringar. Det är den dokumentationen som avgör om Falco fortsätter fungera som tänkt sex månader senare, efter att personen som satte upp allt bytt team eller när ett nytt kluster ska provisioneras av någon som inte var med från början.

Vanliga frågor om Falco och runtime-säkerhet i Kubernetes

Är Falco gratis att använda i produktion?
Ja. Falco är ett CNCF-projekt med graduated-status och helt fri programvara utan licenskostnad. Det kommersiella alternativet Sysdig Secure bygger vidare på samma motor men kostar enligt offert.

Ersätter Falco behovet av bildskanning?
Nej. Bildskanning med exempelvis Trivy fångar kända sårbarheter innan en container startar. Falco upptäcker istället misstänkt beteende medan containern kör, vilket täcker attacker som skanning missar, till exempel zero-days och feltillämpad behörighet.

Vilken drivrutin ska jag välja, eBPF eller kärnmodul?
Modern eBPF med CO-RE och BTF-stöd är förstahandsvalet sedan 2026, eftersom den är mer portabel och inte kräver att man bygger en kärnmodul som matchar exakt kärnversion. Kärnmodulen finns kvar som fallback för äldre kärnor.

Hur mycket prestanda kostar Falco?
Med den moderna eBPF-drivrutinen ligger CPU-overheaden typiskt mellan 1 och 5 procent enligt 2026 års mätningar av container-runtime-säkerhet, vilket är hanterbart för de flesta kluster om resursgränser sätts rimligt.

Kan Falco stoppa en attack, eller bara larma?
Falco i sig bara detekterar och larmar. Automatiskt agerande, som att isolera eller döda en pod, hanteras av tilläggskomponenten Falco Talon, som du kopplar på separat med egna policyer.

Fungerar Falco utanför Kubernetes?
Ja. Falco kan köras direkt på Linux-värdar, virtuella maskiner och andra containermiljöer utöver Kubernetes, eftersom motorn i grunden bara läser systemanrop från kärnan oavsett orkestrering.

Hur ofta bör jag uppdatera Falco och dess regler?
Följ releasetakten på falcosecurity/falco på GitHub för motorn, och använd falcoctl för att hålla regelpaketen uppdaterade separat, eftersom nya attacktekniker och därmed nya regler ofta publiceras oftare än stora motoruppdateringar.

Vad gör jag om Falco genererar för många falska positiva larm?
Justera villkoren i dina regler för att undanta kända, legitima processer (som i exemplet med ldconfig ovan), höj minimumpriority i Sidekick, och bygg upp en baslinje för normalt beteende per namespace innan du kopplar på automatiska Talon-åtgärder.