Vi lanserer nå en ny deploy-løsning i Nais. Denne løsningen består av to deler.

• nais/setup er en GitHub Action som setter opp Nais CLI i workflowen deres.
• nais apply deployer manifestene med Nais CLI.

Vi lanserer også V3 av nais/deploy/actions/deploy, denne støtter eksisterende manifester og templating, men bruker Nais CLI under panseret. For de fleste team er det nok å oppdatere nais/deploy/actions/deploy-actionen til v3.

nais apply og nais/setup

Dette er den nye anbefalte måten å konfigurere GitHub actions på. nais/setup setter opp Nais CLI i workflowen deres, og nais apply deployer manifestene med Nais CLI.

Dokumentasjonen er oppdatert med et eksempel på hvordan dette kan settes opp i en GitHub Actions workflow.

nais apply støtter eksisterende Kubernetes-manifester, men også nye Nais-manifester (mer om dette under).

Det er også en endring i hvordan templating håndteres, les mer om dette i dokumentasjonen for mixins.

Den nye løsningen lager ikke “deployments”, men lagrer endringer og informasjon i aktivitetsloggen. Denne inneholder mer informasjon enn tidligere, og gir bedre innsikt i hva som har endret seg.

Dette må dere gjøre

Dere trenger ikke migrere eksisterende manifester nå. Kubernetes-manifestene dere bruker i dag, fortsetter å virke.

Har dere allerede en workflow med nais/setup og nais apply, kan den vanligvis fortsette uendret. Det er innholdet i manifestet som endres når dere tar i bruk det nye formatet.

For nye workflows anbefaler vi:

1. Legg manifestene i .nais/ i repositoryet.
2. Bruk nais/setup til å sette opp Nais CLI og velge team.
3. Bruk nais apply til å deploye til ønsket miljø.

steps:
  - uses: actions/checkout@v6
  - uses: nais/setup@v1
    with:
      team: mitt-team
  - run: nais apply .nais/opensearch.yaml --environment dev-gcp

Ta gjerne i bruk Nais-formatet når dere oppretter en støttet ressurs, eller neste gang dere endrer manifestet.

Nais-manifester

Samtidig begynner vi å innføre Nais-manifester. Dette er vår langsiktige retning for å beskrive ressurser i plattformen. I stedet for Kubernetes-manifester er Nais-manifester mer spesialiserte for det platformen tilbyr.

Nais-manifester gir et grensesnitt som beskriver Nais-ressurser uten at dere må forholde dere til Kubernetes-spesifikke felter og andre implementasjonsdetaljer.

Manifestene sendes gjennom Nais API. Det gir felles validering, tilgangsstyring og aktivitetslogging, og gjør at de samme ressursene kan forvaltes gjennom både Nais CLI og Console.

Valkey og OpenSearch er de første ressursene som kun bruker det nye oppsettet:

• Eksempel på Valkey-manifest
• Eksempel på OpenSearch-manifest

På sikt vil flere Kubernetes-manifester bli erstattet av Nais-manifester. Det finnes foreløpig ingen sluttdato for dagens oppsett, og eksisterende manifester kan fortsatt brukes.

Prøv gjerne den nye deploy-veien, og gi oss tilbakemeldinger på Slack.

Hvorfor Nais-manifester?

De siste årene har vi jobbet med et eget API på toppen av plattformen. Selv om Nais fortsatt kjører på Kubernetes under panseret, sendes de nye Nais-manifestene til vårt eget API via Nais CLI – ikke direkte til Kubernetes.

Dette gir flere store fordeler:

• Bedre sporbarhet og tilgangsstyring: Vi får sentral aktivitetslogging (audit logs), tydeligere validering og mulighet for strengere sikkerhetsmekanismer som just-in-time access (JITA).
• Flere flater: Med et felles API kan vi tilby oppretting og endring av ressurser på tvers av verktøy – både i GitOps, Nais CLI og direkte i Nais Console.

Dokumentasjon:

• Bygg og deploy med GitHub Actions
• Opprett Valkey med GitHub Actions
• Opprett OpenSearch med GitHub Actions
• Forstå Nais-manifester

Hva betyr dette for kubectl?
Du kan fortsatt bruke kubectl til feilsøking og inspeksjon som før. Men fordi tilgangsstyringen strammes inn, kan ikke nye ressurser som Valkey og OpenSearch opprettes eller endres via kubectl. Enkelte sensitive ressurser (som secrets) krever JIT-tilgang for i det hele tatt å kunne leses.

