Styrning med Excel i en värld av kontinuerliga driftsättningar
Många organisationers styrmodell är fortfarande byggd för en tid då:
- releasecykler mättes i månader
- förändringar passerade manuella CAB-möten
- revision innebar att samla in Excel listor från systemägare
Samtidigt befinner sig plattformsteam och utvecklingsorganisationer i en verklighet med:
- kontinuerliga driftsättningar
- dynamiska Kubernetes kluster
- mikrotjänster och självbetjäning
I den miljön räcker inte “kontroll genom möten och dokument”. En modern styrmodell för molnet behöver vara inbyggd i plattformen, inte ligga vid sidan av.
Från kontroll av beslut till kontroll av beteenden
Traditionell styrmodell fokuserar ofta på att godkänna enskilda beslut:
- Har rätt mall fyllts i?
- Har CAB sagt ja?
- Har alla signerat?
Det är en modell som är svår att skala när antalet driftsättningar och förändringar ökar.
I en Cloud Native miljö behöver vi i stället styra beteenden i systemet:
- Hur skapas nya tjänster?
- Vilka images får användas?
- Hur får data flöda mellan zoner, namespaces och kluster?
Det innebär ett skifte:
Från: “Kontrollera varje förändring”
Till: “Definiera ramar – och säkerställ att allt innanför ramarna är automatiskt godkänt”
Kubernetes som motor för efterlevnad
Kubernetes är inte bara en plattform för att köra containers – det är också en enforcement motor.
Med komponenter som:
- Admission Controllers
- Validating/Mutating Webhooks
- Open Policy Agent (OPA), Gatekeeper eller Kyverno
- Pod Security Standards
kan vi uttrycka regler som:
- “Alla images ska vara signerade och komma från godkända registries.”
- “Pods får inte köra som root eller med privilegierade capabilities.”
- “Endast definierade namespaces får exponeras utåt.”
Detta gör det möjligt att gå från:
- tolkningsbara policys i ett PDF dokument
- till binära beslut i plattformen: driftsättning tillåts eller nekas
Samtidigt behöver en modern styrmodell omfatta mer än Kubernetes — exempelvis identitet och åtkomst på organisationsnivå, nätverksarkitektur, brandväggspolicys och krav på loggarkiv eller retention. Kubernetes är en central motor för enforcement, men inte hela styrmodellen.
Policy as Code – när styrmodellen flyttar in i pipelines
Policy as Code innebär att styrregler:
- uttrycks i kod
- versionshanteras
- granskas via pull requests
- testas och distribueras automatiskt
För plattformsteamet betyder det att policyförändringar kan:
- testas i separata miljöer
- rullas ut globalt snabbt
- rullas tillbaka om något blir fel
För utvecklingsteamen betyder det:
- tydliga regler
- mindre friktion
- inga sena säkerhetsblockeringar i slutet av cykeln
Detta är ett verkligt shift left.
Så vet du att din styrmodell är omodern
Några vanliga signaler:
- Säkerhetsteamet har ständig backlog med manuella granskningspunkter
- Team hittar egna lösningar för att komma runt processer
- Ingen kan snabbt svara på frågor som:
- “Hur många tjänster bryter mot X policy just nu?”
- “Hur fort kan vi rulla ut en global policyändring?”
Detta skapar styrmodellsskuld – en växande risk i form av osynliga avvikelser och inkonsekventa säkerhetsmönster.
KPI:er för en modern styrmodell för molnet
För att styra och förbättra styrmodellen bör vi mäta:
Policy Compliance Rate
Andel driftsättningar som uppfyller policys utan manuell handpåläggning.
MTTR för policyförändringar
Hur snabbt kan vi ändra en global säkerhetsregel i alla miljöer?
Adoption av Golden Paths
Hur stor del av organisationens tjänster följer de fördefinierade, godkända leveransvägarna?
Dessa KPI:er visar hur styrningen fungerar i vardagen – inte bara på papper.
Federerad styrmodell och Golden Paths
I större organisationer är en federerad modell oftast mest praktisk:
- Plattformsteamet skapar guardrails, Golden Paths och standarder
- Team får frihet inom dessa ramar
- Undantag hanteras genom tydliga, spårbara processer
Golden Paths är centrala eftersom de:
- ger säkra, förgodkända leveransvägar
- minskar valtrötthet
- minimerar risken för styrmodellsskuld
Vad vi ser hos kunder – från dokument till automation
Organisationer som lyckas gör samma resa:
Inventering
Vilka policys finns? Var lever de? (dokument, IAM, nätverk, huvudkunskap)
Prioritering
Vilka policys är mest kritiska och mest lämpade att automatisera först?
Förflyttning
- dokument → Policy as Code
- manuell granskning → Admission Controllers
- lokala lösningar → gemensamma, återanvändbara byggblock
Resultatet är inte bara bättre efterlevnad – utan också snabbare leverans.
Kopplingen till suveränitet, portabilitet och plattform
- Bloggen om Digital suveränitet förklarar varför kontrollskiktet är centralt
- Bloggen Kubernetes och portabilitet diskuterar hur vi säkerställer att styrningen fungerar oavsett miljö
- Bloggen om Suveräna cloud native-plattformar vis ar hur vi operationaliserar styrmodellen för utvecklingsteamen
Sammanfattning: Styrmodell som möjliggörare
Moderna styrmodeller för molnet handlar inte om att bromsa utveckling, utan om att:
- definiera ramar
- automatisera efterlevnad
- ge teamen bra, säkra vägar
Kubernetes och Policy as Code gör det möjligt att bygga Compliance by Design – efterlevnad som en integrerad del av plattformens DNA.
Vill ni utveckla er styrmodell?
Vill ni utveckla er styrmodell eller ta första steget mot Policy as Code i Kubernetes? Våra experter inom Cloud Native-säkerhet och plattformsteam hjälper er vidare.
