AWS satte 24. august 2026 i gang den mest omfattende sikkerhetsendringen for Elastic Kubernetes Service (EKS) på flere år. To ting skjer samtidig: identitetsgrensen for OIDC-leverandører per klynge dobles fra fem til ti, og en ny sertifiseringsmekanisme tvinger frem automatisk rotasjon av rot-CA-en på alle EKS-klynger som er opprettet siden 2018. For norske og nordiske selskaper som kjører produksjonsklynger i offentlig sektor, finans og industri, er dette ikke en valgfri oppdatering. Den aktiveres uansett, og den treffer akkurat i det Norge legger siste hånd på implementeringen av EU AI Act og naboland som Sverige har fått en ny, streng cybersikkerhetslov på plass.
Saken er interessant fordi den kobler tre ting som sjelden møtes i samme nyhetssak: infrastruktursikkerhet på kontrollplan-nivå, identitetshåndtering for flerpartsorganisasjoner, og et regulatorisk klima i Norden som gjør at IT-avdelinger ikke lenger kan skyve sertifikatvedlikehold foran seg. Vi går gjennom hva som faktisk endres, hvorfor AWS gjør det nå, hvilke klynger som rammes hardest, og hvordan dette stiller seg opp mot tilsvarende grep hos Google og Microsoft i vår løpende dekning av skytjenester.
Hva AWS faktisk endret 20.-24. august 2026
Endringen kom i to separate kunngjøringer fra AWS i løpet av en firedagersperiode. Den 20. august ble en ny rotasjonsmodell for klyngens sertifiseringsinstans (CA) sluppet: EKS-klynger som er opprettet fra og med 2018, har en ti-årig levetid på rot-CA-en, og AWS legger nå automatisk til en etterfølgende CA to år før den opprinnelige utløper. Den nye CA-en aktiveres seks måneder før utløp, uavhengig av om klyngeeieren har forberedt seg eller ikke. Fire dager senere, 24. august, hevet AWS taket for eksterne identitetsleverandører (OIDC) per klynge til ti, opp fra det tidligere taket, og gjorde det kostnadsfritt. Begrensningen gjelder kun for klynger som kjører en Kubernetes-versjon nyere enn 1.32, så eldre klynger må oppgraderes før de kan dra nytte av endringen, noe som også har vært en pådriver bak EKS-støtten for Kubernetes 1.36 tidligere i år.
Det som gjør CA-rotasjonen spesiell, er ordet “uansett”. AWS har designet mekanismen slik at den aktiveres på et fast tidspunkt uavhengig av om driftsteamet har rukket å teste kompatibilitet med interne verktøy, sertifikatpinning eller tredjeparts-integrasjoner. For klynger som har kjørt siden lanseringen av EKS i 2018, betyr det at flere allerede nærmer seg midten eller den senere delen av sin ti-årige CA-syklus, og at forberedelsestiden før tvungen aktivering kan være kortere enn mange driftsteam regner med. Samtidig ble Ray on SageMaker HyperPod gjort generelt tilgjengelig samme dag som OIDC-utvidelsen, noe som kobler AI-arbeidslaster enda tettere til Kubernetes som kontrollplan. Oppsettet krever en EKS-klynge og operatøren KubeRay, pluss fem tilleggskomponenter som dashboard, IDE-tilkobling, Grafana-paneler og KV-cache-støtte.
Hvorfor identitetstaket på ti OIDC-leverandører betyr noe
OIDC-leverandører (OpenID Connect) er mekanismen Kubernetes bruker til å stole på eksterne identitetssystemer, slik at brukere og tjenester kan autentisere seg mot klyngen uten at man må vedlikeholde separate legitimasjoner inne i EKS. Frem til nå har taket på fem leverandører vært en praktisk begrensning for større organisasjoner som opererer flere forretningsenheter, partnere eller datterselskaper på samme klynge. En norsk offentlig etat med flere direktorater, eller et nordisk finanskonsern med datterselskaper i fire land, har typisk måttet bygge omveier: enten separate klynger per identitetsdomene, eller et eget mellomlag som oversetter identiteter før de når Kubernetes-API-et.
Med et tak på ti leverandører, kostnadsfritt, faller mye av begrunnelsen for slike omveier bort. Det er spesielt relevant for FinOps- og sikkerhetsteam i Norden, som har brukt betydelig tid på skreddersydd verktøy rundt identitetsføderering nettopp fordi standardgrensene var for trange. Endringen er derimot ikke bakoverkompatibel: den gjelder kun Kubernetes-versjoner over 1.32, så klynger som henger etter på versjon må gjennom en oppgradering før de kan høste gevinsten. Det legger et ekstra press på driftsteam som allerede har nok å gjøre med sertifikatrotasjonen.
CA-rotasjon: den tvungne klokken ingen kan stille
Det som skiller denne CA-rotasjonen fra vanlig sertifikatfornyelse, er automatikken. Historisk har mange organisasjoner behandlet rot-CA-rotasjon som en sjelden, planlagt hendelse man kan utsette til neste kvartal. AWS sin nye modell fjerner den fleksibiliteten: to år før utløp dukker en etterfølger-CA opp i klyngen, og seks måneder før utløp blir den aktivert, uavhengig av om applikasjoner, klient-sertifikater eller interne PKI-integrasjoner er klare. For klynger opprettet i 2018 eller tidlig i 2019 betyr det at flere norske og nordiske driftsmiljøer allerede befinner seg i det tidsvinduet der en etterfølger-CA kan dukke opp uten forvarsel utover det AWS har publisert i sin dokumentasjon.
Konsekvensen er mest merkbar for organisasjoner med strenge krav til sertifikatpinning, altså der applikasjoner eller integrasjoner er hardkodet til å stole på et spesifikt CA-fingeravtrykk i stedet for å følge klyngens rotstol dynamisk. Slike oppsett er vanlige i regulerte bransjer som bank, kraft og offentlig forvaltning, nettopp miljøene som er mest utbredt i Norge og Norden. Her blir jobben å kartlegge alle steder som pinner mot den gamle CA-en, oppdatere dem før seks-måneders-vinduet, og teste at rotasjonen ikke bryter interne overvåkings- eller autentiseringstjenester.
Tallene: hva som faktisk endres i EKS august 2026
| Endring | Før | Etter (fra 20.-24. august 2026) |
|---|---|---|
| OIDC-leverandører per klynge | 5 | 10, kostnadsfritt |
| Minimumsversjon for OIDC-utvidelse | Ikke aktuelt | Kubernetes nyere enn 1.32 |
| Levetid rot-CA (klynger fra 2018) | Manuell/variabel prosess | 10 år, fast syklus |
| Tid før utløp etterfølger-CA legges til | Ikke automatisert | 2 år før utløp |
| Tid før utløp ny CA aktiveres | Ikke automatisert | 6 måneder før utløp, automatisk |
| Ray on SageMaker HyperPod | Forhåndsversjon | Generelt tilgjengelig fra 24. august |
| Krav for HyperPod-oppsett | – | 1 EKS-klynge + KubeRay-operatør + 5 tilleggskomponenter |
Tabellen over oppsummerer kjernen i endringen. Det er verdt å merke seg at AWS sitt eget veikart for august ikke er fullt levert: av tre lovede Argo CD-relaterte konfigurasjonsinnstillinger for EKS er bare én sluppet per 21. august, ifølge gjennomgang av AWS sine egne oppdateringer. De resterende to er verken levert eller tydelig dokumentert med ny tidsplan, noe som er verdt å følge med på for team som planlegger GitOps-arbeidsflyt rundt Argo CD på EKS utover høsten.
Konkurransebildet: hvordan Azure og Google Cloud håndterer det samme problemet
AWS er ikke alene om å stramme inn identitets- og sertifikathåndtering for administrert Kubernetes. Azure Kubernetes Service (AKS) har i 2026 vært gjennom sin egen sikkerhetsrunde, med en sårbarhet vurdert til CVSS 9,4 som ble omtalt tidligere i år og som tvang frem patching av over 400 feil i tilstøtende komponenter. Google Cloud sin motpart, GKE, har på sin side kjempet med fire separate containerd-sårbarheter i samme periode, noe som rammer nesten alle containerkjøringer i klyngene deres. Det kommer i tillegg til en bredere bølge av CVE-er i andre Kubernetes-verktøy gjennom våren og sommeren. Mønsteret er tydelig: alle de tre store skyleverandørene bruker 2026 til å stramme inn kontrollplan-sikkerhet, men de velger ulike virkemidler.
Der Azure og Google i stor grad har reagert på konkrete sårbarheter etter at de er oppdaget, er AWS sin CA-rotasjon en proaktiv, strukturell endring som ikke er knyttet til en enkelt sårbarhet. Det er en vesentlig forskjell i tilnærming: AWS bygger inn tvungen hygiene i selve plattformen, mens konkurrentene i større grad har patchet reaktivt. For norske selskaper som kjører flerskyoppsett, betyr det at sikkerhetsteamet må forholde seg til tre ulike rytmer for sertifikat- og identitetsvedlikehold, avhengig av hvilken sky arbeidslasten kjører på.
Sammenligning: identitets- og sertifikathåndtering hos de tre store
| Leverandør | Tjeneste | Nylig sikkerhetsgrep i 2026 | Tilnærming |
|---|---|---|---|
| AWS | EKS | 10 OIDC-leverandører + tvungen 10-års CA-rotasjon | Proaktiv, strukturell, automatisert |
| Microsoft | AKS | CVSS 9,4-sårbarhet, 415 feil patchet | Reaktiv patching etter funn |
| Google Cloud | GKE | 4 containerd-sårbarheter patchet | Reaktiv patching, hyppige runder |
Selv om tabellen forenkler et komplekst bilde, illustrerer den hvorfor nordiske organisasjoner med flerskystrategi bør sette opp egne rutiner for hver plattform i stedet for å anta at samme sjekkliste dekker alle tre.
Historisk kontekst: fra selvsignerte CA-er til automatisert rotasjon
Da EKS ble lansert i 2018, var Kubernetes fortsatt et relativt ungt prosjekt der de fleste driftsteam håndterte klyngesertifikater manuelt eller med enkle skript. Standardpraksisen var lange levetider på klyngesertifikater og manuell rotasjon når noe gikk galt, ofte utløst av en utgått sertifikat-feilmelding midt i produksjon. Etter hvert som Kubernetes ble kjernen i stadig flere produksjonsmiljøer, inkludert kritisk infrastruktur i Norden, ble denne uformelle tilnærmingen en risiko i seg selv. Det er samme utvikling man har sett med TLS-sertifikater generelt: bransjen har gått fra flerårige levetider til kortere, automatiserte sykluser nettopp for å redusere skaden dersom en nøkkel kompromitteres.
AWS sin nye modell er et forsinket, men logisk neste steg i den utviklingen: i stedet for å stole på at hvert enkelt driftsteam husker å rotere en sjelden brukt rot-CA hvert tiende år, bygger AWS inn en fast, forutsigbar syklus direkte i plattformen. Det fjerner menneskelig glemsel som feilkilde, men det fjerner samtidig fleksibiliteten til å utsette rotasjonen dersom man ikke er klar. For organisasjoner som har bygget skjøre integrasjoner rundt antakelsen om at CA-en aldri endrer seg, er dette en vekker.
Hvorfor dette treffer Norge og Norden hardere enn andre regioner nå
Timingen er ikke tilfeldig ubeleilig. Norge jobber i sommer og høst 2026 med å sluttføre implementeringen av EU AI Act, noe som legger press på norske organisasjoner til å gjennomgå skybaserte AI-arbeidslaster, identitetshåndtering og databeskyttelse på nytt. Samtidig trådte Sveriges Cybersäkerhetslagen i kraft 15. januar 2026, og loven regnes som en av de mest omfattende NIS2-implementeringene i Europa, ifølge gjennomgang fra bransjenettverket NIC. Begge disse regulatoriske sporene peker i samme retning: dokumentert kontroll over identitet, sertifikater og kryptografisk hygiene i skyinfrastruktur.
Kravet kommer på toppen av en allerede skjerpet debatt om skysuverenitet i Norden, der både AWS og Azure har måttet svare på spørsmål om hvor data og nøkkelmateriale faktisk ligger. Det betyr at norske og svenske selskaper som rammes av AWS sin tvungne CA-rotasjon, ikke bare må håndtere den tekniske hendelsen. De må også kunne dokumentere overfor tilsynsmyndigheter at rotasjonen er planlagt, testet og ikke har skapt sikkerhetshull i overgangen. En etat eller bank som ikke har oversikt over egne EKS-klynger og deres CA-alder, risikerer å bli tatt på senga akkurat når NIS2-tilsyn og AI Act-krav skjerpes samtidig. Kombinasjonen av teknisk automatikk fra AWS og regulatorisk skjerpelse fra EU og nasjonale myndigheter gjør denne saken til mer enn en teknisk fotnote.
Markedseffekt: hva dette betyr for FinOps og sikkerhetsbudsjetter
For sikkerhets- og driftsbudsjetter i Norden gir endringen et blandet bilde. På den ene siden er den kostnadsfrie utvidelsen til ti OIDC-leverandører en direkte besparelse for organisasjoner som tidligere betalte for eller bygde selv identitetsføderering rundt det gamle taket på fem. Det frigjør ingeniørtid som ellers ville gått med til å vedlikeholde skreddersydde løsninger. På den andre siden krever CA-rotasjonen en engangsinnsats: kartlegging av alle klynger opprettet siden 2018, identifisering av sertifikatpinning, og testing av at applikasjoner tåler byttet av rot-CA uten nedetid.
Denne typen engangsinnsats er nøyaktig det FinOps-team i Norden har begynt å budsjettere for som en fast kostnad ved å drifte skyinfrastruktur i stor skala, på samme måte som periodisk oppgradering av Kubernetes-versjoner. Samtidig kobler lanseringen av Ray on SageMaker HyperPod samme dag som OIDC-utvidelsen, EKS enda tettere til AI-arbeidslaster. Det er relevant fordi det øker antallet kritiske tjenester som er avhengige av at identitets- og sertifikatlaget i EKS fungerer feilfritt. Jo mer AI-trening og AI-inferens som flyttes inn i Kubernetes, desto dyrere blir det å håndtere identitets- og sertifikatfeil dårlig.
Wasm og edge: den lengre linjen i skyarkitektur i 2026
EKS-endringene skjer også i en bredere kontekst der Kubernetes i økende grad omtales som et universelt kontrollplan for både containere og serverløse funksjoner. Trendanalyser fra august 2026 peker på WebAssembly (Wasm) som et voksende alternativ for edge- og serverløse arbeidslaster, med kaldstarter under ett millisekund og binærstørrelser på rundt 2 MB. Det er spesielt relevant for nordiske miljøer med begrenset båndbredde, som avsidesliggende industrianlegg langs norskekysten eller i Nord-Sverige, der lav ventetid og små binærfiler er en praktisk fordel fremfor teoretisk finesse.
Samtidig blir flerskymønstre stadig mer vanlig. AWS og Google Cloud har lansert et felles initiativ for å forenkle flerskydrift, og Azure ventes å slutte seg til senere i 2026. For nordiske selskaper som allerede balanserer EKS, AKS og GKE side om side, betyr det at identitets- og sertifikatpolitikk må designes med tanke på at arbeidslaster kan flytte seg, eller kommunisere på tvers av, flere skyer samtidig. Et sikkerhetsregime som bare er tilpasset én leverandørs rotasjonssyklus, holder ikke lenger.
Praktiske steg for norske driftsteam
Første steg er å kartlegge når hver EKS-klynge i organisasjonen ble opprettet, og dermed hvor i den ti-årige CA-syklusen den befinner seg. Klynger fra 2018 og 2019 bør prioriteres først, siden de har kortest tid igjen til tvungen aktivering av etterfølger-CA-en. Deretter bør teamet søke gjennom kodebase og konfigurasjon etter sertifikatpinning mot den eksisterende rot-CA-en, siden dette er der rotasjonen kan skape brudd som er vanskelige å feilsøke i produksjon.
# Sjekk Kubernetes-versjon for å avgjøre om OIDC-utvidelsen gjelder
kubectl version --short
# List identitetsleverandører knyttet til klyngen
aws eks describe-cluster --name MIN-KLYNGE \
--query "cluster.identity.oidc.issuer"
# Sjekk opprettelsesdato og status for klyngens sertifikat
aws eks describe-cluster --name MIN-KLYNGE \
--query "cluster.{Opprettet:createdAt,Status:status}"
Deretter bør Kubernetes-versjonen oppgraderes til over 1.32 der det er mulig, slik at organisasjonen faktisk kan nyttiggjøre seg det utvidede OIDC-taket fremfor bare å bli rammet av CA-rotasjonen uten å høste fordelene. Til sist bør sikkerhetsteamet dokumentere hele prosessen med tanke på NIS2- og AI Act-relatert revisjon, siden tilsynsmyndigheter i økende grad ber om konkret bevis på at kryptografisk hygiene er en styrt prosess og ikke en tilfeldighet.
Fem spådommer for EKS-sikkerhet og identitet fremover
- Azure og Google Cloud vil trolig følge etter med egne automatiserte CA-rotasjonsmodeller for AKS og GKE i løpet av 2027, for å matche AWS sin proaktive tilnærming.
- Flere norske og svenske myndighetsorganer vil kreve dokumentert sertifikat- og identitetsstyring som en del av NIS2-tilsyn allerede i løpet av 2026 og 2027.
- Bruken av OIDC-føderering med ti eller flere identitetsleverandører per klynge vil bli standard i nordiske finanskonsern med flere datterselskaper innen utgangen av 2027.
- AWS vil trolig levere de to gjenstående Argo CD-konfigurasjonsinnstillingene innen utgangen av 2026, gitt presset fra GitOps-brukere.
- Kombinasjonen av Ray on SageMaker HyperPod og utvidet OIDC-støtte vil gjøre EKS til et enda mer utbredt fundament for AI-arbeidslaster i nordisk offentlig sektor og industri gjennom 2027.
Hva IT-ledere i Norden bør prioritere denne høsten
Kortsiktig handler dette om å unngå overraskelser: vite hvilke klynger som rammes, når etterfølger-CA-en dukker opp, og hvilke interne systemer som må testes på forhånd. Middels sikt handler det om å utnytte det utvidede OIDC-taket til å forenkle identitetsarkitektur som i dag er unødvendig komplisert på grunn av gamle begrensninger. Langsiktig handler det om å bygge en driftsmodell der sertifikat- og identitetsrotasjon behandles som en forventet, syklisk hendelse på linje med Kubernetes-versjonsoppgraderinger, ikke som en krise når AWS, Microsoft eller Google bestemmer seg for å stramme inn.
Norske og nordiske organisasjoner som kommer tidlig i gang med kartlegging, står bedre rustet både teknisk og regulatorisk enn de som venter til seks-måneders-varselet fra AWS blir en akutt driftshendelse. Kildene til denne saken inkluderer AWS sin offisielle EKS-dokumentasjon, gjennomgang av EKS-oppdateringene fra ecorpIT, Kloudping sin analyse av skytrender for august 2026, NIC sin oversikt over nordisk cybersikkerhetsregulering, og IO+ sin gjennomgang av europeisk sky- og AI-infrastruktur.
Ofte stilte spørsmål om EKS-sikkerhetsendringene i 2026
Må jeg gjøre noe med min EKS-klynge nå?
Hvis klyngen ble opprettet i 2018 eller 2019, bør du kartlegge CA-alder og eventuell sertifikatpinning nå, siden aktiveringsvinduet på seks måneder kan være nærmere enn du tror.
Koster det noe å bruke ti OIDC-leverandører per klynge?
Nei, AWS har gjort utvidelsen fra fem til ti leverandører kostnadsfri, men den krever at klyngen kjører en Kubernetes-versjon nyere enn 1.32.
Kan jeg utsette CA-rotasjonen hvis jeg ikke er klar?
Nei. Mekanismen aktiverer den nye CA-en automatisk seks måneder før den gamle utløper, uavhengig av om driftsteamet har testet konsekvensene.
Påvirker dette klynger med eldre Kubernetes-versjon enn 1.32?
CA-rotasjonen gjelder alle EKS-klynger fra 2018 og fremover, uavhengig av versjon. Det utvidede OIDC-taket på ti leverandører krever derimot versjon nyere enn 1.32.
Hvordan skiller dette seg fra Azure AKS og Google GKE sine sikkerhetsgrep i 2026?
Azure og Google har i hovedsak patchet konkrete sårbarheter etter at de er oppdaget, som CVSS 9,4-feilen i AKS og de fire containerd-sårbarhetene i GKE. AWS sin CA-rotasjon er derimot en strukturell, proaktiv endring som ikke er utløst av en enkeltstående sårbarhet.
Hvorfor er dette spesielt relevant for norske og nordiske selskaper nå?
Fordi Norge samtidig sluttfører implementeringen av EU AI Act, og Sverige har innført en av Europas mest omfattende NIS2-implementeringer gjennom Cybersäkerhetslagen fra 15. januar 2026. Begge legger press på dokumentert kontroll over identitet og sertifikater i skyinfrastruktur.
Hva har Ray on SageMaker HyperPod med dette å gjøre?
Tjenesten ble gjort generelt tilgjengelig samme dag som OIDC-utvidelsen og krever en EKS-klynge og KubeRay-operatøren. Det knytter stadig flere AI-arbeidslaster til EKS sitt identitets- og sertifikatlag, som gjør det viktigere at dette laget fungerer feilfritt.
