nais cli støtter verify-audit for å sjekke om databasen er korrekt satt opp for auditlogging.

Det er nå mulig å sjekke oppsettet i sin Cloud SQL Postgres database. Det gjør det litt enklere å verifisere at nødvendige parametere er satt riktig.

Dette gjelder da spesielt for de som har applikasjoner som er underlagt krav om audit logging.

Hvordan gjøres det?

nais postgres verify-audit <appname> [-n team-namespace] [--context gcp-context]

appname må benyttes og angir applikasjonen som eier databasen

team-namespace og gcp-context er valgfrie parametere som spesifiserer hvilket namespace og GCP-cluster som skal benyttes.

Hva gjør kommandoen?

• Verifiserer nødvendige databaseflagg og viser verdien av disse
• Verifiserer pgaudit extension
• Verifiserer konfigurasjon for applikasjonsbrukerens logging

Hvilke forutsetninger gjelder?

• Innlogget bruker
• Medlem av teamet som eier databasen

👉 Les mer og kom i gang i dokumentasjonen

Personlig tilgang til databaser i den nye Postgres-løsningen

Da vi annonserte den nye Postgres-løsningen var det en del ting som ikke var på plass ennå.

Nå har vi løst en av disse tingene: Tilgang til databasen fra utviklermaskin (med naisdevice).

Hvis man har en applikasjon som benytter den nye postgres-løsningen, kan man bruke noen av de samme kommandoene for tilgang som man bruker for CloudSQL.

På grunn av måten den nye løsningen oppretter databaser og roller, så er det ikke lenger nødvendig å bruke grant, prepare, users eller revoke. Alt man trenger er proxy eller psql:

nais postgres proxy <app-navn>  # Setter opp en proxy, som man kan koble til med ønsket postgres-klient.
nais postgres psql <app-navn>   # Setter opp en proxy, og starter psql for deg.

Hvordan fungerer det?

Alle medlemmer i teamet som eier databasen blir lagt til i databasen med en egen rolle for menneskelige brukere.

Denne rollen har lese- og skrive-tilganger ut av boksen. Den har ikke tilgang til å gjøre strukturelle endringer, da slike bør gjøres gjennom applikasjonen.

Når man logger inn i databasen, så benyttes et kortlevd (1 time) token fra login.nais.io, som man får ved hjelp av nais auth login --nais.

Videre planer for den nye postgres-løsningen?

DBA tilgang: I tillegg til at utviklere trenger tilgang til basen så vil det være situasjoner hvor man trenger hjelp av en DBA med utvidede tilganger. Det er derfor planlagt å lage støtte for at DBA’ene skal kunne gå inn i databasene med Superuser-tilgang, men at teamet som eier databasen må gi dem tidsbegrenset tilgang. Her må vi fortsatt finne ut av noen detaljer rundt hvordan det skal fungere og lage mekanismene teamet skal benytte.

Vise frem i Console: Vi planlegger å vise de nye postgres clusterne i Console, på samme måte som CloudSQL instansene.

Katastrofebackups: Vi tar i dag backups (nattlig og PITR) men disse lagres kun i GCP. Vi vil lage løsninger for å få lagret nattlige backups til et annet sted, slik at vi har mulighet for restore i en katastrofe hvor GCP ikke er tilgjengelig. Dette vil antageligvis bygges inn i løsningen som allerede benyttes for CloudSQL.

Migreringshjelp: Vi skal se på mulighetene for å lage verktøystøtte for å migrere fra CloudSQL til Postgres, men dette er fortsatt på tegnebordet så helt nøyaktig hvordan det blir er vanskelig å si.

Det er nå mulig å opprette, konfigurere samt slette både Valkey- og OpenSearch-instanser via Nais Console og Nais CLI. Vi håper med dette å tilby alternative grensesnitt som både er enklere og mer brukervennlige enn tidligere.

Les mer i dokumentasjonen for å komme i gang:

• OpenSearch
• Valkey

Nais CLI har fra versjon 3.3.0 og oppover to nye kommandoer som i første omgang ligger under nais alpha:

nais alpha opensearch

nais alpha valkey

Bruk --help på de respektive subkommandoene for ytterligere dokumentasjon og eksempler.

Eksisterende instanser kan også migreres til nytt oppsett, men vær obs på at ikke alle felter er støttet per nå. Ta kontakt hvis det mangler noen felter dere ønsker støtte for.

• Migrering av eksisterende OpenSearch instanser
• Migrering av eksisterende Valkey instanser

Vi har nå endelig kommet til Kafka i Aiven-vedlikeholdsferden startet mars!

Kafkaspesifikke kubernetes hemmeligheter

Fra og med 10. september vil Nais gi alle nye deploys av apper som benytter Kafka en egen hemmelighet for kafkatilkobling.

