Token-validering og grovkornet autorisasjon

SKIP benytter seg av kubernetes operatoren Ztoperator for å håndheve token-validering og grovkornet autorisasjon for tjenester som kjører på SKIP.

Hvis man ønsker å benytte seg av SKIP sin løsning for å sette opp token-validering og grovkornet autorisasjon, har man to valg. Man kan benytte seg av Skiperator dersom man ønsker å holde konfigurasjonen nær Skiperator-manifestet. Alternativt kan man bruke CRD-en fra Ztoperator direkte.

Felles for begge alternativene er at de bygger inn to prinsipper i hvordan token-validering og grovkornet autorisasjon settes opp.

• Gyldig JWT by default: Med mindre endepunkt er eksplisitt spesifisert som åpne må innkommende request ha en gyldig JWT.
• Trygge standardinnstillinger: Hvis man ved en feil spesifiserer et endepunkt som både åpent og autorisert, vil forespørselen som standard kreve et gyldig og autorisert JWT.

Skiperator

🚧 UNDER UTVIKLING 🚧
Støtte for å sette opp token-validering og grovkornet autorisasjon via Skiperator-manifestet er under utvikling og er foreløpig ikke tilgjengelig.

Ztoperator

Ztoperator introduserer CRD-en AuthPolicy, som har i oppgave å sette opp token-validering og grovkornet autorisasjon. AuthPolicy har som hovedoppgave å opprette Istio-ressursene RequestAuthentication og AuthorizationPolicy på en måte som følger brukerens definerte regler, samtidig som de to prinsippene nevnt ovenfor ivaretas. API-dokumentasjonen til Ztoperator finner du her.

Hvilken workload reglene definert i en AuthPolicy skal gjelde for spesifiseres ved å referere til labels.

Visste du at...

Hvis du har en Skiperator-applikasjon med navn some-application vil den få labelen app: some-application.

🧠 Wildcards for URL-stier (paths)

Når man setter opp tilgangsstyring med Ztoperator, så kan man enten åpne opp tilgang til endepunkter, eller spesifisere endepunkter som skal være autentiserte og/eller grovkornet autoriserte (innsnevre tilgang til endepunkt basert på verdiene til token-claims). Da spesifiserer man et sett med en eller flere URL-stier. Istio, og dermed også Ztoperator, støtter bruken av wildcards i disse stiene, men er noe uklar i bruken av disse i deres dokumentasjon.

Ztoperator støtter bruken av tre wildcard-operatorer: *, {*} og {**}, der * er den gamle wildcard-syntaksen, mens {*} og {**} er den nye wildcard-syntaksen. Ztoperator har følgende validering av stier:

• En sti kan ikke blande gammel og ny wildcard-syntax.
• Wildcardet *, (dvs. gammel wildcard-syntaks), kan kun brukes som enten prefiks, suffiks eller alene. Wildcardet vil da matche null eller flere sti-segmenter (deler av stien mellom /).
• Wildcardet {*}, (dvs. ny wildcard-syntaks), kan kun brukes alene i et sti-segment. Wildcardet vil da matche ett sti-segment (deler av stien mellom /).
• Wildcardet {**}, (dvs. ny wildcard-syntaks), kan kun brukes alene i et sti-segment. Wildcardet vil da matche null eller flere sti-segmenter (deler av stien mellom /). Hvis {**} benyttes så må den være den siste wilcard-operatoren.

📑 Eksempler på wildcards for URL-stier

Sti	Gyldig	Forklaring
*	✅	Matcher alle stier
*/foo/bar	✅	Matcher /foo/bar, /api/foo/bar, /api/something/foo/bar, /api/something/else/foo/bar.
/foo/bar*	✅	Matcher /foo/bar, /foo/bar/baz, /foo/bar/baz.html.
/foo/{*}/	✅	Matcher /foo/bar, men ikke /foo/bar/baz.
/foo/{**}/	✅	Matcher /foo/bar/, /foo/bar/baz.txt, og /foo//, men ikke /foo/bar.
/foo/{*}/bar/{**}	✅	Matcher /foo/buzz/bar/ og /foo/buzz/bar/baz.
foo/*/bar	❌	Kun lov å bruke wildcardet * som enten prefiks, suffiks eller alene.
/*/baz/{*}	❌	Ikke lov å blande gammel og ny wildcard-syntaks.
/**/baz/{*}	❌	Wildcard-operatoren ** er ikke lov å bruke, den må være omsluttet av krøllparenteser, i.e. {**}.
/{**}/foo/{*}	❌	Ikke lov: Hvis wildcard-operatoren {**} benyttes må den være den siste wildcard-operatoren.
/foo/{*}.txt	❌	Wildcard-operatoren {*} er ikke lov å bruke sammen med andre tegn innenfor et sti-segment.

