AWS Single Sign-On i Ruter
Tilgangsstyring til en stadig voksende applikasjonsplattform er ikke en triviell oppgave. Derfor kan det være nyttig å se seg om etter muligheter for å forenkle dette så langt det lar seg gjøre, uten at det går på bekostning av sikkerheten på plattformen. Applikasjonsplattformen til Ruter er fordelt over flere AWS-kontoer som vi bruker til å separere miljøene våre. I tillegg bruker vi noen systemer utenfor selve plattformen, men som absolutt er relaterte — i første rekke Datadog og GitLab.
I Ruter har vi ca. 15 produktteam/utviklingsteam som jobber etter DevOps-prinsipper. Teamene eier, utvikler og drifter sine løsninger og applikasjoner fra start til slutt. Disse produktteamene består p.t. av ca. 150 utviklere, som alle er interesserte i at utviklingen skal gå så enkelt som mulig. Utfordringene skal ligge i å lage gode løsninger som Ruters kunder vil få nytte av, ikke å måtte streve med å bli tildelt tilgangene de trenger. Siden produktteamene selv eier sine løsninger burde de også selv kunne bestemme hvem som skal få tilgang til deres løsninger, også hvis det er personer fra andre team i Ruter.
Vi hadde altså noen problemstillinger å bryne oss på:
· Enklere tilgang inn til plattformen
· Gruppere sammen tilganger på tvers av miljøer og applikasjoner
· Fjerne repetitiv brukerstyring
· Demokratisering av tilganger
· Sette bort den daglige brukerstyringen
Hva er AWS SSO
AWS Single Sign-On er en av AWS sine mange løsninger for tilgangsstyring til AWS-kontoer. Den skiller seg litt fra de andre løsningene ved at den på en enklere måte også kan brukes for tilgangsstyring mot eksterne systemer.
AWS SSO ligger i en «master-konto» og er en del av AWS Organizations. Dette forenkler en del av arbeidet når man skal tildele tilganger i forskjellige underliggende kontoer.
Selvstyre
Vi bruker AWS SSO som et mellomledd mellom Active Directory hos en av våre driftsleverandører og AWS-miljøene som vi i stor grad drifter selv. I denne løsningen benytter vi Active Directory kun som en kilde til identitetene (identity provider). De faktiske rettighetene som brukerne blir tildelt styrer vi selv via IAM-roller og -policies.
Denne måten å dele det opp på gir oss på plattformteamet muligheten til å raskere kunne gi tilgang til nye tjenester og ressurser når de blir tilgjengelige fra AWS.
Den gamle måten
Måten vi har implementert AWS SSO på bygger egentlig videre på et eksisterende tilgangsregime hvor tilganger tildeles på team-nivå. Alle medlemmer av et team får i utgangspunktet den samme tilgangen.
Hva vi måtte gjøre
Den gamle måten hadde også en del utfordringer når det kom til brukervennligheten. Alt startet med at vi på plattformteamet først satte opp en bruker kalt «teamadmin» for de enkelte teamene. Denne ble overlevert til teamleder for hvert team. Prosessen var helt manuell og forutsatte at tilgangsnøkler ble oversendt til teamleder.
Hva teamadmin måtte gjøre
Denne teamadmin-brukeren kunne så opprette nye personlige brukere for de enkelte teammedlemmene. Nok en manuell prosess, som attpåtil var veldig sårbar for feil.
Denne prosessen forutsatte også at det skulle registreres en MFA-enhet for autentisering, noe som faktisk er mulig å gjøre via AWS CLI, men man fort blir lei av å gjøre gjentatte ganger.
Frittstående IAM-brukere
I tillegg opprettet vi brukere med PowerUser-tilgang i DEV/TEST slik at det skulle være mulig for utviklerne å prøve ut nye tjenester i forbindelse med POC.
Felles for alle disse registrerte brukerne var at ingenting var automatisert. Vi måtte få bestillinger fra teamene både når nye utviklere startet og når noen sluttet. Vi var veldig sårbare for at noen fortsatt hadde tilganger de absolutt ikke skulle ha.
Hvordan vi gikk frem
Active Directory
Vi drifter ikke AD selv, men vi har fått god støtte og forståelse hos vår driftsleverandør som raskt har bistått oss med å legge til rette for våre behov.
Grupper for hvert team
Det viktigste på AD-siden er at vi har fått opprettet dedikerte grupper for hvert enkelt produktteam. Her er alle personer på teamet meldt inn, og når det starter noen nye på teamet ber teamleder om at personen meldes inn i gruppa.
Tilganger
Vi jobbet også videre med policy-dokumenter og migrerte mye fra den gamle løsningen. AWS SSO ga oss muligheten til å implementere en løsere kobling mellom AD-gruppene og deres respektive tilganger. I AWS SSO opprettes denne knytningen via noe de kaller Permission Sets, som automatisk oppretter tilhørende roller i de forskjellige AWS-kontoene. Her sparer vi en del arbeid ved at vi slipper å delegere tillit (trust policy) på tvers av kontoer.
Utfordringer
Tidlig ute
Da vi startet med dette prosjektet på vinteren/våren 2020 var løsningen fortsatt ganske umoden. Den hadde liten støtte når det kom til IaC og krevde at vi oppgraderte til AWS CLI 2. AWS SSO har modnet mye siden da og flere muligheter kommer stadig til.
Manglende støtte for Terraform
En stor utfordring var at Terraform, som vi bruker til IaC, ikke hadde støtte for AWS SSO. Vi var rett og slett nødt til å lage løsninger utenom Terraform. Vi landet på et Python-bibliotek — doit sammen med boto3 pluss litt av vår egen scripting for å opprette de nødvendige ressursene i AWS SSO.
Policies
Det er ikke mulig å legge til flere separate policy-dokumenter på et permission-set. Dette medfører at tilganger på tvers av ulike tjenester må bakes inn i et stort dokument som så knyttes til et permission-set. Her støter vi på noen utfordringer når det kommer til makslengden på en policy.
Gevinster
Selv om vi har vært igjennom noen utfordringer og begrensninger, har AWS SSO vært en positiv forandring i måten vi gjør tilgangsstyring:
· Den har fjernet store deler av det repetitive arbeidet rundt brukerstyring, vha. synkronisering mot Active Directory.
· Teamledere kan påse at nye teammedlemmer får de riktige tilgangene fra første dag.
· AWS SSO har gitt oss en ny portal inn til plattformen og tilhørende systemer, slik at det er litt enklere å finne frem.
· Utviklerne slipper å forholde seg til flere forskjellige bruker-identiteter.
· Vi har fått bedre sikkerhet ved at personer som slutter automatisk mister tilgangen til plattformen.
Veien videre
Et viktig steg videre for vår del blir å forenkle policy-dokumentene. I dag er det i stor grad basert på en RBAC-modell. Når vi går videre ønsker vi å basere oss mer på en ABAC-modell hvor tagger på brukere og ressurser er det som ligger til grunn for tilgangsstyringen. Dette fører til mye mindre duplisering i dokumentene ved at vi slipper å oppgi enkeltressurser for en policy.
Om Team CMP
Team CMP (Core Mobility Platform) er plattformteamet i Ruter. Vi består av 9 personer og vi jobber med å bygge og levere plattformtjenester til de andre produkt/utviklingsteamene i Ruter som bruker plattformen til å levere sine tjenester til Ruters kunder og samarbeidspartnere. Terraform, Kubernetes og en bråte AWS-tjenester er sentrale i vårt arbeid.
