En sikkerhetsforsker fant ut at tre linjer YAML-kode er nok til å ta over en hel Google Cloud-organisasjon. Ingen passord, ingen stjålet nøkkel, bare tilgang til ett eneste Kubernetes-navnerom. Funnet fikk navnet ConfigConfusion, og historien rundt det har utviklet seg til noe langt større enn en teknisk feil: en åpen konflikt mellom en uavhengig forsker og Google om hva som egentlig regnes som en sårbarhet.
Saken ble først omtalt av The Register 18. juni 2026, men eksploderte i internasjonale medier igjen 23. til 25. september etter at Varonis publiserte en fullstendig teknisk gjennomgang. For skyteam i Norge og resten av Norden, der Google Cloud vinner terreng som plattform for containerdrift og AI-arbeidslaster, er saken en påminnelse om at IAM-modellen i Kubernetes-operatører kan skjule store hull selv når hver enkelt komponent fungerer nøyaktig som dokumentert.
Hva er ConfigConfusion?
ConfigConfusion er navnet forsker Justin O’Leary ga sin oppdagelse i Google Kubernetes Config Connector (KCC), et populært tillegg som lar utviklere opprette Google Cloud-ressurser gjennom vanlige Kubernetes-manifester i stedet for å logge inn direkte i Google Cloud Console. Config Connector kjører som en kontroller inne i en GKE-klynge, leser YAML-filer utviklere legger inn, og oversetter dem til API-kall mot Google Cloud IAM på utviklerens vegne.
Poenget med oppsettet er godt: utviklere trenger aldri egne Google Cloud-nøkler, og plattformteamet slipper å administrere hundrevis av spredte servicekonto-nøkler i kodebaser og bygge-pipeliner. Denne typen “hemmelighetsspredning” regnes normalt som et av de vanskeligste problemene i skysikkerhet å rydde opp i. Config Connector løser det ved å gi kontrolleren selv én sterk identitet som håndterer alt.
Problemet oppstår når den ene identiteten har for mye makt. Ifølge Varonis-forsker Sivan Zohar-Kotzer, som bygget videre på O’Learys opprinnelige funn i et blogginnlegg publisert 25. august 2026, kan Config Connectors tjenestekonto ofte få roller som roles/owner eller roles/resourcemanager.organizationAdmin på organisasjonsnivå, fordi kontrolleren i praksis må forvalte ressurser på tvers av mange prosjekter og mapper. Når den tilgangen kombineres med at vanlige utviklere kan opprette IAM-relaterte ressurser i navnerommene sine, oppstår en vei fra begrenset klyngetilgang til full organisasjonskontroll.
Slik fungerer angrepet mot GKE Config Connector
Angrepet krever overraskende lite. En bruker med vanlig kubectl-tilgang til ett navnerom, uten en eneste Google Cloud-tillatelse, kan sende inn en IAMPolicyMember-ressurs som ber Config Connector gi en konto eieren-rollen på hele organisasjonen. Fordi Config Connector alltid handler gjennom sin egen privilegerte tjenestekonto, sjekker den ikke om personen som sendte inn forespørselen egentlig har rett til å be om den endringen.
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
name: eskalering
namespace: mitt-team
spec:
member: "serviceAccount:[email protected]"
role: roles/owner
resourceRef:
apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
kind: Organization
external: "123456789"I en video som demonstrerer teknikken viste O’Leary hvordan tre linjer YAML gir full administrativ kontroll over en GCP-organisasjon på rundt fem sekunder, ifølge The Register. Angriperen trenger aldri å etterligne en bruker eller stjele en nøkkel. Config Connector gjør jobben selv, fordi den ikke skiller mellom en forespørsel fra en klareringsverdig plattformadministrator og en forespørsel fra en tilfeldig utvikler med skrivetilgang til én mappe.
To autorisasjonssystemer, ett hull ingen sjekket
Kjernen i problemet er at Kubernetes RBAC og Google Cloud IAM opererer som to helt separate systemer som aldri snakker sammen. Kubernetes RBAC sjekker bare om en bruker har lov til å opprette en gitt ressurstype i et gitt navnerom. Den vet ingenting om hva ressursen faktisk fører til utenfor klyngen. Google Cloud IAM på sin side sjekker bare om Config Connectors tjenestekonto har lov til å utføre handlingen den blir bedt om. Den vet ingenting om hvilken menneskelig bruker som opprinnelig trigget forespørselen.
Resultatet er et klassisk eksempel på det sikkerhetsmiljøet kaller et “confused deputy”-problem: en aktør med bred makt handler på vegne av noen med langt mindre makt, uten noen mekanisme som kobler de to sammen. O’Leary formulerte det slik overfor The Register: sårbarheten er den manglende autorisasjonssjekken, fordi Config Connector utfører privilegerte operasjoner på vegne av brukere uten å bekrefte at de faktisk har rett til det. Han pekte også på at det ikke finnes noe revisjonsspor som viser hvilken opprinnelig bruker som utløste en gitt IAM-endring, se The Registers gjennomgang av saken.
Tidslinjen: fra “nice catch” til avslått belønning
Det som gjør ConfigConfusion spesielt betent, er ikke bare teknikken, men hvordan Google har håndtert rapporten. O’Leary meldte inn funnet 8. mars 2026. Nitten dager senere, 27. mars, godkjente en sikkerhetsingeniør hos Google saken og klassifiserte den som prioritet P1 og alvorlighetsgrad S1, det høyeste nivået som signaliserer at feilen rammer en stor andel brukere og kan forstyrre kjernefunksjoner i en organisasjon. Ingeniøren skal ifølge O’Leary ha skrevet “Nice catch!” i tilbakemeldingen.
Elleve dager senere, 7. april, snudde en automatisert bot fra Googles sårbarhetsbelønningsprogram avgjørelsen. Meldingen O’Leary mottok, og som The Register har sett, konkluderte med at saken ikke oppfylte kriteriene for en belønning fordi programvaren “fungerer som tiltenkt”. Nesten tre måneder senere, da The Register publiserte saken 18. juni, sto saken fortsatt registrert internt hos Google som P1/S1 med status “pågår (godkjent)”, uten at det var tildelt et CVE-nummer eller utgitt en rettelse.
| Dato | Hendelse |
|---|---|
| 8. mars 2026 | Justin O’Leary rapporterer ConfigConfusion til Google via bug bounty-programmet |
| 27. mars 2026 | Google klassifiserer saken som P1/S1 og skriver “Nice catch!” til forskeren |
| 7. april 2026 | Googles belønningspanel reverserer og avslår utbetaling, kaller det “working as intended” |
| 18. juni 2026 | The Register publiserer den første offentlige saken om ConfigConfusion |
| 25. august 2026 | Varonis publiserer teknisk dybdeartikkel skrevet av Sivan Zohar-Kotzer |
| 23.–25. september 2026 | BleepingComputer og flere sikkerhetsmedier plukker opp saken på nytt |
Saken er heller ikke O’Learys første runde med en stor skyleverandør. Han hadde tidligere en lignende opplevelse med Microsoft, der han meldte inn en privilegie-eskalering i Azure Backup for AKS. Microsoft avviste også den rapporten, for deretter å rette feilen stille uten å tildele et CVE-nummer eller publisere et sikkerhetsvarsel. O’Leary omtalte dette overfor The Register som et gjennomgående mønster hos store skyselskaper når uavhengige forskere finner kritiske hull i mye brukt infrastruktur.
Googles offisielle svar: “fungerer som tiltenkt”
Da The Register konfronterte Google direkte, kom svaret fra en talsperson som forklarte at IAM-omgåelsen bare er utnyttbar dersom en angriper allerede har tilgang til en Config Connector-tjenestekonto som organisasjonen selv har gitt rollen Organization Admin. Talspersonen la til at en angriper først må skaffe seg tilgang til et miljø, for eksempel via en eksponert container, før den privilegerte Config Connector-instansen kan misbrukes, og at å gi et slikt nivå av tilgang til tjenestekontoen strider mot Google Clouds egne anbefalte praksiser om minste privilegium.
Det er en teknisk korrekt beskrivelse, men den overser et sentralt poeng som både O’Leary og Varonis peker på: Googles egen dokumentasjon instruerer administratorer i hvordan de setter opp nettopp den organisasjonsbrede tilgangen som gjør angrepet mulig, fordi Config Connector i mange oppsett faktisk trenger å forvalte ressurser på tvers av flere prosjekter og mapper. Å ha de tillatelsene betyr ikke at enhver bruker i et hvilket som helst navnerom bør kunne utnytte dem, som O’Leary formulerte det. Varonis beskriver samme dynamikk som at Google kaller det en funksjon fremfor en feil, fordi konfigurasjonen teknisk sett gjør nøyaktig det administratoren ba om, selv om dokumentasjonen aldri tydeliggjør koblingen mellom de to valgene.
Hvorfor er ConfigConfusion så vanskelig å fikse?
Den mest åpenbare løsningen høres enkel ut: sjekk om den opprinnelige Kubernetes-brukeren faktisk har den tilsvarende Google Cloud-tillatelsen før Config Connector utfører handlingen. Problemet er at hele poenget med Config Connector er at utviklere aldri får en egen Google Cloud-identitet. Å innføre en slik sjekk ville enten kreve at hver utvikler får sin egen skyidentitet, noe som undergraver designet Config Connector er bygget rundt, eller at kontrolleren slår opp brukerens rettigheter ved hver eneste synkronisering, noe som legger til ekstra autorisasjonslogikk og API-kall i hver eneste rekonsileringssyklus.
Googles anbefalte tiltak handler derfor ikke om å endre hvordan Config Connector autoriserer hver forespørsel, men om å redusere hvor mye makt som i utgangspunktet legges i kontrollerens tjenestekonto. Det flytter ansvaret over på hver enkelt kunde, som må vurdere en avveining mellom operasjonell bekvemmelighet og eksponering, i stedet for at plattformen har innebygde rekkverk som gjelder uansett kundens oppsett.
Samme risiko i AWS og Azure?
Confused deputy-problemet Config Connector illustrerer, er ikke unikt for Google Cloud. Enhver infrastrukturkontroller som mottar instruksjoner fra én identitet og utfører dem gjennom en annen, kan i teorien skape det samme gapet. Det som varierer mellom skyleverandørene, er hvor mye makt kontrolleren normalt får, og hvor lett den makten kan avgrenses.
AWS Controllers for Kubernetes (ACK) deler opp kontrollerne per tjeneste. IAM, Amazon S3 og Amazon EC2 har hver sin egen kontroller med en IAM-rolle avgrenset til akkurat den tjenesten. En bruker som klarer å manipulere forespørselsbanen til S3-kontrolleren kan i verste fall påvirke S3-ressurser, men ikke gjøre IAM-endringer, fordi den rollen rett og slett ikke har den tillatelsen. Azure Service Operator v2 lar administratorer knytte en egen administrert identitet til hvert Kubernetes-navnerom, noe som gir et praktisk verktøy for å begrense skade per team fremfor å legge all makt bak én identitet for hele klyngen.
| Plattform | Kontroller | Identitetsmodell | Eksponering ved feilkonfigurasjon |
|---|---|---|---|
| Google Cloud (GKE) | Config Connector (KCC) | Én delt tjenestekonto per instans, kan ha organisasjonsnivå-rettigheter | Potensielt full organisasjonskontroll via ett enkelt navnerom |
| AWS | AWS Controllers for Kubernetes (ACK) | Egen IAM-rolle per tjenestekontroller (S3, EC2, IAM osv.) | Begrenset til tjenesten den aktuelle kontrolleren styrer |
| Microsoft Azure | Azure Service Operator v2 | Egen administrert identitet kan knyttes til hvert navnerom | Kan avgrenses per team, men krever aktivt oppsett |
Ingen av de tre modellene fjerner confused deputy-risikoen helt. Forskjellen ligger i hvor mye skade et misbrukt navnerom kan gjøre før noen oppdager det, og det er nettopp den forskjellen som gjør Config Connectors organisasjonsbrede standardmønster spesielt farlig sammenlignet med konkurrentene.
Historisk kontekst: confused deputy-problemer i skyen
Confused deputy-mønsteret er langt eldre enn Kubernetes. Begrepet stammer fra klassisk datasikkerhetsteori og beskriver generelt en situasjon der et program med høyere privilegier blir lurt til å utføre en handling på vegne av en aktør med lavere privilegier. I skysammenheng har mønsteret dukket opp gjentatte ganger i takt med at infrastruktur-som-kode og GitOps har blitt standard arbeidsmåte, fordi nettopp den arbeidsflyten bygger på at kontrollere og operatorer får bred makt for å slippe menneskelig inngripen ved hver endring.
Det som gjør ConfigConfusion til et interessant tilfelle å studere, er at det ikke krever en programvarefeil i tradisjonell forstand. Ingen minnefeil, ingen usikret endepunkt, ingen glemt patch. Hele angrepskjeden består av to systemer som hver for seg fungerer helt korrekt, men som til sammen skaper et hull fordi ingen av dem har det fulle bildet. Den typen sårbarhet er notorisk vanskelig å fange opp med tradisjonell sårbarhetsskanning, fordi skanneverktøy typisk leter etter kjente signaturer og feilkonfigurasjoner, ikke etter logiske brister i samspillet mellom to separate autorisasjonsmodeller.
Markedskonsekvenser for Google Cloud og GKE-kunder
Timingen er ikke gunstig for Google. Ifølge Synergy Research Group hadde Google Cloud 14 prosent av det globale markedet for skyinfrastrukturtjenester i fjerde kvartal 2025, mot 28 prosent for AWS og 21 prosent for Microsoft Azure. De tre store sto samlet for rundt 68 prosent av all bedriftsbruk av skyinfrastruktur i perioden. Google Cloud var samtidig den av de tre som vokste raskest i markedsandel, delvis drevet av at flere selskaper flytter AI-arbeidslaster til Google-plattformen, ifølge tall gjengitt av CRN.
Kubernetes-avhengigheten som gjør ConfigConfusion relevant for så mange, henger sammen med hvor dominerende plattformen har blitt. Cloud Native Computing Foundations årlige undersøkelse for 2025, publisert i januar 2026, viser at 82 prosent av containerbrukere nå kjører Kubernetes i produksjon, opp fra 66 prosent i 2023, og at 98 prosent av virksomhetene som ble spurt har tatt i bruk skyfødte teknologier i en eller annen form. Når en så stor andel av produksjonsmiljøer bygger på Kubernetes, blir også operatormønstre som Config Connector langt mer utbredt enn de var for få år siden.
Kostnadssiden av å ikke ta slike hull på alvor er heller ikke ubetydelig. IBMs Cost of a Data Breach Report 2025 satte gjennomsnittskostnaden for et sikkerhetsbrudd globalt til 4,44 millioner dollar, en nedgang på 9 prosent og den første globale nedgangen på fem år. Samme rapport skiller mellom miljøtyper: brudd som involverte offentlig sky kostet i snitt 4,18 millioner dollar, brudd i privat sky 4,68 millioner dollar, mens brudd som spredte seg på tvers av flere miljøer kostet i snitt 5,05 millioner dollar, altså den dyreste kategorien. Et scenario der en angriper får full organisasjonskontroll, inkludert prosjekter, hemmeligheter og fakturering, faller naturlig i den øverste enden av den skalaen.
Hva betyr dette for norske og nordiske virksomheter?
Norske og nordiske selskaper som bygger på Google Cloud og GKE for containerdrift, bør lese ConfigConfusion-saken som mer enn en enkeltstående feil hos én leverandør. Den peker på et strukturelt spørsmål mange plattformteam ikke stiller seg selv i det daglige: hvilken skyidentitet arver egentlig makten når et team får lov til å opprette en bestemt type Kubernetes-ressurs? I mange norske organisasjoner er GitOps-modellen akkurat den samme som Config Connector bygger på, nettopp fordi den løser reelle problemer med spredte nøkler og manuell tilgangsstyring.
Samtidig skjerper regelverket kravene til nettopp denne typen risikostyring. Med NIS2 innført i norsk rett gjennom digitalsikkerhetsloven må langt flere virksomheter enn før dokumentere hvordan de styrer tilgang og identitet i skymiljøer, ikke bare hvordan de patcher kjente sårbarheter. En feilkonfigurasjon som gir en hel organisasjon bort, uten at det finnes et CVE-nummer å vise til i et avvikssystem, er nettopp den typen risiko som lett faller mellom stolene i tradisjonelle sårbarhetshåndteringsrutiner, fordi den ikke dukker opp i en vanlig CVE-basert skanningsrapport.
Slik sikrer du Config Connector i dag
Både Varonis og O’Leary peker på konkrete grep plattformteam kan gjøre uten å vente på en offisiell rettelse fra Google. Det viktigste er å angripe begge sidene av gapet samtidig: hva Config Connectors tjenestekonto faktisk kan gjøre i Google Cloud, og hvem som i utgangspunktet kan sende inn ressurser den skal behandle.
- Bruk Config Connector i navnerom-modus (namespaced mode), med en egen, snevert avgrenset Google-tjenestekonto per navnerom i stedet for én delt konto for hele klyngen.
- Gå gjennom alle IAM-roller Config Connector har på prosjekt-, mappe- og organisasjonsnivå, og fjern brede roller som
roles/ownerogroles/resourcemanager.organizationAdminmed mindre de er strengt nødvendige. - Begrens hvem som kan opprette
IAMPolicyMember,IAMPolicyogIAMPartialPolicy-ressurser til godkjente plattform- eller infrastrukturteam, ikke til alle utviklere med klyngetilgang. - Overvåk IAM-endringer på mappe- og organisasjonsnivå som er utført av Config Connector, spesielt de som skjer utenfor den godkjente GitOps-arbeidsflyten.
- Vurder tilsvarende gjennomgang for andre skyoperatører i klyngen, som Terraform-kontrollere eller egendefinerte operatorer, siden det samme confused deputy-mønsteret kan gjenta seg der.
Den sårbare konfigurasjonen oppstår først når to forhold inntreffer samtidig: en Config Connector-tjenestekonto med organisasjonsnivå-tillatelser, og bred skrivetilgang til navnerommene Config Connector overvåker. Hvert av forholdene kan håndteres hver for seg, men sammen skaper de en eskaleringsvei som ikke krever en eneste Google Cloud-legitimasjon å utnytte.
Fem spådommer for veien videre
Basert på hvordan lignende saker har utviklet seg tidligere, og hvordan denne konkrete saken har eskalert siden mars, peker flere ting mot hva som trolig skjer videre.
- Mediepresset etter Varonis- og BleepingComputer-dekningen i september gjør det sannsynlig at Google til slutt oppdaterer dokumentasjonen for Config Connector med tydeligere advarsler om organisasjonsnivå-tillatelser, selv om selskapet fortsatt kan la være å tildele et eget CVE-nummer.
- Flere sikkerhetsselskaper vil trolig følge Varonis’ eksempel og lete etter tilsvarende confused deputy-mønstre i andre populære Kubernetes-operatorer, både hos Google, AWS og Azure, gitt hvor mye oppmerksomhet saken har fått.
- Bug bounty-programmer hos store skyselskaper vil trolig møte økt kritikk for å avvise rapporter som “fungerer som tiltenkt”, etter at samme mønster nå er dokumentert både hos Google og tidligere hos Microsoft i O’Learys sak om Azure Backup for AKS.
- Flere virksomheter vil begynne å inkludere identitetsarv i Kubernetes-operatorer som eget punkt i sine interne sikkerhetsrevisjoner, ikke bare tradisjonell CVE-basert sårbarhetsskanning.
- Etterspørselen etter verktøy som kartlegger sammenhengen mellom Kubernetes RBAC og skyleverandørers IAM-modeller ventes å øke, ettersom dagens verktøylandskap i stor grad behandler de to systemene separat.
Hva sier dette om tilliten til skyleverandørenes sikkerhetsprosesser?
Det mest urovekkende elementet i ConfigConfusion-saken er kanskje ikke selve den tekniske mekanismen, men sekvensen av beslutninger hos Google. En sikkerhetsingeniør vurderte funnet som alvorlig nok til å gi høyeste prioritet og roste forskeren direkte. Elleve dager senere reverserte et automatisert panel den vurderingen uten at den underliggende tekniske risikoen hadde endret seg. For virksomheter som er avhengige av at skyleverandøren selv oppdager og retter opp denne typen strukturelle hull, er det et signal om at intern klassifisering hos leverandøren ikke nødvendigvis er en pålitelig indikator på hvor alvorlig en sårbarhet faktisk er, og at kundene selv må gjøre egne vurderinger uavhengig av om et CVE-nummer eksisterer.
Ofte stilte spørsmål om ConfigConfusion
Hva er ConfigConfusion?
ConfigConfusion er navnet på en privilegie-eskaleringsteknikk oppdaget av sikkerhetsforsker Justin O’Leary. Den utnytter at Google Kubernetes Config Connector utfører Google Cloud-operasjoner gjennom sin egen tjenestekonto uten å sjekke om den opprinnelige Kubernetes-brukeren har rett til å be om handlingen.
Har Google fikset ConfigConfusion?
Ved siste kjente status, gjengitt av The Register 18. juni 2026, var saken fortsatt registrert internt hos Google som “pågår (godkjent)” uten et tildelt CVE-nummer eller en publisert rettelse. Google har i stedet publisert anbefalinger om å begrense tillatelsene til Config Connectors tjenestekonto.
Fikk Justin O’Leary noen belønning for funnet?
Nei. Google klassifiserte først saken som høy prioritet og alvorlighetsgrad, men et automatisert belønningspanel reverserte vurderingen elleve dager senere og konkluderte med at programvaren fungerte som tiltenkt, uten utbetaling.
Rammer ConfigConfusion alle GKE-klynger?
Nei. Sårbarheten krever at Config Connectors tjenestekonto har fått organisasjonsnivå-tillatelser, og at vanlige brukere har bred skrivetilgang til navnerommene Config Connector overvåker. Klynger som bruker navnerom-modus med snevert avgrensede tjenestekontoer er langt mindre utsatt.
Har AWS og Azure de samme problemene?
Det generelle confused deputy-mønsteret kan i teorien ramme enhver infrastrukturkontroller. AWS Controllers for Kubernetes deler opp tillatelser per tjeneste, mens Azure Service Operator v2 lar administratorer knytte egne identiteter til hvert navnerom. Begge modellene begrenser potensiell skade sammenlignet med Config Connectors ofte organisasjonsbrede standardoppsett, men fjerner ikke risikoen helt.
Hvordan sjekker jeg om min egen GKE-klynge er sårbar?
Se gjennom hvilke IAM-roller Config Connectors tjenestekonto har på organisasjons-, mappe- og prosjektnivå, og kartlegg hvem som har rettigheter til å opprette IAMPolicyMember-ressurser i klyngen. Hvis begge er brede samtidig, bør tilgangen strammes inn umiddelbart.
Finnes det et offentlig kjent bevis-på-konsept for angrepet?
Ja. Justin O’Leary demonstrerte teknikken i en video som viste hvordan tre linjer YAML kan gi full administrativ kontroll over en GCP-organisasjon på om lag fem sekunder, ifølge The Register.
Er dette relevant for norske virksomheter under NIS2?
Ja. Digitalsikkerhetsloven, som gjennomfører NIS2 i Norge, stiller krav om dokumentert risikostyring for identitet og tilgang i skymiljøer. En strukturell IAM-svakhet uten eget CVE-nummer faller lett utenfor tradisjonell CVE-basert sårbarhetsskanning, men bør likevel inngå i virksomhetens interne risikovurdering av skyleverandøravhengigheter.