Det er nå mulig å sette labels på ressurser i Nais. Labels er nøkkel-verdi-par du definerer selv for å organisere og kategorisere ressursene dine.

Labels settes under metadata.labels i manifestet:

metadata:
  labels:
    team-area: payments
    sensitive: "true"

For Valkey, OpenSearch, Config og Secrets kan labels også legges til og redigeres direkte fra Console. Labels kan brukes for å filtrere ressurser i Console.

Se dokumentasjonen for detaljer.

Vi har satt opp en felles Loki-installasjon i management-clusteret som samler logger fra alle clustere.

Hvorfor?

• 🚀 Bedre ytelse – Én stor instans håndterer spørringer mer effektivt enn mange små
• 💰 Lavere kostnader – Vi sparer ressurser ved å konsolidere til én installasjon

Hva betyr dette for deg?

• Datasource: Bruk datasourcen Logs i Grafana for å se logger
• Skille mellom clustere: Bruk labelen k8s_cluster_name for å filtrere på ønsket cluster

Eksempel på spørring:

{k8s_cluster_name="prod", service_name="min-app"}

⚠️ Viktig å vite

• De gamle per-cluster Loki-instansene (datasources som prod-gcp, dev-gcp) vil bli faset ut om to uker
• I overgangsperioden fungerer begge, men vi anbefaler å begynne å bruke Logs allerede nå

Team med mange workloads som deler samme image ser ofte den samme CVE-en flagget flere ganger. Tidligere måtte man undertrykke hver enkelt manuelt en om gangen. For et team med ti workloads betyr en falsk positiv minst ti klikk.

Det er nå mulig å undertrykke en sårbarhet for flere workloads i en operasjon direkte fra Console. Funksjonen finner du på teamsiden under “Vulnerabilities” ved å bruke søkefeltet “Search for vulnerability”. Søk opp sårbarheten, velg hvilke workloads som er berørt, angi årsak, og det er gjort.

Siden undertrykkingen er knyttet til selve imaget og ikke den enkelte workloaden, trenger man bare å gjøre det en gang per unikt image selv om mange workloads bruker det. Endringen vises umiddelbart i sårbarhetsoversikten.

Dette er en del av det løpende arbeidet med å gjøre sårbarhetshåndtering mindre støyete og mer handlingsrettet for team på Nais.

Console har fått seg en real overhaling. Hensikten er å gjøre det enklere å forstå og gi bedre oversikt over hva som skjer.

Det er ganske mye som endrer seg i denne oppdateringen, så vi lister opp noen highlights:

• Oversiktssiden til teamet gir nå en rask oversikt på status på tvers av alle applikasjoner og jobber.
• Oversiktssiden til apper og jobber oppsummerer og viser de mest relevante tingene for workloaden
• Vi byttet tidligere ut sidemenyen når man var inne på en app eller job, dette er nå tabs i steden.
• Alle handlinger man kan gjøre på en workload er samlet under en Actions-meny. (Restart, Stop, Resize, Set env variables, view manifest og Delete)
• Filter og sortering finnes nå i sidemenyen på workloads og activityLog; det kommer fler senere.

Bruk gjerne Feedback-knappen i Console om du har tilbakemeldinger.

Som vi annonserte i juni i fjor, så jobber vi med en helt ny måte å kjøre PostgreSQL i Nais.

I løpet av året har vi lært mye, implementert og endret mye i bakgrunnen og gradvis bygget opp løsningen til noe som nærmer seg produksjonsklart.

For ca. 8 uker siden tok vi en fot i bakken og oppsummerte hva vi hadde lært, hva vi følte manglet, og hvordan vi skulle fortsette. Oppsummeringen er at vi har fortsatt god tro på at det er mye å hente på å kjøre PostgreSQL i clusterne, både i form av kostnadsbesparelse, utvikleropplevelse og plattformdrift. Vi er også ganske fornøyd med utviklergrensesnittet vi har lagt opp til, med en Postgres ressurs som beskriver databasen og en referanse fra Application/Naisjob.

Det vi derimot har mistet litt troen på er at Zalando sin postgres-operator er veien å gå. Zalando har skiftet fokus til å kun fokusere på sine egne behov (og ikke open-source community), og der vi opplever problemer med operatoren så er det avhengig av at Zalando har det samme problemet for at det skal bli tatt tak i.

