Vi har i dag lansert støtte for å kunne deploye endringer i Application/Naisjob uten å bygge et nytt Docker image. 🎉

Frem til i dag har det vært nødvendig å bygge et nytt Docker image hvis du skal deploye endringer i Application/Naisjob, fordi spec’en krever et image og du har ikke det gamle lett tilgjengelig. Vi har nå gjort endringer som gjør at du ikke trenger å ha image i Application/Naisjob i det hele tatt.

Hvis du deployer en Application/Naisjob uten at image er satt, så vil vi finne det forrige imaget du deployet og bruke det. Dette forutsetter at du har gjort en deploy tidligere med WORKLOAD_IMAGE-variabelen satt (se nedenfor).

Hvis du ikke trenger denne muligheten er det ikke nødvendig å gjøre noen endringer.

For at dette skal fungere er det noen endringer du må gjøre i workflowen din:

1. Fjern image fra Application/Naisjob spec’en din.
2. Sørg for at checkout steget i workflowen din henter hele historikken, slik at vi kan slå fast hva som har endret seg siden sist.
3. Legg til et nytt steg som sjekker om det er endringer i spec’en din, f.eks. ved hjelp av nais/what-changed-action.
4. Legg til en if: steps.changed-files.outputs.changed != 'only-inputs' på byggesteget ditt, slik at det kun bygges hvis det er endringer.
5. Sett variabelen WORKLOAD_IMAGE til output fra byggesteget i kallet til nais/deploy.

Se eksempelet i dokumentasjonen vår for hvordan du kan gjøre dette: Build and deploy with GitHub Actions.

Fra og med 20. mars vil Nais rotere tilkoblingshemmelighetene til Valkey og OpenSearch instansene. Servicebrukeren som k8s clusterene til Nais bruker for å tillate tilkobling til Aiven sine Valkey og OpenSearch instanser, vil få sin hemmelighet (til Aiven ressursen) rotert senest hver andre uke. De roteres inn/ut av bruk ettersom relevante Aiven ressurser legges til/fjernes i Nais Application spec, samt tilhørende ReplicaSets i k8s.

Les mer om OpenSearch i Nais docen her. Les mer om Valkey i Nais docen her.

Vi ser at vi ikke har fått til det vi ønsket med spa-deploy, og for å lette byrden på teamet velger vi å sanere og rydde bort denne Github actionen. Dette vil ikke påvirke tjenestene som allerede bruker action, og ingressene som har blir opprettet vil ikke bli ryddet bort. Vi fjerner kun selve Github action, så hvis du er et av de 10 teamene som bruker den, må dere gjøre en liten migrering vekk fra spa-deploy, over til cdn-upload.

- uses: nais/deploy/actions/spa-deploy/v2@master
  with:
    team: security-champion-admin
    app: playbook
    environment: prod
    source: build
    ingress: https://sikkerhet.nav.no

må endres til

- name: Upload static files to CDN
  uses: nais/deploy/actions/cdn-upload/v2@master
  with:
    team: security-champion-admin
    source: build
    destination: playbook/prod

destination er kombinasjon av app og environment.

Fra og med 1. april vil vi kreve at applikasjoner og jobber på Nais bruker images som kommer fra teamets eget repository i Google Artifact Registry/GAR. De fleste gjør allerede dette, så for de er det ingen endring.

Det er to hovedgrunner til at dette nå blir håndhevet:

1. Vi kan da være sikre på at det er en autorisert Nais-bruker eller repository som har lastet det opp. Med audit logg.
2. Teamets repository ligger nærmere clusteret, og støtter Image Streaming som gjør at oppstartstid ved f.eks autoskalering eller plattform-vedlikehold er rask.

Den enkleste måten å sikre at imagene havner riktig sted er å bruke Nais’ github actions i workflowet sitt. Da trenger man ikke ha et aktivt forhold til hvor imaget ligger lagret, og alt går av seg selv.

Console vil fra nå og frem til 1. april gi en advarsel om dette.

Les mer om image repositories i Nais-dokumentasjonen.

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"
}

Fordeler med Texas:

• Agnostisk til programmeringsspråk og rammeverk (gitt at det kan snakke HTTP)
• Innebygget best practices — caching av tokens og validering av det viktigste
• Ingen kodeavhengigheter — du slipper å dra inn ekstern kode som må gjennomgås og vedlikeholdes. Dette reduserer antall potensielle kilder til sårbarheter.
• Du slipper å forholde deg til hemmeligheter i applikasjonskoden

Texas er foreløpig i beta for et utvalg identity providere. Yihaa!

Les mer og kom-i-gang i dokumentasjonen