Sikkerhed i microservices

Fra en monolitisk softwarearkitektur over i en microservice-baseret verden er der mange nye værktøjer og teknologistakke man bør overveje at tage i brug for at opnå en succesfuld oplevelse med microservices. Det gælder bl.a. logning, monitorering, deployment, kommunikation imellem services og ikke mindst sikkerheden omkring alle de forskellige microservices. Til GOTO Cph 2017 er der sat et helt track af til at udforske microservices fra forskellige vinkler.

Sikkerheden i en monolitisk applikation kan løses vha. perimeter sikkerhed, hvor et system er sikret mod uvedkommende indtrængen som én stor sikkerhedsbarriere. Dette kan også være én løsning for en microservice platform, men der skal som oftes tænkes lidt anderledes hvad angår sikkerhed, når der er flere uafhængige services og komponenter, og dermed mange snitflader man kan nå udefra.

I en microservice-arkitektur udstiller hver service så begrænset en mængde funktionalitet som muligt, idet hver service helst kun skal kunne én ting. Hver enkelt komponent skal til gengæld sikres mht. adgang, og data i hver microservice skal beskyttes for sig – hvilket gør sikkerhedsdelen af et microservicesystem lidt mere kompleks.

Keycloak

Keycloak er en Identity – og Access Management system, der kan håndtere bl.a. Single-Sign On, Social Login, authentication & authorization, samtykke, 2-faktor login, interagere med eksisterende LDAP servere etc.

Keycloak er baseret på standardprotokoller og tilbyder support for OAUTH 2.0, OpenID Connect og SAML.

Keycloak er især velegnet til at sikre microservices. Der eksisterer et stort udvalg af såkaldte Keycloak Client Adapters, som er biblioteker der tilføjes hver microservice, der skal beskyttes af Keycloak. Client Adapters findes til en del forskellige programmeringssprog, og til mange forskellige platforme. Det er nemt at integrere dem i services netop fordi de er tilpasset den valgte platform (fx Spring, JBOSS, Jetty, Tomcat etc. for Java applikationer), så derfor passer de godt ind i en microservice-verden.

Keycloak er baseret på et koncept kaldet Realms, som både består af overordnede sikkerhedsregler for applikationen, samt af en samling af Keycloak clients. En client kan fx være en microservice, som skal beskyttes af Keycloak.

Keycloak kan administreres centralt via selve Keycloak admin serveren, hvor opsætningen af al data, clients, brugere, roller, key/value mappings, authorization-regler etc. specificeres og gemmes. Der findes API’er til stort set al kommunikation med Keycloak admin serveren, således at opsætningen kan gøres programmatisk – eller direkte via admin web-siden.

Authn og authz

Jeg har været med til at udvikle en microservice-platform samt et antal microservices, der hver håndterer forskellige typer resourcer. Nogle af disse microservices gemmer data i en database (også i en microservice), nogle modtager og forwarder requests (backend for frontend), mens andre konverterer data. Det hele er udviklet ud fra tankegangen om API driven development, og alle microservices er baseret på REST. Mht front-end er der lavet både en mobil app samt en web grænseflade, der skal tilgå data fra de forskellige microservices. For at sikre alle microservices i projektet, har vi valgt at bruge Keycloak som vores security løsning.

Authentication af brugere sker gennem Keycloak. En ny bruger oprettes i Keycloak-serveren med brugernavn og password. Vi har brugt Keycloaks egen login-side, som vises i app’en (eller web grænsefladen) når brugeren logger ind. Denne login-side kan tilpasses mht. udseende. Når man logger ind via Keycloak serveren med de rette parametre, evt. med et ekstra lag af sikkerhed (ud over brugernavn og password), får man et Keycloak access token retur. Dette access token kan derefter bruges i REST kald til de microservices, man vil tilgå.

Authorization kan ske enten i Keycloak serveren, hvor forskellige authz-regler sættes op for hver bruger/client/microservice, eller også kan man vælge at håndtere authorization inde i maven på hver microservice. Man kan opnå en mere finkornet authorization ved selv at implementere meget specifikke authorization-regler, der er målrettet hver enkelt microservice. Keycloak-serveren er til gengæld god til at håndtere de mere overordnede authz-regler, og kan konfigureres til at tillade brugere med bestemte roller at tilgå bestemte resourcer (dvs clients), og dermed opnå en mere generel authorization uden for meget boilerplate kode. Vi har i projektet valgt lidt af begge dele. Hvem, der har adgang til hvilke typer data i hver microservice, bliver håndteret i microservice-delen, mens Keycloak-serveren gemmer på et antal roller som hver bruger bliver tildelt ved oprettelse. Når en microservice modtager et REST kald med et access token i Authorization Header, søger man i access token’et efter hvilke roller, bruger ID og andet vigtig info omkring denne bruger.

Høj læringskurve

Keycloak er en sikkerhedsmanagement løsning, hvor der er mulighed for at til- og fravælge mange forskellige sikkerhedsvalg for ens applikation. Der findes en del eksempler på implementationer på github, og Keycloaks dokumentation er omfangsrig. Men der er også steder hvor det halter mht. dokumentation og eksempler, og læringskurven er forholdvis høj, selvom der argumenteres for at Keycloak er nem at bruge og kræver næsten ingen viden om security – hvilket ikke kan siges at være helt korrekt. Der er mange valg, man skal tage stilling til, og det er en stor hjælp at have udformet et security design for ens projekt på forhånd, for at kunne træffe de rigtige valg mht. Keycloak-opsætningen.

Men når man har sat sig ind i Keycloaks mange valgmuligheder, og sikret sine microservices på den mest optimale måde, der passer til ens behov, så virker det out of the box, kan nemt skalere og kan udvides og tilpasses som man vil.