📖 Eksempler

Under følger en rekke eksempler på hvordan å konfigurere token-validering og grovkornet autorisasjon på SKIP.

Eksempel 1: Token-validering for alle endepunkt

Skiperator

🚧 UNDER UTVIKLING 🚧
Støtte for å sette opp token-validering og grovkornet autorisasjon via Skiperator-manifestet er under utvikling og er foreløpig ikke tilgjengelig.

Ztoperator

Følgende AuthPolicy-manifest konfigurerer token-validering for alle endepunktene inn til workloads med labelen app: some-application i namespacet some-namespace.

apiVersion: ztoperator.kartverket.no/v1alpha1
kind: AuthPolicy
metadata:
  name: some-auth-policy
  namespace: some-namespace
spec:
  enabled: true
  audience:
    - some-audience
  wellKnownURI: https://some-issuer.com/.well-known/openid-configuration
  selector:
    matchLabels:
      app: some-application

Eksempel 2: Legg til åpne endepunkt

Skiperator

🚧 UNDER UTVIKLING 🚧
Støtte for å sette opp token-validering og grovkornet autorisasjon via Skiperator-manifestet er under utvikling og er foreløpig ikke tilgjengelig.

Ztoperator

Følgende AuthPolicy-manifest konfigurerer token-validering for alle endepunktene inn til some-application, utenom for GET til /api/cars og /api/cars/public*.

Legg merke til...

Her er wildcard (*) brukt. Resultatet blir da at GET mot /api/cars, /api/cars/public og alle andre sub-paths av /api/cars/public vil være åpne, mens requests mot andre stier vil kreve autentisert JWT, dvs. JWT med claimet iss: https://some-issuer.com og aud: some-audience.

apiVersion: ztoperator.kartverket.no/v1alpha1
kind: AuthPolicy
metadata:
  name: some-auth-policy
  namespace: some-namespace
spec:
  enabled: true
  audience:
    - some-audience
  wellKnownURI: https://some-issuer.com/.well-known/openid-configuration
  ignoreAuthRules:
    - paths:
        - "/api/cars"
        - "/api/cars/public*"
      methods:
        - "GET"
  selector:
    matchLabels:
      app: some-application

Eksempel 3: Legg til autoriserte endepunkt

Skiperator

🚧 UNDER UTVIKLING 🚧
Støtte for å sette opp token-validering og grovkornet autorisasjon via Skiperator-manifestet er under utvikling og er foreløpig ikke tilgjengelig.

Ztoperator

Følgende AuthPolicy-manifest konfigurerer token-validering for alle endepunktene inn til some-application, utenom for endepunktene /api/cars* og /api/cars/public for alle metoder. I tillegg spesifiserer den at POST, PUT og DELETE mot /api/cars/admin kun er lov hvis JWT-claimet roles eksisterer med verdien admin.

Legg merke til...

Stiene /api/cars og alle sub-stier er nå spesifisert som åpne, som er i konflikt med at POST, PUT og DELETE mot /api/cars/admin krever autorisert JWT (roles: admin). Her spiller prinsippet om trygge standardinnstillinger inn, og Ztoperator vil falle tilbake til å kreve autorisert JWT for POST, PUT og DELETE mot /api/cars/admin.

apiVersion: ztoperator.kartverket.no/v1alpha1
kind: AuthPolicy
metadata:
  name: some-auth-policy
  namespace: some-namespace
spec:
  enabled: true
  audience:
    - some-audience
  wellKnownURI: https://some-issuer.com/.well-known/openid-configuration
  ignoreAuthRules:
    - paths:
        - "/api/cars*"
        - "/api/cars/public"
  authRules:
    - paths:
        - "/api/cars/admin"
      methods:
        - POST
        - PUT
        - DELETE
      when:
        - claim: "roles"
          values:
            - "admin"
  selector:
    matchLabels:
      app: some-application