Før vi landet på Zalando i første omgang så evaluerte vi også cloudnative-pg, men kom til at prosjektet var for ungt og ustabilt. Etter at vi fant ut at vi ikke var helt fornøyd med Zalando så tok vi en kort test av cloudnative-pg, for å se om de hadde løst noen av problemene vi fant i forrige evaluering for godt over et år siden. Konklusjonen etter den testen er at vi har lyst til å prøve cloudnative-pg i stedet for Zalandos postgres-operator.

Det betyr at vi må ta noen steg tilbake og skrive om en del av det vi har gjort så langt, og eksisterende pilotbrukere vil være nødt til å migrere databasene sine når vi kommer så langt. Inntil vi er klare med endringene så ønsker vi at teamene venter med å opprette nye databaser på denne løsningen.

Planen nå er at vi frem mot sommeren skal jobbe med å implementere cloudnative-pg i plattformen der vi tidligere har brukt Zalando postgres-operator. Eksisterende brukere vil kunne fortsette med de basene de har inntil videre, men vil nok bli anmodet om å migrere etter sommeren en gang. Vi kommer til å se på om det kan gjøres automatisk på noe vis, vi vil kontakte aktuelle team med mer detaljer når det er klart.

Vi forventer å ha produksjonsklare databaser tilgjengelig tidlig i høst.

Vi har gjort et aldri så lite løft i Nais CLI. Vi har introdusert funksjonalitet som tidligere bare har vært tilgjengelig i Console i form av en drøss med nye kommandoer som det bare er å kaste seg over.

Noen kommandoer har også blitt flyttet ut av nais alpha til roten av Nais CLI:

nais api --help # Commands for interacting with the Nais API
nais log --help # Show logs for a team

For å gjøre det enklere å finne ut av hva Nais CLI har å tilby har vi fått på plass https://cli.nais.io/.

Det er nå mulig å opprette og administrere config (ConfigMaps) via Nais Console og Nais CLI.

Config fungerer på samme måte som secret, men for konfigurasjon som ikke er sensitiv. key/value-par kan mountes som miljøvariabler eller filer i workloads. I motsetning til hemmeligheter kreves det ingen begrunnelse eller tidsavgrenset tilgang for å se verdiene.

Det er også støtte for binære filer. Verdier sendes da som base64-kodet data, og lagres og hentes korrekt uten tap av innhold.

I Console finner du Config under teamet ditt. Derfra kan du opprette, redigere og slette configs, administrere key/value-par, og se hvilke workloads som bruker dem.

I CLI er det en ny config-kommando med følgende subkommandoer:

nais config list        # List configs for teamet
nais config get         # Se detaljer og nøkkel/verdi-par
nais config create      # Opprett ny config
nais config delete      # Slett en config
nais config set         # Sett nøkkel/verdi-par
nais config unset       # Fjern nøkler
nais config activity    # Se aktivitetslogg

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

Dersom teamet ditt allerede har configMaps, kan man legge til disse i nais ved å legge på følgende label på configMap:

metadata:
  labels: nais.io/managed-by=console

Les mer i dokumentasjonen.

Vi har lagt til tre nye kommandoer i Nais CLI som gir deg midlertidige credentials for Valkey, OpenSearch og Kafka. Dette er nyttig for eksempel ved lokal utvikling eller feilsøking der du trenger direkte tilgang til en av disse tjenestene.

Nye kommandoer

nais valkey credentials <instansnavn> -e <miljø> -p <READ|WRITE|READWRITE|ADMIN> --ttl <varighet>
nais opensearch credentials <instansnavn> -e <miljø> -p <READ|WRITE|READWRITE|ADMIN> --ttl <varighet>
nais kafka credentials -e <miljø> --ttl <varighet>

Credentials skrives til stdout som miljøvariabler, klare til å sources direkte. For Kafka kan du i tillegg bruke --output kcat eller --output java for å få ferdig konfigurerte filer.

Maksimal levetid er 30 dager. All bruk logges i aktivitetsloggen.

Erstatter nais aiven

Disse kommandoene erstatter de gamle nais aiven create-kommandoene, som er markert som deprecated. Den gamle flyten var avhengig av direkte tilgang til Kubernetes-hemmeligheter, noe som ikke lenger er tilgjengelig. De nye kommandoene går via Nais API og krever kun at du er autentisert med nais login.

Oppdater til siste versjon av Nais CLI for å ta i bruk de nye kommandoene.

Vi har nylig gjort endringer i nais cli hvor navnet på miljøet (environment) tar en mer fremtredende plass. Dette har ført til noen problemer der navnet brukt i kubeconfig ikke har matchet navnet på miljøet.

