Token Exchange as a Service (Texas )

De fleste applikasjoner som trenger autentisering må i dag forholde seg til mange detaljer rundt OAuth og JWTer. For å gjøre det lett å gjøre rett så har vi nå laget en tjeneste som abstraherer vekk alt dette bak et enkelt HTTP API.

Tjenesten er en sidecar som kjører sammen med appen din og er kun tilgjengelig i kjøretid på Nais. APIet har tre endepunkt som tilgjengeliggjøres som miljøvariabler:

• NAIS_TOKEN_ENDPOINT lar deg hente et maskin-til-maskin token
• NAIS_TOKEN_EXCHANGE_ENDPOINT lar deg bytte inn et token med sluttbrukerkontekst mot et nytt on-behalf-of-token
• NAIS_TOKEN_INTROSPECTION_ENDPOINT validerer et token og returnerer tilhørende claims som JSON

Kodeeksemplene under illustrerer enkel bruk av APIet via curl.

curl $NAIS_TOKEN_ENDPOINT \
  -X POST \
  -d 'target=api://<cluster>.<namespace>.<app>/.default' \
  -d 'identity_provider=azuread'

{
    "access_token": "eyJra...",
    "expires_in": 3599,
    "token_type": "Bearer"
}

curl $NAIS_TOKEN_INTROPECTION_ENDPOINT \
  -X POST \
  -d 'token=eyJra...'

{
    "active": true,
    "aud": "client-id",
    "exp": 1732193127,
    "iat": 1732189527,
    ...
}

curl $NAIS_TOKEN_EXCHANGE_ENDPOINT \
  -X POST \
  -d 'target=<cluster>:<namespace>:<application>' \
  -d 'identity_provider=tokenx' \
  -d 'user_token=eyJra...'

{
    "access_token": "eyJra...",
    "expires_in": 3599,
    "token_type": "Bearer"
}

Texas er foreløpig i beta og kun tilgjengelig ved opt-in. Bli med i #texas hvis du vil bidra til at tjenesten blir så nais som mulig!

Les mer og kom-i-gang i dokumentasjonen

Tired of hand-sucking nginx controller annotations? Would you like better living?

Be all you can be? Deprecate old ingresses without too much disruption?

https://docs.nais.io/workloads/application/reference/application-spec/#redirects

You can now add spec.redirects: and send traffic - from: an old ingress to: a new one.

Det er nå mulig å bruke et nais-debug image for å debugge containers i pods.

Se docs her

Det er også støtte i nais-cli via nais debug <appname> (krever oppdatering).

Det finnes også et easter egg i imaget. Se om du kan finne det. (it’s real, not just engagement hacking. )

Har du lyst på en ny SQLInstance til applikasjonen din sier du?

Vi har laget et verktøy for å gjøre det enklere å migrere en applikasjon fra en SQLInstance til en ny. Dette er nyttig når du ønsker å:

• Redusere disken
• Få privat IP, eller
• Har lyst på rollback-mulighet når du oppgraderer til ny versjon av PostgreSQL

Vi er relativt sikre på at det skal fungere som det skal, men løsningen har mange bevegelige deler. Selv om vi har gjort tusenvis av tester så er det en liten mulighet for at noe ikke virker helt som forventet. Vi er derfor veldig interessert i å finne noen som har lyst til å teste det ut, for å få noen ekte erfaringer. Hvis noen prøver og opplever at noe går galt, ta kontakt så hjelper vi dere i mål.

For å komme i gang, se dokumentasjonen vår her

🌟 Ny Vulnerabilities-fane i NAIS Console! 🌟

Hei, kjære venner! Vi er glade for å kunngjøre en ny/gammel “Vulnerabilities”-fane i NAIS Console, som gjør det enklere å holde oversikt over og håndtere sårbarheter i workloadene deres. Denne funksjonen gir en direkte visning av kjente sårbarheter, samt detaljer for å hjelpe dere med å prioritere og håndtere dem effektivt.

Vulnerabilities-fanen i Console viser kritisk innsikt i workloads:

• Raskt vurdere risikonivået for hver workload
• Se sårbarhetsdetaljer for å vite nøyaktig hvilke komponenter som kan trenge oppdatering
• Rangere team basert på sårbarhetshåndtering, slik at dere få en liten innblikk i hvor godt andre jobber med sårbarheter
• Ta handling for å redusere eksponering på tvers av applikasjonene
• Se hvor stor % av din workloads som har en SBOM (100% er målet)
• Se hvordan ditt teams totale risk går nedover, som kan vare veldig tilfredsstillende 🙃 Sjekk det ut i Console eller hvis du er ny kan du lese deg opp her, og gi oss beskjed hvis du har spørsmål eller tilbakemeldinger.

🚀 🔒 Endringer i Github Action - nais/docker-build-push

Vi har gjort noen endringer så nais/docker-build-push er mer robust ifm med rate-limiting ( TOO_MANY_REQUESTS ) ved generering av SBOM. Dette betyr forhåpentligvis at dette steget ikke skal feile lenger (som rapportert fra flere i #nais kanalen).

I tillegg har vi gjort endringer som skal gjøre dette steget en god del raskere enn før! 🎉

Hva må dere gjøre? Ingenting, bare deploye som før!

For de som lurer på hva vi har gjort:

• Innført github cache i nais/attest-sign for det Trivy kaller trivy-java-db - alle kjøringer etter at cachen er satt bør bli en del raskere!
• Støtter fallback i Trivy for flere repositories for trivy-java-db , skal da sørge for at bygget ikke feiler om du blir rate limita på første forsøk
• Satt opp en “passthrough cache” i GAR (google) som speiler/cacher Trivy sitt github repo (som også bør hjelpe på rate limiting)

Si gjerne ifra om ting ikke fungerer som forventet!

Tracing i NAIS deploy

Vi har lagt inn støtte for tracing i NAIS deploy samt docker-build-push, så nå framover vil du ha tilgang på nøyaktig hvor lang tid ting tar i pipelinen din, og besvare følgende:

• Hvor lang tid tok det før committen kom i produksjon?
• Hvor lang tid tar det å bygge Docker-imaget?
• Hvor lang tid tar SLSA SBOM sign & attest?
• Hvor lang tid må jeg vente på at min applikasjon rulles ut i clusteret?

Ut av boksen får man kun svar på det siste punktet, men hvis du følger vår enkle guide til integrering av telemetry så får du all data som er tilgjengelig! 🚀

Link til tracing-dashboard dukker opp som et GitHub step summary når deploy-jobben er fullført.

Kom gjerne med tilbakemeldinger på om dette er nyttig for deg eller hva som kunne gjort det bedre 😄