🛡️ Token-validering og grovkornet autorisasjon

SKIP tilbyr innebygd støtte for å sette opp Kubernetes-ressurser som kan validere autentisiteten og autorisasjonen på inkommende requests før den i det hele tatt når applikasjonen. Dette er mulig fordi SKIP benytter seg av Istio som service mesh og instruerer Istio til å sette opp en Istio-sidecar i hver pod.

Fordelen med at hver pod har en istio-sidecar er at Istio introduserer flere nyttige CRD-er som kan berike kapabilitetene til istio-sidecar. To av disse CRD-ene er RequestAuthentication og AuthorizationPolicy, som blant annet kan brukes til å validere tokens (JWT) til innkommende requests og autorisere tilgang basert på claims.

Kilde: Kube by Example

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.

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.

🧾Spesifikasjonen til AuthPolicy

spec (object, required) – Spesifikasjon for AuthPolicy

rules ([]object, required) – Regler som bestemmer hvordan innkommende forespørsler skal tillates eller avvises basert på JWT-validering.

enabled (boolean, required) – Angir om JWT-validering skal være aktivert. Hvis aktivert, vil innkommende JWT-er bli validert mot spesifisert utsteder og audience.

issuerURI (string, required) – Forventet iss-claim i JWT. Må samsvare med den som ble brukt da tokenet ble utstedt.

jwksURI (string, required) – URI for å hente JWKS (nøkkelsett brukt til å verifisere JWT-signatur).

audience ([]string, required) – Liste med aksepterte aud-verdier i JWT. Minst én verdi må finnes i tokenet for at det skal være gyldig.

forwardJwt (boolean, optional) – Hvis satt til true, videresendes den originale JWT-en. Standard er true.

fromCookies ([]string, optional) – Lister hvilke cookies som skal undersøkes for JWT.

outputClaimToHeaders ([]object, optional) – Definerer hvordan claims fra verifisert JWT skal kopieres til HTTP-headere. Støtter enkle og nøstede verdier av typen string, int eller `bool.

claim (string, required) – Navn på claimet som skal hentes fra JWT.

header (string, required) – Navn på HTTP-headeren som skal inneholde claim-verdien.

acceptedResources ([]string, optional) – Liste med ressursindikatorer som må finnes i JWT (aud). Følger RFC8707. Må være gyldige URI-er.

authRules ([]object, optional) – Regler for å tillate HTTP-forespørsler basert på påstander i JWT.

paths ([]string, required) – Stier regelen skal gjelde for. Må starte med /, ikke slutte med /, og kan avsluttes med * som wildcard-operator.

methods ([]string, optional) – HTTP-metoder som regelen gjelder for. Hvis ikke angitt, tillates alle metoder. Tillatte metoder er GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE, CONNECT.

when ([]object, required) – Tilleggskrav basert på JWT-claims. Forespørselen tillates hvis minst ett av tilleggskravene er oppfylt.

claim (string, required) – Navnet på JWT-claimet som skal kontrolleres.

values ([]string, required) – Verdier som claimet må inneholde for å være gyldig. Tilleggskravet er møtt hvis claimet fra JWT inneholder én eller flere av disse verdiene (OR-logikk).

ignoreAuthRules ([]object, optional) – Definerer hvilke forespørsler som ikke krever JWT-autentisering.

paths ([]string, required) – Stier regelen skal gjelde for. Må starte med /, ikke slutte med /, og kan avsluttes med * som wildcard-operator.

methods ([]string, optional) – HTTP-metoder som regelen gjelder for. Hvis ikke angitt, tillates alle metoder. Tillatte metoder er GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE, CONNECT.

selector (object, required) – Bestemmer hvilke workloads policyen skal gjelde for.

matchLabels (map[string]string, optional) – Et sett med labels som brukes til å identifisere hvilke workloads policyen skal gjelde for. Gjelder bare innenfor samme namespace. Label-nøkler kan ikke være tomme eller inneholde wildcard-tegn.

📖 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:
  rules:
    - enabled: true
      audience:
        - some-audience
      issuerURI: https://some-issuer.com
      jwksURI: https://some-jwks-uri.com
  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:
  rules:
    - enabled: true
      audience:
        - some-audience
      issuerURI: https://some-issuer.com
      jwksURI: https://some-jwks-uri.com
      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.

Eksempel 4: Token-validering og grovkornet autorisasjon med flere identitetstilbydere

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 og grovkornet autorisasjon inn til some-application for to identitetstilbydere: ID-porten og Maksinporten. Ztoperator tolker de definerte reglene som følger:

• /api/idporten/public og /api/maskinporten/public er åpne endepunkt for alle metoder.

• /api/idporten/secret må ha en gyldig JWT signert av ID-porten med claimet roles har verdien admin for alle metoder.

• /api/maskinporten/secret må ha en gyldig JWT signert av Maskinporten med claimet consumer har verdien 123456789 for alle metoder.

• Resterende endepunkt krever gydlgi JWT signert av enten ID-porten eller Maskinporten.

  apiVersion: ztoperator.kartverket.no/v1alpha1
  kind: AuthPolicy
  metadata:
    name: some-auth-policy
    namespace: some-namespace
  spec:
    rules:
      - enabled: true
        audience:
          - <DIN ID-PORTEN CLIENT-ID>
        issuerURI: https://idporten.no
        jwksURI: https://idporten.no/jwks.json
        ignoreAuthRules:
          - paths:
              - "/api/idporten/public"
        authRules:
          - paths:
              - "/api/idporten/secret"
            when:
              - claim: "roles"
                values: "admin"
      - enabled: true
        audience:
          - <DIN MASKINPORTEN CLIENT-ID>
        issuerURI: https://maskinporten.no/
        jwksURI: https://maskinporten.no/jwk
        ignoreAuthRules:
          - paths:
              - "/api/maskinporten/public"
        authRules:
          - paths:
              - "/api/maskinporten/secret"
            when:
              - claim: "consumer"
                values: "123456789"
    selector:
      matchLabels:
        app: some-application