Dette problemet har først og fremst rammet utviklere utenfor Nav, fordi i Nav har vi av legacy-grunner gjort omskriving av navnet i kubeconfig.

I nyeste versjon av nais cli så gjør vi nå en omskriving av context når vi genererer kubeconfig slik at navnet i kubeconfig vil være det samme som miljø-navnet brukt andre steder i plattformen.

Hvis du ønsker å fjerne de eksisterende contextene i kubeconfig og bare ha de med nye navn kan du kjøre nais kubeconfig --clear.

Aiven har annonsert at de avslutter støtte for OpenSearch v1 og v2.17 fra 2026.07.26. Alle instanser av OpenSearch som kjører disse versjonene vil bli tvangsoppgradert til v2.19 i neste vedlikeholdsvindu etter denne datoen.

Vi oppfordrer alle team til å ta kontroll på denne oppgraderingen ved å gjøre det selv på et tidspunkt som passer dem. Oppgradering kan gjøres gjennom Console.

Når man har kommet opp på v2.19 er det også mulig å oppgradere videre til v3.3.

Se også Aiven sine announcements med mer detaljer:

• Deprecation: Aiven for OpenSearch® version 1
• Deprecation: Aiven for OpenSearch® 2.17
• Upgrade to OpenSearch® 3.3.2

Tidligere har Nais plattformen gjort det mulig for utviklere å skaffe seg en servicebruker for å kunne aksessere topics i Kafka clustere, ved hjelp av nais aiven kafka create CLI kommandoen. Denne kommandoen opprettet nødvendig servicebruker hos Aiven, men man måtte selv sikre seg å (på rett måte):

• ordne lese/skrive/annen rettigheter
• til én og enhver topic
• manuelt selv

For å kunne støtte oppunder utviklere som har behov for å for eksempel (ikke uttømmende liste):

• manuelt flytte på offset til en Kafka topic tilbake i tid
• resette topicene til en Kafka Stream

har vi nå lagt til en ny gruppe subkommandoer til https://github.com/nais/cli!

$ nais aiven grant-access --help
Grant a user access to an Aiven service.

Usage:
  nais aiven grant-access [command]

Available Commands:
  stream      Grant a user's service-user access to a Kafka Stream.
  topic       Grant a user's service-user access to a Kafka Topic.

Flags:
  -h, --help   help for grant-access

Global Flags:
      --config string   Specify the location for the configuration file. (default "/home/x10an14/.config/.nais/config.yaml")
      --no-colors       Disable colors in the output.
      --team string     Specify the team to use for this command. Overrides the default team from configuration.
  -v, --verbose count   Set verbosity level. Use -v for verbose, -vv for debug, -vvv for trace.

Use "nais aiven grant-access [command] --help" for more information about a command.

En tenkt fremgangsmåte kan da være at man benytter seg av følgende kommandoer i denne rekkefølgen:

$ nais aiven create kafka ...
$ nais aiven get kafka ...
$ nais aiven grant-access <topic|stream> ...

Les oppdatert dokumentasjon til Nais CLI verktøyet igjennom bruk av --help flagget, evnt. les mer hos https://docs.nais.io/operate/cli/reference/aiven/#grant-access!

For å øke sikkerheten rundt håndtering av hemmeligheter i Nais, har vi gjort noen endringer i default-tilgangen til hemmeligheter.

Der man tidligere hadde en permanent tilgang til alle hemmeligheter i sitt team, har vi nå innført en mer restriktiv policy. Før man får lesetilgang til verdiene i en hemmelighet, må man i oppgi en begrunnelse.

Tilgangen gis automatisk, loggføres og varer i 5 minutter.

Bakgrunnen for denne endringen er å redusere risikoen for utilsiktet eller ondsinnet tilgang til sensitive data dersom man blir utsatt for et eksfiltreringsangrep eller lignende.

Vi har gleden av å lansere en ny funksjon i Nais Console som gir teamene mer kontroll over sin Unleash-instans: Release Channels! 🎉

Med release channels kan du nå selv velge hvilken versjon av Unleash feature toggle-serveren teamet ditt skal kjøre – direkte fra Console.

⚠️ Viktig: Unleash v5 er End of Life

Unleash v5 er ikke lenger støttet. Hvis teamet ditt fortsatt kjører v5, anbefaler vi sterkt at dere oppgraderer til v6 eller v7 så snart som mulig.

5. februar 2026 vil alle Unleash-instanser som fortsatt kjører v5 automatisk bli oppgradert til v6.

