Microsoft satte containersikkerhet for alvor på agendaen i Azure denne høsten. 1. september 2026 ble Microsoft Defender for Cloud generelt tilgjengelig for Azure Container Apps, og bare to uker senere, 14. september, pensjoneres forhåndsvisningsfeltet enableCustomCATrust i Azure Kubernetes Service. To datoer, én rød tråd: Microsoft strammer grepet om hvordan serverløse containere og Kubernetes-klynger overvåkes og sikres, midt i en bølge av alvorlige sårbarheter i containerverktøy som containerd, Docker/Moby og Kata Containers. For norske og nordiske IT-avdelinger som har flyttet arbeidslaster til Container Apps eller AKS de siste par årene, er dette ikke en teknisk fotnote. Det er en frist med reelle driftskonsekvenser.
Hva skjedde: Defender for Cloud blir GA for Container Apps
Azure sin oppdateringslogg viser en GA-oppføring datert 1. september 2026 med tittelen «Microsoft Defender for Cloud support for Azure Container Apps (Serverless Containers Posture)». Det betyr at Container Apps nå formelt regnes som en egen ressurstype, «serverløse containere», i Defenders støttematrise, på lik linje med AKS og andre containerarbeidslaster. Frem til nå har Defender for Cloud i praksis vært bygget rundt Kubernetes: agentbasert og agentløs overvåking av AKS, samt sårbarhetsskanning av registre som Azure Container Registry. Container Apps, som kjører uten at kunden må administrere en Kubernetes-kontrollplan, falt utenfor det dekningsområdet.
Med GA-lanseringen kommer Azure Container Apps inn under Defender CSPM (Cloud Security Posture Management), som dekker konfigurasjonsvurdering av nettverk, identitet, kryptering og hemmeligheter, samt agentløs bildeskanning der image ligger i støttede registre. I praksis får team som kjører Container Apps de samme type funn som AKS-brukere har hatt tilgang til: feilkonfigurerte tilganger, manglende TLS-herding og sårbare avhengigheter i containerbildet, synlig i samme Defender-portal og med samme alvorlighetsgradering som resten av skymiljøet.
enableCustomCATrust pensjoneres 14. september
Den andre og potensielt mer forstyrrende endringen gjelder AKS. Ifølge utgivelsesnotatene fra Azure/AKS-prosjektet på GitHub, publisert 17. juli 2026, blir forhåndsvisningsfeltet enableCustomCATrust pensjonert 14. september 2026. Etter den datoen vil ikke lenger `enableCustomCATrust=true` aktivere en egendefinert sertifiseringsinstans på nodenivå. Microsoft advarer eksplisitt om at klynger som fortsatt lener seg på det gamle forhåndsvisningsfeltet, risikerer feil ved skalering og ved sertifikatfornyelse dersom de ikke oppdateres før fristen.
Feltet ble opprinnelig laget for virksomheter med intern PKI, altså selskaper som trenger at AKS-nodene stoler på interne sertifiseringsinstanser for mTLS mot bakenforliggende tjenester, databaser eller servicemesh-komponenter. Den generelt tilgjengelige erstatningen heter customCaTrustCertificates, tilgjengelig via CLI-parameteren `–custom-ca-trust-certificates`. Microsoft fjernet allerede i september 2025 selve forhåndsvisnings-API-versjonen for feltet, og den gamle deaktiveringskommandoen `–disable-custom-ca-trust` finnes ikke lenger i nyere Azure CLI-versjoner. Klynger som fortsatt har flagget satt til true, må derfor oppdateres med en generisk ressursoppdatering, ikke den gamle snarveien.
# Sjekk om klyngen fortsatt bruker det utgåtte feltet
az aks nodepool show --resource-group MyRG --cluster-name MyAKS \
--name nodepool1 --query "enableCustomCaTrust"
# Fjern det gamle forhåndsvisningsfeltet og bruk GA-mekanismen
az aks update --resource-group MyRG --name MyAKS \
--custom-ca-trust-certificates ./ca-bundle.pemKonsekvensen for team som ikke rydder opp før 14. september, er ikke et umiddelbart driftsstopp, men en stille degradering: nye noder som legges til under skalering, kan mangle tillit til den interne sertifiseringsinstansen, mens eldre noder fortsatt har den. Det gir en inkonsistent klynge der noen poder klarer mTLS-oppkobling og andre feiler tilfeldig, en type feil som er vond å feilsøke fordi den ikke slår ut med en gang.
Bakgrunn: hvorfor Microsoft strammer grepet om containersikkerhet nå
Timingen er ikke tilfeldig. 2026 har vært et år med flere alvorlige funn i selve fundamentet under containerdrift, altså i runtime-lag som containerd, Docker Engine (Moby) og Kata Containers, ikke bare i applikasjonskoden som kjører inni containerne. En sårbarhet i containerd, katalogisert som CVE-2026-46680, lar et ondsinnet image omgå Kubernetes sin `runAsNonRoot`-restriksjon ved å sende en brukerverdi som ikke lar seg tolke som et 32-bits heltall. Resultatet kan bli at containeren kjører som root selv om policyen eksplisitt forbyr det. NVD og Red Hat har gitt feilen en CVSS-score på 7,8.
Mer alvorlig er en relatert svakhet i CRI-implementasjonen (Container Runtime Interface), der kjøretiden stoler på CDI-annoteringer fra ubetrodd metadata under gjenoppretting av containere fra sjekkpunkt. En bruker med rettigheter til å opprette poder kan utnytte dette til å omgå ressursallokering og enhetshåndheving, noe som er spesielt relevant for GPU- og akselerator-arbeidslaster i konfidensiell databehandling. NVD har gitt denne sårbarheten en CVSS-score på 9,6. I tillegg fant sikkerhetsforskere en autorisasjonsomgåelse i Docker Engine (Moby), med CVSS 8,8, som lar angripere omgå AuthZ-plugins og få uautorisert tilgang til Docker-daemonen. Til sammen tegner dette et bilde av et containerøkosystem der selve kjøretiden, ikke bare applikasjonslaget, er blitt et aktivt mål.
Hva Defender CSPM nå faktisk dekker for serverløse containere
Konkret betyr GA-lanseringen at Container Apps får tre typer beskyttelse de tidligere manglet i Defender-porteføljen. Det første er miljøherding: policybaserte sjekker for ting som privilegerte containere, usikre kapabiliteter og svak tilgangsstyring, tilpasset applikasjonsmiljønivået siden Container Apps ikke eksponerer en full Kubernetes-API. Det andre er agentløs sårbarhetsvurdering av bilder, som skanner containerbildet mot kjente CVE-er dersom det ligger i et støttet register som Azure Container Registry, Docker Hub eller JFrog Artifactory. Det tredje er integrering med Azure Policy, slik at funn kan håndheves automatisk fremfor å bare vises som anbefaling i en portal ingen leser.
Det som fortsatt mangler, sammenlignet med full Defender for Containers på AKS, er en dedikert runtime-agent for Container Apps. Microsofts egen støttematrise plasserer serverløse containere under agentløs skanning og CSPM, ikke under sanntids kjøretidsdeteksjon slik AKS-klynger med agent installert har. Det er en bevisst avveining: Container Apps er designet for å være operasjonelt enkelt, og en obligatorisk sikkerhetsagent i hver arbeidslast ville motvirke nettopp det poenget.
Hva det koster: Defender-prising for serverløse containere
Prismodellen skiller mellom to Defender-planer. Defender for Containers, som dekker AKS, faktureres per vCore i Kubernetes-arbeidernodene, historisk priset til rundt 7 dollar per vCore i måneden med 20 gratis skanninger inkludert, og 0,29 dollar per ekstra bildeskanning utover det. Defender CSPM, som er planen Container Apps nå faller inn under, faktureres derimot som en egen ressurskategori kalt «serverløse containere», sammen med virtuelle maskiner, lagringskontoer og databaser i planen. Det gir en fundamentalt annen kostnadsstruktur: du betaler ikke per vCore i en klynge du selv drifter, men som en egen linje i CSPM-faktureringen basert på antall serverløse containerressurser.
For selskaper med blandet miljø, altså både AKS og Container Apps, betyr det to separate kostnadslinjer å holde styr på i Azure-fakturaen. Defender for Cloud er for øvrig gratis de første 30 dagene per ressurs, slik at team kan teste dekningen på et representativt Container Apps-miljø før de forplikter seg til full fakturering.
Tidslinje: containersikkerhet i Azure gjennom 2025 og 2026
| Dato | Hendelse | Betydning |
|---|---|---|
| 21. september 2025 | AKS fjerner enableCustomCATrust fra API-versjon 20250902-preview | Første steg mot pensjonering, GA-mekanisme innføres parallelt |
| 17. juli 2026 | Azure/AKS publiserer utgivelsesnotat om pensjonering | Formell varsling med konkret sluttdato satt |
| 13. august 2026 | AWS FinOps Agent diskuteres på FinOps X 2026 | Viser parallell trend: skyleverandører automatiserer drift med KI-agenter |
| 1. september 2026 | Defender for Cloud blir GA for Azure Container Apps | Serverløse containere får CSPM-dekning og bildeskanning |
| 14. september 2026 | enableCustomCATrust pensjoneres endelig i AKS | Klynger uten migrering risikerer skalerings- og sertifikatfeil |
Konkurrentbildet: hvordan AWS og Google Cloud løser det samme problemet
Microsoft er ikke alene om å utvide sikkerhetsdekningen til serverløse containere. AWS løser dette hovedsakelig gjennom GuardDuty, der EKS Protection overvåker Kubernetes-revisjonslogger for mistenkelig API-aktivitet, mens «Runtime Monitoring» går dypere og gir innsyn i filtilgang, prosesskjøring og nettverkstrafikk inne i containeren. Det gode med AWS sin modell er at Runtime Monitoring også dekker ECS-oppgaver som kjører på Fargate, altså AWS sin motsvarighet til Container Apps. Det gir reell kjøretidsdeteksjon for serverløse containere, noe Azure foreløpig mangler for Container Apps.
Google Cloud har på sin side bygget et sikkerhetsposisjon-dashbord for GKE, der klynger meldes inn til skanning og funn vises i en egen «bekymringer»-visning, kategorisert etter blant annet konfigurasjonsfeil. Dashbordet gir konkrete anbefalinger til endringer i podspesifikasjoner eller klyngekonfigurasjon. For Cloud Run, som er Googles motstykke til Container Apps, er dekningen derimot tynnere: sikkerheten lener seg mer på bildeskanning gjennom Artifact Registry og Binary Authorization enn på et dedikert posisjonsdashbord bygget for den serverløse tjenesten spesifikt.
| Funksjon | Azure (Container Apps) | AWS (Fargate/ECS) | Google Cloud (Cloud Run) |
|---|---|---|---|
| Posisjonshåndtering / CSPM | Defender CSPM, GA fra 1. sept. 2026 | Security Hub + GuardDuty-funn | Sikkerhetsposisjon-dashbord primært for GKE |
| Kjøretidsdeteksjon i selve containeren | Ikke dedikert agent for Container Apps | GuardDuty Runtime Monitoring dekker Fargate | Begrenset for Cloud Run spesifikt |
| Bildeskanning mot CVE-er | Agentløs VA mot ACR, Docker Hub, Artifactory | ECR-skanning pluss tredjepartsverktøy | Artifact Registry + Container Analysis |
| Prismodell | Egen CSPM-ressurskategori for serverløse containere | Inkludert i GuardDuty-plan per konto/region | Delvis inkludert, delvis tilleggstjeneste |
| Anbefalt for | Team som vil unngå å drifte Kubernetes-API | Team som allerede står på ECS/Fargate | Enkle, hendelsesdrevne arbeidslaster |
Markedet: containersikkerhet vokser raskere enn resten av cybersikkerhet
Bevegelsen hos Microsoft, AWS og Google skjer i et marked som vokser uvanlig fort. Analyseselskaper anslår det globale markedet for containersikkerhet til mellom 2,96 og 3,69 milliarder dollar i 2026, opp fra rundt 2,43 til 3,06 milliarder dollar i 2025, med en årlig vekstrate på 20 til 22 prosent frem mot 2031. Det er godt over veksttakten for cybersikkerhetsmarkedet som helhet. Det bredere Kubernetes-markedet er anslått til 3,13 milliarder dollar i 2026, der administrerte tjenester som AKS, EKS og GKE utgjør rundt 62 prosent av forbruket, ifølge markedsanalyser publisert i 2026.
Det som driver veksten er ikke bare frykt for enkelthendelser, men en bredere konsolideringstrend. Virksomheter samler i økende grad CSPM, container-skanning, hemmelighetsdeteksjon og kjøretidsbeskyttelse i én plattform, ofte omtalt som CNAPP (Cloud-Native Application Protection Platform), fremfor å kjøpe punktløsninger fra ulike leverandører. En bransjerapport fra Red Hat om tilstanden for skynativ sikkerhet i 2026 finner at over 60 prosent av organisasjonene planlegger å investere i automatisert sikkerhet i CI/CD-rørledninger, mens 56 prosent prioriterer integritet i programvareforsyningskjeden fra kode til kjøretid. 64 prosent oppgir at EU sin Cyber Resilience Act forventes å være en hoveddriver for sikkerhetsinvesteringer i 2026.
Norge og Norden: hva skyadopsjonen betyr for denne endringen
Norge har en av de høyeste skyadopsjonsratene i Europa. Ifølge tall referert i bransjeanalyser for 2026 bruker rundt 78 prosent av norske virksomheter skytjenester, med samlet skyforbruk anslått til om lag 2,4 milliarder dollar. AWS har den enkeltstørste andelen av det norske skymarkedet med rundt 35 prosent, mens Azure og Google Cloud deler resten sammen med mindre leverandører. Statistisk sentralbyrå har i flere år dokumentert en jevn økning i skybruk på tvers av norske bransjer, en trend som gjør containersikkerhet til noe langt flere norske IT-avdelinger må forholde seg til enn for bare noen år siden.
For nordiske virksomheter med blandet Azure-portefølje, altså både AKS-klynger driftet internt og nyere Container Apps-arbeidslaster satt opp av utviklerteam som ville unngå Kubernetes-kompleksitet, faller de to fristene sammen på en måte som krever koordinering mellom plattformteam og applikasjonsteam. Plattformteamet må rydde opp i enableCustomCATrust før 14. september, mens applikasjonsteamet bør aktivere og gå gjennom Defender CSPM-funn for Container Apps så snart planen er slått på, siden førstegangs skanning typisk avdekker en bunke eksisterende feilkonfigurasjoner som har ligget skjult.
Historisk kontekst: fra Kubernetes-fokus til multiskyplattform
Defender for Cloud startet som en Azure-spesifikk sikkerhetstjeneste bygget rundt Azure Security Center. Over tid har Microsoft bygget den ut til å dekke AWS og Google Cloud også, ikke bare Azure, og til å inkludere multicloud-arbeidslaster i samme portal. Utvidelsen til Container Apps er et logisk neste steg i den samme retningen: fra å være en Kubernetes-sentrert løsning til å dekke hele spekteret av containeriserte kjøremiljøer, uavhengig av om kunden administrerer en full klynge eller kjører helt serverløst.
Det samme mønsteret ser vi hos konkurrentene. AWS bygde opprinnelig GuardDuty rundt EC2 og VPC-trafikk, før EKS Protection og siden Runtime Monitoring for Fargate kom på plass. Google Cloud sitt sikkerhetsposisjon-dashbord startet som et GKE-verktøy og utvides gradvis mot Cloud Run og andre serverløse tjenester. Ingen av de tre store skyleverandørene har foreløpig full paritet mellom sin Kubernetes-sikkerhet og sin serverløse containersikkerhet, men gapet krymper år for år, drevet av at kundene selv flytter stadig mer produksjonstrafikk til de serverløse variantene.
Det er verdt å minne om hvor fort denne kategorien har beveget seg. For bare fem år siden var «serverløse containere» stort sett synonymt med enkle webhooks og korte batch-jobber, noe utviklere satte opp uten å tenke på sikkerhetsposisjon i det hele tatt. I dag kjører selskaper hele produksjonstjenester, inkludert betalingsflyt og kundedata, på Container Apps, Fargate og Cloud Run. Den forskyvningen er selve grunnen til at Microsoft, AWS og Google nå bygger ut posisjonsstyring og sårbarhetsskanning for tjenester som opprinnelig ble solgt inn som «bare kjør koden din, vi tar oss av resten». Når arbeidslaster med reell forretningsrisiko flyttes dit, følger sikkerhetskravene automatisk etter, uansett hvor mye leverandørene i utgangspunktet ønsket å holde plattformen enkel.
Hva bedrifter i Norden bør gjøre nå
- Søk gjennom alle AKS-klynger etter noder med enableCustomCaTrust satt til true, og planlegg migrering til –custom-ca-trust-certificates før 14. september 2026.
- Oppdater Terraform-, Bicep- eller ARM-maler slik at de kun bruker stabile AKS-API-versjoner, siden AzureRM-provideren allerede har fjernet støtte for det gamle forhåndsvisningsfeltet i versjon 4.x.
- Aktiver Defender CSPM for eksisterende Container Apps-miljøer og gå gjennom førstegangsfunnene sammen med applikasjonsteamet, ikke bare plattformteamet.
- Prioriter oppdatering mot containerd-sårbarhetene med CVSS 9,6 og 7,8 dersom klyngen kjører images fra ubetrodde eller eksterne kilder.
- Sammenlign faktisk kostnad mellom Defender for Containers (vCore-basert) og Defender CSPM (ressursbasert) før dere skalerer opp blandede AKS/Container Apps-miljøer, siden fakturamodellen er forskjellig.
Spådommer: hva skjer videre med containersikkerhet i skyen
For det første vil Microsoft trolig utvide kjøretidsdeteksjon, ikke bare agentløs skanning, til Container Apps i løpet av 2027, for å lukke gapet mot AWS sin Runtime Monitoring for Fargate. Presset fra kunder som kjører produksjonstrafikk uten Kubernetes-API vil gjøre det vanskelig å la det stå som en ren CSPM-løsning over tid.
For det andre vil flere leverandører fase ut forhåndsvisningsflagg til fordel for stabile GA-mekanismer, slik AKS nå gjør med enableCustomCATrust. Mønsteret med å bygge kritisk sikkerhetsfunksjonalitet på et forhåndsvisningsflagg har vist seg for skjørt, og bransjen beveger seg mot at slike funksjoner må være GA før virksomheter tar dem i produksjonsbruk.
For det tredje vil containersikkerhetsmarkedet trolig fortsette å vokse over 20 prosent årlig frem mot 2028, drevet av EU sin Cyber Resilience Act og tilsvarende regulering som tvinger frem dokumentert sårbarhetshåndtering i programvareforsyningskjeden, ikke bare frivillig beste praksis.
For det fjerde vil flere norske og nordiske virksomheter trolig konsolidere sikkerhetsverktøy inn i én CNAPP-plattform fremfor å kjøre separate punktløsninger for CSPM, bildeskanning og kjøretidsbeskyttelse, i tråd med konsolideringstrenden analytikere allerede ser globalt.
For det femte er det sannsynlig at flere kritiske CVE-er i containerruntime-laget, i stil med containerd- og Moby-funnene fra 2026, vil dukke opp i 2027, ettersom sikkerhetsforskere nå har rettet søkelyset mot nettopp dette laget etter å ha funnet flere alvorlige feil på kort tid.
Ofte stilte spørsmål
Må jeg betale ekstra for Defender-dekning av Azure Container Apps?
Ja, utover den første gratis 30-dagersperioden per ressurs faktureres Container Apps som en egen ressurskategori under Defender CSPM-planen, atskilt fra hvordan AKS faktureres per vCore under Defender for Containers.
Hva skjer hvis jeg ikke fjerner enableCustomCATrust før 14. september 2026?
Flagget slutter å ha effekt. Noder som skaleres opp etter fristen kan mangle riktig tillit til den interne sertifiseringsinstansen, og sertifikatfornyelser kan feile på berørte noder, ifølge Microsofts egne utgivelsesnotater.
Er Azure Container Apps eller AKS mest utsatt for de nye CVE-ene?
Sårbarhetene i containerd, Docker/Moby og Kata Containers rammer selve kjøretidslaget, og relevansen avhenger av hvilken kjøretidsteknologi den underliggende infrastrukturen bruker, ikke av om du bruker AKS eller Container Apps direkte. Begge tjenestetypene bør oppdateres i tråd med Microsofts patching-tidslinje.
Hvordan skiller AWS sin løsning seg fra Azures for serverløse containere?
AWS sin GuardDuty Runtime Monitoring gir sanntids kjøretidsdeteksjon for ECS-oppgaver på Fargate, mens Azure Defender CSPM for Container Apps foreløpig er begrenset til posisjonsstyring og agentløs bildeskanning, uten en tilsvarende dedikert kjøretidsagent for den serverløse tjenesten.
Påvirker dette Kubernetes-versjonen jeg kjører i AKS?
Nei, pensjoneringen av enableCustomCATrust gjelder et eget forhåndsvisningsfelt for sertifikattillit på nodenivå, uavhengig av hvilken Kubernetes-versjon klyngen kjører. Endringen krever likevel en egen oppdatering av nodepool-konfigurasjonen.
Hvor stort er containersikkerhetsmarkedet i 2026?
Analyser anslår markedet til mellom 2,96 og 3,69 milliarder dollar i 2026, med en forventet årlig vekstrate på 20 til 22 prosent frem mot begynnelsen av neste tiår, ifølge flere markedsrapporter publisert i 2026.
Bør norske virksomheter velge Container Apps eller AKS av sikkerhetshensyn?
Valget bør styres av operasjonelle behov, ikke bare sikkerhet. Container Apps krever mindre drift og passer godt for team uten dedikert Kubernetes-kompetanse, mens AKS gir tilgang til full Defender for Containers-dekning inkludert kjøretidsagent, noe som kan veie tungt for arbeidslaster med høyere risikoprofil.