Dette fordi

1. Reduserer nedslagsfeltet hvis man bruker flere Aiven tjenester
2. Tillater uavhenging rotering av tilkoblingshemmeligheter av Aiven tjenester

Dette skal ikke ha noen konsekvenser for brukere av Nais og Kafka. Skriv melding i #nais hvis noe skulle feile.

NAIS støtter nå spec.ttl for automatisert opprydding i Naisjob!

Det er nå mulig å angi en TTL (time to live) direkte i spec.ttl for Naisjob — noe som tidligere kun var tilgjengelig for Application-ressurser.

Når TTL-en utløper, slettes ressursen automatisk av NAIS-plattformen.
Perfekt for:

• engangsjobber
• testmiljøer
• midlertidige deploys

av Naisjob, styrt av ttl.

👉 Les mer og kom i gang i dokumentasjonen

Vi eksponerer nå vedlikeholdsvindu til teamets Aiven instanser (OpenSearch og Valkey)! Du finner det ved å klikke inn på en instans i Nais Console. Vedlikeholdsvinduet består av dag i uken, og tid på døgnet.

Sent i fjor introduserte vi Texas i beta. Det er en tjeneste som gjør det meget mye enklere å navigere seg rundt alt av JWTer og OAuth.

Texas er nå automatisk tilgjengelig for alle apper som bruker minst én av:

• Entra ID / Azure AD
• ID-porten
• Maskinporten
• TokenX

I første omgang vil dere ikke merke annet enn at dere får en ekstra container i poddene deres neste gang dere gjør en deploy.

Texas er valgfri å ta i bruk. Det er også helt lov til å bare bruke deler av funksjonaliteten. Vi har ingen planer om å fjerne eksisterende miljøvariabler for de som ikke bruker Texas, men vi håper nå at den gjør livene deres litt enklere hvis dere er i gang med en ny (eller gammel) app som må håndtere tokens.

De av dere som har tatt i bruk Texas under betaperioden kan trygt fjerne annotasjonen texas.nais.io/enabled: "true" fra manifestene deres. Tusen takk til dere som også bidratt med tilbakemeldinger gjennom perioden.

Les mer og kom-i-gang i dokumentasjonen. Med ønske om en riktig nais sommer! ☀️

En ny måte å kjøre postgres i Nais

I en periode har vi i Nais jobbet med å finne en mer kostnadseffektiv måte å kjøre Postgres i Nais. Per i dag så står CloudSQL for omtrent to tredjedeler av alle kostnader i Nais, og vi har derfor sett på alternative løsninger. 💸 Når mange i tillegg opplever at utvikleropplevelsen med CloudSQL er under middels, så har vi sett på alternativer utenfor Google Cloud.

Vi har landet på at vi vil tilby Postgres i Nais via en postgres-operator utviklet av Zalando. 👚 Det vil si at Postgres vil kjøre i Kubernetes clusteret vårt, og dermed komme mye nærmere applikasjonene. På den annen side så har vi lite erfaring med å kjøre stateful workloads i Nais, og dette vil være den mest krevende formen for stateful workloads: databaser. Det er derfor lagt opp til at vi fremover skal jobbe med å forbedre løsningen, men også lære mer om hvordan det er best å kjøre slike løsninger i Nais. :student:

Siden vi i Nais ikke er Postgres-eksperter, og med denne løsningen ikke kan lene oss på Google Support, så er løsningen satt opp i tett samarbeid med Team Database som har lang erfaring med å drifte Postgres databasene våre on-prem.

Denne løsningen er i dag i en eksperimentell fase, og vi ønsker å invitere alle som er interessert til å teste den ut. :scientist:

I løpet av høsten skal vi gjøre ytterligere forbedringer, slik at løsningen etterhvert vil være en fullverdig erstatning for applikasjoner som ønsker å bruke Postgres.

Har du lyst til å teste ut løsningen, så kan du lese mer om den i dokumentasjonen.

Vi har nå fått to nye features relatert til Aiven inn i Console!

Kafkakost

Vi har lenge hatt lyst til å finne en måte å bevisstgjøre kostnadene til Kafka for teamene, og nå lanserer vi første versjon. Siden vi kjører Kafka som en instans, så er det ikke noen direkte kobling mellom et teams bruk, og en kostnad. Derfor har vi laget vår egen forenklet fordeling, som vi tenker gir en pekepinne på hva slags kostnader et team har knyttet til Kafka.

Måten vi har gått frem på er:

• 50% av den totale kostnaden til Kafka fordeles likt på alle team som bruker Kafka. Dette betyr at jo flere som bruker Kafka, jo billigere blir det for alle.
• De resterende 50% av kostnadene blir fordelt på teamets samlete størrelse på topics. Dette betyr at mer data koster mer penger.