Tilgjengelige Release Channels

unleash-v7 (anbefalt)

Dette er den nyeste versjonen og anbefales for alle team. Høydepunkter:

• 🧹 Automatiske opprydningspåminnelser – få varsler når feature flags bør fjernes
• 🔗 Eksterne lenker på feature flags – koble flags til metrics, analytics eller issue trackers
• 🎨 Farger på tags – enklere visuell differensiering av flags
• 📊 Forbedret flags-oversikt – bedre oversikt over livssyklus og status

Viktige endringer fra v6:

• Flere deprecated API-endepunkter er fjernet
• “Search” er omdøpt til “Flags overview”
• “Health” er omdøpt til “Technical Debt”

unleash-v6 (støttet til juli 2026)

Et godt alternativ hvis du trenger litt mer tid før du går til v7:

• 🎯 Nytt sidemeny-design – enklere navigasjon
• 🔍 Forbedret prosjektoversikt – bedre søk og filtrering av feature flags
• 📝 “Feature toggle” omdøpt til “feature flag” – oppdatert terminologi

Viktige endringer fra v5:

• Environment variants er faset ut (bruk strategy variants i stedet)
• Legacy /api/features endpoint er fjernet

Slik bytter du Release Channel

1. Gå til teamets Unleash-side i Nais Console
2. Finn “Release Channel” og klikk på blyant-ikonet
3. Velg ønsket channel fra dropdown-menyen

Sjekk SDK-kompatibilitet før oppgradering

Før du bytter til en nyere versjon, er det viktig å sjekke at applikasjonene dine bruker SDK-versjoner som støtter den nye Unleash-versjonen. Se Unleash SDK-kompatibilitetsmatrise for detaljer.

Lenker og hjelp

• Unleash-dokumentasjon på Nais
• Unleash upgrade guide
• SDK-kompatibilitetsmatrise

Har du spørsmål eller trenger hjelp? Ta kontakt i #unleash på Slack!

Ved neste rotering (neste deploy etter helgen antageligvis) av secret for OpenSearch og Valkey, vil det dukke opp noen flere felter.

For alle OpenSearch instanser så vil det nå også være mulig å finne URI, host og port for Dashboardet. Dette er neppe relevant for applikasjonen direkte, men gjør det lettere for utviklere å se hva disse verdiene er. Bruk nais cli for å få en secret hvor disse verdiene er synlige. Mer informasjon i dokumentasjonen.

For Valkey instanser på business eller premium plan (med flere noder), så har de alltid hatt en read replica som tidligere har vært skjult for applikasjonene. De instansene som har disse vil nå få ekstra felter i secreten for å kunne snakke med replica, for leseoperasjoner. Mer informasjon i dokumentasjonen.

clamav er utvidet med endepunktet /api/v2/scan

Det er lagt til et nytt endepunkt for clamav som kan benyttes internt i nais clustere. Endepunktet er relativt likt med /scan, men gir litt mer informasjon tilbake til klienten.

Det opprinnelige endepunktet /scan vil fortsatt være tilgjengelig og fungerer som tidligere. Så ingen endringer er påkrevd for de som allerede benytter clamav-rest med mindre man ønsker.

Takk til Landbruksdirektoratet for å ha bidratt med endringsønsker, testing og tilbakemeldinger underveis.

Hva er nytt?

Tidligere har man kun fått tilbake et resultat sier om virus er funnet eller ikke og filnavnet.

Nytt endepunkt vil i tillegg returnere hvilket virus som evt er funnet og feilmelding dersom noe uforutsett skjer.

Nytt endepunkt vil returnere HTTP/200 selv om en feil inntreffer under skanningen, men da med informasjon om hvilken feil som oppstod (fra gammelt endepunkt fikk man HTTP/500).

Hvordan endre til det nye endepunktet?

• Kode må endres for endepunktet: /scan -> /api/v2/scan
• Kode må endres for å håndtere nytt resultatformat
• Kode må endres for å håndtere feilmeldingene som kan returneres

Endringene beskrevet i for tjenesten dokumentasjonen.

👉 Les mer i nais-dokumentasjonen

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

:rip: 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! :sunny:

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

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. :money_with_wings: Når mange i tillegg opplever at utvikleropplevelsen med CloudSQL er under middels, så har vi sett på alternativer utenfor Google Cloud. :old-man-yells-at-gcp:

Vi har landet på at vi vil tilby Postgres i Nais via en postgres-operator utviklet av Zalando. :womans_clothes: 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. :tada:

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