Denne fordelingen er ikke skrevet i stein, og det kan hende vi vil gjøre noen mindre justeringer fremover. Kom gjerne med tilbakemeldinger!

Vedlikehold

Du kan nå se vedlikeholdsmeldinger for OpenSearch og Valkey instanser. Disse kommer i to varianter, anbefalt, og påkrevd vedlikehold. De påkrevde vil bli kjørt i neste vedlikeholdsvindu, mens de anbefalte vil bli liggende til det kommer et påkrevd vedlikehold. Man har også muligheten til å starte vedlikehold tidligere enn planlagt ved å trykke på Run all maintenance.

De siste årene har det vært gjort en betydelig innsats for å forbedre observerbarhet i Nais. Først frontend observerbarhet med Faro, og så helhetlig sporing på tvers av applikasjoner med OpenTelemetry Tracing. Alt sammen har integret sømløst med Grafana, som er Nais sitt fortrukne observerbarhetverktøy.

Det har i lengre tid vært mulig for teamene i Nav å sende applikasjonslogger til Grafana i GCP, dette er nå mulig for applikasjoner i FSS fra og med i dag! Dette gir deg som utvikler en helhetlig oversikt over hva som skjer i applikasjonen din, og gjør det enklere å feilsøke og forstå hva som skjer i systemet uansett om applikasjonen din kjører i GCP eller FSS.

Hva skjer videre?

Dette er første skritt i retning for å samle all observerbarhet for applikasjoner på Nais under ett tak i Grafana. Etter hvert kommer logging til Grafana Loki å bli satt som standard for alle applikasjoner. Vi kommer tilbake med mer informasjon om dette og eksakte datoer snart.

I en mellom-periode vil det være mulig å sende logger til både Grafana og Elastic for å sikre en smidig overgang før vi gradvis faser ut Elastic og Kibana fra Nais-plattformen.

Hva må du gjøre?

Du kan allerede i dag ta i bruk den nye loggfunksjonaliteten i Nais. For å gjøre dette må du oppdatere konfigurasjonen til din applikasjon på følgende måte. Hvis du i overgangsperioden ønsker å sende logger til både Grafana og Elastic, må du oppdatere konfigurasjonen din til å sende logger begge steder.

Hvorfor gjør vi dette?

Vi har valgt å gjøre denne endringen for å gi deg som utvikler en bedre opplevelse når det kommer til observerbarhet. Ved å samle all observerbarhet i Grafana, kan vi tilby en mer helhetlig løsning som er enklere å bruke og gir deg bedre innsikt i hva som skjer i applikasjonen din og systemet som helhet på tvers av logger, tracing og metrics.

I tillegg vil dette gjøre det enklere for oss å vedlikeholde og utvikle nye funksjoner i Nais, da vi kan fokusere på én plattform i stedet for flere.

Hva med secure logs?

Secure logs vil bli erstattet med en ny løsning som heter Team logs. Dette vil gi deg den samme muligheten til å sende logger som ikke skal være tilgjenglig for andre team. Denne løsningen baserer seg på Google Cloud Logging og vil gi deg bedre kontroll over hvem som har tilgang til loggene.

Google Cloud Logging er en del av Google Cloud Platform og bor i hvert enkelt team sitt Google Cloud prosjekt og gir deg muligheten til å lagre, søke og analysere loggene dine på en enkel måte. Dette er samme sted som mange av audit loggene fra Nais også blir lagret.

Jeg vil vite mer!

Vi kommer til å sette opp flere informasjonsmøter og workshops for å hjelpe deg med å ta i bruk den nye loggfunksjonaliteten i Nais. Vi vil også oppdatere dokumentasjonen vår for å gjøre det enklere for deg å komme i gang.

Det er fortsatt en del applikasjoner som bruker Postgres 12 i GCP. Vi minner om at Postgres 12 egentlig hadde End-of-Life 21. november 2024, og det er anbefalt å oppgradere til nyere versjoner.

Vi har også fått varsel fra Google om at bruk av Postgres-versjoner som har passert End-of-Life vil ble vesentlig dyrere fra 1. mai. Kjappe overslag antyder omtrent $115 ekstra i måneden per CPU.

Vi anbefaler alle team om å oppgradere Postgres jevnlig, for å unngå å havne alt for langt på etterskudd. Nyeste major versjon av Postgres er 17.

For å oppgradere kan man velge en av disse tilnærmingene:

• Gjøre en enkel in-place oppgradering: https://docs.nais.io/persistence/postgres/how-to/upgrade-postgres/, eller
• Gjøre en migrering til ny instans: https://docs.nais.io/persistence/postgres/how-to/migrate-to-new-instance/

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