Testnav Dokumentasjon

1. Introduksjon

Testnav-Monorepo er et samlerepo som inneholder frontend- og backend-applikasjoner som støtter tjenester knyttet til Dolly og syntetiske testdata.

1.1. Om

Dette er en samlet dokumentasjon for applikasjoner, retningslinjer og støtteverktøy relatert til syntetiske testdata i NAV. Spesisfikke søke kan gjøres i søkefelt øverst til høyre.

2. Dolly

Dolly er NAVs selvbetjeningsløsning for å opprette syntetiske data.

2.1. Brukerveiledning

Dolly er NAVs selvbetjeningsløsning for å opprette syntetiske data. I Dolly kan du opprette syntetiske personer med forskjellige egenskaper, og tilgjengeliggjøre dataene i valgte testmiljøer.

Link til Dolly: https://dolly.ekstern.dev.nav.no/

Et omfattende eksempel på bestilling av tilgang til dolly samt noe bruk av dolly er tilgjengelig på team helsearbeidsgiver sine docs her: https://github.com/navikt/sykepenger-im-lps-api/wiki/Testdata

2.1.1. Pålogging

Dolly benytter seg nå av Single Sign On (SSO) som fører til at du blir innlogget gjennom dette systemet. Du vil derfor som oftest være logget inn på din bruker med en gang du åpner Dolly.

Det første som møter deg når du har logget inn er en startside med noen menyvalg. Siden åpnes automatisk med en oversikt over dine grupper.

Startside

Noen ganger vil du bli møtt av en eller flere meldinger når du åpner Dolly, f.eks. om det er første gang du bruker applikasjonen, eller om det har dukket opp nyheter. Det er viktig at du leser disse meldingene, da de inneholder nyttig informasjon om bruk av Dolly.

Varslinger

2.1.2. Opprette en ny gruppe

For å opprette nye syntetiske personer i Dolly kan du enten lage en ny gruppe eller legge til personer i en eksisterende gruppe. En gruppe inneholder personer du eller teamet har opprettet.

Under Mine vises grupper opprettet av deg selv. Under Alle vises dine og andres grupper. En god regel er at du ikke endrer andres grupper uten avtale med eieren.

Trykk på Ny gruppe og velg navn og beskriv hensikten med gruppen. Når hensikten er beskrevet er det enklere for både deg selv og eventuelt andre du samarbeider med å forstå hva denne gruppen brukes til. Trykk Opprett og gå til gruppe.

Testdatagrupper

Inne på gruppen har du en oversikt over alle personene som tilhører gruppen og hvilke egenskaper de har. Her kan du også legge til nye personer.

Ny testdatagruppe

Det kommer opp en boks der du får to valg:

  1. Opprette helt nye personer (Dolly finner et ubrukt fnr, dnr eller bost)

  2. Opprette fra eksisterende fnr, dnr eller bost (identen kan ikke finnes i prod eller i Dolly)

Vi velger å opprette nye og angir at vi ønsker 10 personer i bestillingen.

Opprettelse av personer følger en prosess med fire steg:

Opprettelse prosess

  1. Angi identtype, antall identer og hvilken gruppe disse skal havne i.

  2. Velg hvilke egenskaper du selv ønsker å bestemme. De resterende egenskapene vil systemet sette.

  3. Angi verdier på egenskapene du valgte i steg 1.

  4. Oppsummering og valg av hvilke testmiljø personene skal sendes til.

2.1.2.1. Velg identtype, antall og gruppe
Velg ny person

I dette vinduet velger du om du ønsker å opprette personer med nye identer eller om du ønsker å opprette personer med eksisterende identer. Man kan også velge antall personer som skal opprettes og hvilken gruppe de skal legges til i, samt eventuell mal for bestillingen.

2.1.2.2. Velg egenskaper
Velg egenskaper

Det finnes en lang rekke områder med egenskaper du kan velge. Trykk på pil ned til høyre i boksen for å ekspandere hvert område. I de fleste tilfeller er det kun et utvalg egenskaper som er nødvendig å definere for testscenariene dine. Dolly tildeler verdier til egenskaper du ikke krysser av for.

I dette eksemplet ønsker vi å teste endringer i arbeidsforhold og krysser av for følgende egenskaper:

Valgt egenskap

Team Dolly videreutvikler Dolly kontinuerlig og nye egenskaper legges til fortløpende. Savner du noe, meld inn på Slack-kanalen #dolly.

Når du har angitt aktuelle verdier for egenskapene trykk videre og velg miljø.

For mer informasjon om NAVs testmiljøer se: https://confluence.adeo.no/pages/viewpage.action?pageId=305341700

Miljøvalg

Velg miljø, og opprett en mal dersom denne bestillingen skal gjentas senere. Kommentar kan brukes til å gjenkjenne identen senere, da denne vil vises ved hover i personlisten.

Opprettet gruppe

Gruppen har fått nye personer og du kan jobbe med disse i relevante fagsystemer. Trykk på pil ned til høyre på raden for detaljinformasjon per person.

2.1.3. Legg til eller endre person

Denne funksjonaliteten lar deg legge til ekstra egenskaper på en eksisterende ident eller endre verdier på allerede eksisterende egenskaper. For å legge til ekstra egenskaper på en eksisterende person: åpne detaljvisning for personen, trykk LEGG TIL/ENDRE og velg egenskaper.

2.1.3.1. Demo - Legg til/endre

2.1.4. Flytte identer mellom grupper

Dolly har mulighet til å flytte identer mellom grupper ved å trykke "Flytt personer" i menyen under header på en gruppe. Dette kan være nyttig hvis du ønsker å samle personer med lignende egenskaper i samme gruppe, eller ønsker at noen andre skal ta over eierskap til visse identer.

Flytte identer
2.1.4.1. Demo - Flytte identer

2.1.5. Opprette og bruke maler

Når du oppretter en ny person i Dolly kan du velge å lagre bestillingen som en mal. Malen kan senere hentes av deg selv eller andre og gir en ferdigutfylt bestilling.

For å lage en mal huk av for Lagre som mal på siste steg i prosessen. Gi malen et beskrivende navn.

Opprette mal

For å bruke en mal: i første steg huk av for Maler, velg bruker (deg selv eller annen) og deretter ønsket mal.

Bruk mal

Du kan endre verdier før innsending.

Du vil også finne en oversikt over maler på "Min side" i menyen øverst til høyre.

Min side
2.1.5.1. Demo - Opprette og bruke maler

2.1.6. Team-funksjonalitet

Team gjør det mulig å samarbeide på de samme gruppene i Dolly. Et team er en samling av Dolly-brukere som alle har tilgang på de samme dataene. Du kan velge om du representerer deg selv eller et team. Når du representerer et team vil alt du oppretter av grupper, personer og maler tilhøre teamet og ikke deg selv.

2.1.6.1. Valg av representasjon

Brukermenyen øverst til høyre viser deg selv og alle team du er medlem av. Når du velger et team endres visninger som mine grupper til å heller vise teamets grupper. Øverst til høyre ser du alltid hvem du representerer.

2.1.6.2. Team-oversikt

I brukermenyen finnes nå ett nytt valg for team-oversikt. Denne siden viser alle team du er medlem av og lar deg forlate, redigere og slette team.

Her kan du: * Opprette nye team * Slette team du eier som ikke har medlemmer eller data * Legge til eller fjerne medlemmer i team du er medlem av * Bli med i eller forlate eksisterende team.

2.1.6.3. Opprette nytt team

  1. Åpne Team-oversikt

  2. Velg Opprett team

  3. Fyll inn navn og beskrivelse

  4. Legg til medlemmer (kan eventuelt gjøres senere)

  5. Lagre

Dette teamet kan nå velges ved å trykke på brukernavnet ditt øverst til høyre og velge team isteden. Mens du representerer teamet lagres nye grupper, personer og maler på teamet.

2.1.6.4. Bli med i eksisterende team

  1. Åpne Team-oversikt

  2. Velg Bli med i team

  3. Finn og velg team

  4. Bekreft

Etter innmelding kan du på samme måte som over bytte representasjon til teamet fra brukermenyen.

2.1.6.5. Demo: Team-funksjonalitet
2.1.6.6. Tips

  • Bytt tilbake til deg selv for personlige grupper og maler

  • Gruppene som allerede tilhører din egen bruker kan enkelt flyttes til et team ved å gå til gruppen mens du representerer deg selv og velge "Bytt Eier" i gruppe-menyen

  • Kontroller at du representerer ønsket team eller deg selv før du oppretter nye data

2.1.7. Test-Norge

Test-Norge er en felles offentlig testdatapopulasjon, som ble laget av Skatteetaten i forbindelse med nytt folkeregister. Populasjonen er levende og endrer seg fortløpende ved at personer fødes, dør, får barn osv. Populasjonen har syntetiske fnr/dnr hvor det er lagt til 80 på måned. Hele Test-Norge populasjonen er tilgjengelig i PDL.

2.1.7.1. Søk og import

Under Test-Norge fanen i Dolly er det mulig å søke opp Test-Norge identiteter i Dolly, velge identiteter man ønsker å ta i bruk, velge ekstra informasjon som skal legges til og importere dem inn i en ønsket gruppe i Dolly. Videoen under viser en demo.

For å finne mer spesifikke identiteter kan Skatteetatens testdataskjermsøsning Tenor brukes: https://www.skatteetaten.no/skjema/testdata Tenor er ikke koblet opp mot Dolly, men identiteter funnet i Tenor kan søkes opp i Dolly og importeres til en ønsket gruppe.

2.1.7.2. Import av partner

Det er mulig å inkludere valgte personers partnere i import uten å velge dem på forhånd. Hvis valgt person har en partner som ikke allerede er valgt kan man huke av for IMPORT MED PARTNER for å inkludere den. Bildet under viser et tilfelle hvor import av partner er valgt.

Import med partner

Det er også mulig å importere partner etter opprinnelig import. Dette kan gjøres direkte i personvisning.

2.1.7.3. Demo: Søk i Tenor og import til Dolly

NB: Når man frigjør eller sletter en Test-Norge person fra Dolly vil også eventuell importert partner bli frigjort eller slettet.

2.1.7.4. ID-Porten

Vi anbefaler bruk av TestID når man skal teste ID-Porten ved bruk av importert Test-Norge ident.

2.1.8. Diverse demoer av Dolly

2.1.8.1. Opprette personer med tilfeldige verdier
2.1.8.2. Opprette person med ønskede verdier

2.2. Endringsmelding (status)

Øverst i menyen kan du velge endringsmelding. Her kan du sende inn fødselsmelding eller dødsmelding til ønsket testmiljø. Dette er en separat applikasjon med egne tilganger.

Merk: Kun én person per melding. Funksjonaliteten vil bli erstattet; bruk Dolly-funksjonene for fødsels- og dødsmeldinger:

  • Fødselsmelding: Gå til gruppe, finn forelder, velg Legg til/endre og kryss av Barn eller bruk Legg til relasjoner.

  • Dødsmelding: Gå til gruppe, velg Legg til/endre og kryss av Dødsdato.

For personer som ikke eksisterer i Dolly: Opprett person, velg Eksisterende person og skriv inn ident.

Endringsmelding

2.3. API-dokumentasjon

Øverst i menyen ligger en lenke til API dokumentasjon (Swagger) for tilgjengelige API-er.

API dok

2.4. Feil ved innlogging

Tvungen utlogging

Hvis du gjentatte ganger blir logget ut eller ikke kommer inn kan det skyldes cookies.

2.5. Retningslinjer Dolly

Retningslinjer for bruk og forvaltning av Dolly, basert på overordnede retningslinjer for syntetiske testdata i NAV.

2.5.1. Hensikt, målgrupper og ansvar

Syntetiske testdata skal brukes i utvikling og forvaltning av NAVs IT-løsninger. Ved unntaksvis bruk av produksjonsdata gjelder spesielle sikkerhetstiltak. Disse føringene er sentrale for å minimere og sikre kontroll med bruken av persondata:

  • Syntetiske testdata kan ikke kobles til reelle personer og er ikke personopplysninger

  • Produksjonsdata kan direkte eller indirekte knyttes til en enkeltperson og må håndteres som personopplysninger som må beskyttes gjennom tilgangskontroll, maskering, logging m.m.

Retningslinjene gjelder for alle ansatte og eksterne som er involvert i utvikling av NAVs IT‑løsninger. Følgende har et spesielt ansvar:

  • Teamleder i produktteam har ansvaret for at retningslinjene følges av interne og eksterne ressurser i teamet

  • IT Data og Innsikt har ansvaret for basisløsninger for syntetiske testdata

  • Sikkerhetsseksjonen har overordnet ansvar for bruk av testdata og informasjonssikkerhet

Retningslinjene er operative rutiner til styringssystem for både sikkerhet og personvern. Sikkerhetsseksjonen har ansvaret for vedlikehold; endringsbehov kan meldes dit.

Avgrensning (historisk):

  • NAV utviklet løsning for syntetiske testdata i 2018–2019. Syntetiske data blir gradvis tilgjengelig pr område/system. For områder der syntetiske data ikke er tilgjengelig vil sikkerhetsregler for unntak gjelde

  • Ny løsning for tilgangskontroll ved unntaksvis bruk av produksjonsdata vurderes av personvernprosjekter

2.5.2. Bruk av syntetiske testdata i NAV

Syntetiske testdata skal brukes til utvikling og forvaltning, og er tilgjengelig som:

  • Mini‑Norge (befolkningsutvalg) i syntetiske utviklings-/testmiljøer

  • Egendefinerte data fra Dolly selvbetjening (randtilfeller og spesielle testbehov). Dolly sikrer at personer og egenskaper er syntetiske

  • Syntetiske datasett for integrasjonstest med eksterne samhandlere

  • Tekniske stubber som simulerer eksterne kilder til volum- og basistesting

Syntetiske testdata er ikke personopplysninger og kan brukes uten ekstra sikkerhetstiltak.

Kvalitetskontroller for å hindre reelle data i syntetiske miljøer:

  • Navnepool med fiktive navn

  • Identpool med identer som teknisk sjekkes mot reelle identiteter i Folkeregisteret

  • Jevnlige tekniske sjekker av syntetiske miljøer (fiktive navn og identer)

  • Manuelle stikkprøver av testdata fra eksterne samhandlere

  • Miljøoppsett som hindrer krysskobling mellom syntetiske og produksjonsnære miljøer

2.5.3. Prinsipper for å lage egne testdata i Dolly

Dolly brukes for å lage egne data til randtilfeller og spesialbehov. Brukere må følge disse prinsippene:

  • Ikke ta utgangspunkt i reelle personer – alle verdier må velges uavhengig og tilfeldig

  • Ikke gjør endringer eller slett andres grupper/personer uten avtale

  • Del aldri påloggingsinformasjon

  • Kontakt oss på Slack‑kanalen #dolly for innspill, ønsker eller feil

2.5.4. Unntak fra bruk av syntetiske testdata

Unntak vurderes pr produktteam i samarbeid med behandlingsansvarlig og gjelder typisk:

  • Kritiske produksjonsfeil der produksjonsdata er nødvendig for rekonstruksjon

  • Korrigering av datakvalitet

  • Spesialtester/engangstilfeller med komplekse verdikjeder

  • Større datakonvertering

  • System/område som snart skal saneres eller moderniseres

2.5.5. Oversikt over sikkerhetstiltak

Begrensning i kopiering og bruk av produksjonsdata

  • Diskresjonskode 6 og 7 fjernes alltid ved kopi/uttrekk

  • Ansatte i NAV fjernes alltid

  • For Bisys: brukere bosatt i utlandet og dekket av paragraf 19 tas ut manuelt

  • Maskering brukes i overgangsperioder

Ansvar produktteam:

  • Teknisk støtte for å fjerne kode 6/7 og ansatte ved kopi

  • Rutiner for maskering i overgangsperiode

  • Rutiner som hindrer bruk av egne eller familiemedlemmers data

Midlertidig lagring og tilgangskontroll (ekstraordinære kopier)

  • Kopier utføres av dedikerte IT‑ressurser med logging

  • Kopier lagres på egne områder med tidsbegrenset tilgang

  • Filer lagres i filarkiv med tilgangskontroll (tidsbegrenset)

  • Ved distribusjon (e‑post, minnepinne) skal innhold krypteres og avgrenses

Ansvar produktteam:

  • Behov vurderes per sak med behandlingsansvarlig

  • Bestiller kopi via dedikerte roller

  • Har felles filarkiv med tidsbegrenset lagring (normalt maks 30 dager)

  • Teamleder gir tilgang etter behov

Tilgangskontroll og logging i skyggemiljøer

  • Fagsystemtilganger som testbrukere via IDA

  • Systemtilganger følger produksjonsrutiner

  • Logging på både fagsystem og systembrukere

Ansvar produktteam:

  • Teamleder gir føringer for bruk av tilganger

  • Teamleder har oversikt over hvem som har tilgang

  • Taushetserklæringer gjelder alle

Kontroll av data fra eksterne samhandlere

Integrasjonstester skal kun bruke syntetiske testdata. Andre tester skal bruke syntetiske stubber.

Ansvar produktteam:

  • Avtaler med eksterne samhandlere om miljø og testdata

  • Faste syntetiske datasett for integrasjonstester

  • Jevnlige stikkprøver av data fra eksterne samhandlere

2.5.6. Håndtering av hendelser og avvik

Avvik (brudd på regler for testdata eller sikkerhetstiltak) håndteres slik:

  1. Følg prosess for håndtering av hendelser

  2. Meld brudd på informasjonssikkerhet og personvern i ASYS for videre oppfølging

2.6. Åpen kildekode Dolly

Dolly er åpen kildekode og lagret i GitHub.

2.6.1. Repos

Se kildekode og relaterte prosjekter:

https://github.com/navikt/testnorge/tree/master/apps/dolly-frontend/

2.6.2. Bidra

Pull requests er velkomne. Opprett gjerne issue med forslag eller feil før PR.

2.6.3. Referanser

Brukerveiledning

Retningslinjer

3. Proxyer

3.1. Hensikt

  • Forenkle integrasjon for Dolly-relaterte applikasjoner

  • Skjule variasjon i sikkerhetsmekanismer (TokenX, Azure AD NAV, Azure AD Trygdeetaten, interne servicebrukere)

  • Forholde oss enkelt til nais accesspolicy og ha sentralisert kontroll

  • legge til cross-cutting funksjoner der det egner seg: tidsgrenser, retries, korrelasjonsid, strukturerte logger og metrikk

3.2. Arkitektur og mønster

Alle proxyer følger et felles mønster:

  • Bygget med spring boot webflux for ikke-blokkerende io operasjoner

  • Felles gradle-plugin: dolly-proxies som konfigurerer standard avhengigheter og bygg

  • Felles biblioteker: reactive-core, reactive-proxy, reactive-security, security-core for tokenutveksling og feilhåndtering

  • Konfigurasjon via config.yml (nais application + eventuelle azure-AD application ressurser)

  • Standard interne endepunkter: /internal/health/liveness, /internal/health/readiness, /internal/status

  • Token-håndtering: inngående tokenx eller azure ad token transformeres til riktig utgående token (for eksempel azure ad mot target applikasjon eller interne credentials) gjennom tjenestene i reactive-security

for eksempel pdl-proxy eksponerer seg i namespace dolly i dev-gcp, tillater et sett av interne applikasjoner og ruter videre til pdl-testdata i dev-fss med nødvendig tokenutveksling aktivert.

3.3. Sikkerhet

  • autentisering: konsument sender obo-token (tokenx eller azure ad) avhengig av kall-kontekst

  • autorisasjon: nais accesspolicy + eventuell intern validering av scopes/claims

  • hemmelige verdier: hentes via secret manager (se lokal utvikling) og mountes som envfrom secrets

  • allowallusers settes kun der det er nødvendig for azure-applikasjoner; ellers begrenses til teamets bruk

3.4. Kryss-tenant (nav.no <→ trygdeetaten.no)

flere proxyer krysser azure ad tenants (for eksempel nav (nav.no) og trygdeetaten (trygdeetaten.no)). dette løses ved at:

  • det opprettes en azureadapplication ressurs for sekundær tenant (gir secret med prefiks, f.eks. azure_trygdeetaten eller azure_nav)

  • i application-spec settes azure.application.tenant til primær tenant

  • reactive-security bibliotekene bruker konfigurerte client id/secret fra begge tenants for å gjøre OBO/bytte av token når downstream krever annen tenant enn innkommende token

  • Enkelte proxyer (f.eks. nom-proxy, kontoregister-person-proxy, dokarkiv-proxy) har AzureAdApplication for trygdeetaten.no og kjører applikasjonen i nav.no tenant; andre (f.eks. synthdata-meldekort-proxy) er motsatt

3.5. Tilgjengelige proxyer (ingress og downstream mål)

Format: tabell under genereres automatisk av script. Kolonner: Proxy (lenke til repo), Cluster (proxyens primære cluster utledet fra accessPolicy inbound), Ingress (extern/intern), Downstream apper (navn), Downstream URLer (svc/local/intern/ekstern; flere separert med ;), Cross-tenant (true/false), Status.

Proxy Cluster Ingress Downstream apper Downstream URLer Cross-tenant Status

altinn3-tilgang-proxy

dev-gcp

https://testnav-altinn3-tilgang-proxy.intern.dev.nav.no

testnav-altinn3-tilgang-service-prod

https://testnav-altinn3-tilgang-service.nav.no

false

aktiv

arbeidsplassencv-proxy

dev-gcp

https://testnav-arbeidsplassencv-proxy.intern.dev.nav.no

pam-cv-api-gcp

http://pam-cv-api-gcp.teampam.svc.cluster.local

false

aktiv

arbeidssoekerregisteret-proxy

dev-gcp

https://testnav-arbeidssoekerregisteret-proxy.intern.dev.nav.no

paw-arbeidssoekerregisteret-api-dolly

http://paw-arbeidssoekerregisteret-api-dolly.paw.svc.cluster.local

true

aktiv

brregstub-reverse-proxy

dev-fss

https://testnav-brregstub-reverse-proxy.dev-fss-pub.nais.io

brreg-stub

http://brreg-stub.dolly.svc.nais.local

true

aktiv

dolly-proxy

dev-fss

https://testnav-dolly-proxy.intern.dev.nav.no

digdir-krr-stub

-

true

aktiv

nom-proxy

dev-gcp

https://testnav-nom-proxy.intern.dev.nav.no

nom-api

http://nom-api.nom.svc.cluster.local

true

aktiv

sykemelding-proxy

dev-gcp

https://testnav-sykemelding-proxy.intern.dev.nav.no

syfosmregler, tsm-input-dolly

http://syfosmregler.teamsykmelding.svc.cluster.local, http://tsm-input-dolly.tsm.svc.cluster.local

true

aktiv

synthdata-meldekort-proxy

dev-fss

https://testnav-synthdata-meldekort-proxy.intern.dev.nav.no

synthdata-arena-meldekort

https://synthdata-arena-meldekort.intern.dev.nav.no

true

aktiv

texas-proxy

dev-gcp

https://dolly-texas-proxy.intern.dev.nav.no

samler alle andre proxyer (WIP)

-

false

aktiv

yrkesskade-proxy

dev-gcp

https://testnav-yrkesskade-proxy.intern.dev.nav.no

yrkesskade-datagenerator-service

http://yrkesskade-datagenerator-service.yrkesskade.svc.cluster.local

false

aktiv

3.6. Hvordan koble seg på

  1. Avklar behov og hvilket dataområde proxyen dekker

  2. Kontakt Dolly for tilgang og vurdering av use-case

  3. Finn ingress i proxyens config.yml under ingresses. Eksempler:

    # dev-fss (publisert via nais):
https://testnav-pdl-proxy.dev-fss-pub.nais.io

# dev-gcp intern:
https://testnav-nom-proxy.intern.dev.nav.no

  4. Kall endepunkter med gyldig TokenX/OBO-token. Velg riktig token-type basert på proxy (TokenX for sluttbrukersesjoner, Azure AD OBO for system-til-system)

  5. Hvis proxy krever kryss-tenant tilgang sørg for at applikasjonen din har riktige scopes/audience for innkommende token (NAV eller Trygdeetaten)

  6. Overvåk logger (Elastic/Loki) for korrelasjonsid og eventuelle feil

3.7. Feilsøking

  • 401/403: Sjekk at applikasjonen din er oppført i accessPolicy inbound rules og at riktig token-type/tenant brukes

  • 404: Verifiser path og at endepunktet faktisk er eksponert (noen proxyer kun pass-through på bestemte paths)

  • 5xx: Kontakt oss på slack, eller eventuelt sjekk logger for root cause fra downstream; korrelasjonsid finnes i MDC/loggfelt

3.8. Retningslinjer for endringer og nye proxyer

  • Gjenbruk eksisterende reactive-* biblioteker, ikke kopier sikkerhetskode

  • Ikke eksponer flere endepunkter enn nødvendig

  • Oppdater accessPolicy samtidig med kodeendring som introduserer nye konsumenter

  • Følg navngivingsmønster: testnav-<domene>-proxy

  • Noen proxyer går til forskjellige miljøer, disse vil da kalles med -{miljoe} på enden av ingress og ha routing basert på denne miljøvariabel (se f.eks. saf-proxy)

3.9. Kontakt

Kontakt Dolly på Slack-kanalen #dolly (https://nav-it.slack.com/archives/CA3P9NGA2) for tilgang til en eller flere av disse proxyene.

4. Lokal utvikling

Denne informasjonen er mest tiltenkt dolly-utviklere, men kan også være nyttig for andre som ønsker å se hvordan dolly fungerer under panseret når vi utvikler lokalt.

4.1. Opprette GCP-database for lokal kjøring

  1. Opprett en database i Google Cloud Console. Eksempel: testnav-min-database.

  2. Opprett en bruker i databasen (klikk på instansen, velg Users, Add user account). Ta vare på generert passord.

  3. Opprett en secret i Secret Manager (samme navn). Legg inn passordet slik at applikasjoner kan bruke ${sm://testnav-min-database}.

  4. Instansen er opprettet, men skjema mangler. Logg på instansen (database postgres) og opprett databasen: create database "testnav-min-database";

  5. Logg på databasen testnav-min-database med brukeren testnav-min-database.

Hvis du ønsker å rotere passord: generer nytt og oppdater secret.

4.1.1. Bruk av GCP-database under lokal kjøring

Noen applikasjoner bruker en GCP‑database også lokalt (Spring profile local):

  • dolly-backend

  • organisasjon-forvalter

  • pdl-forvalter

Disse refereres her som APP_NAME.

Applikasjonene bruker gcloud og cloud_sql_proxy (eller nyere Cloud SQL Auth Proxy).

4.1.1.1. Installere proxy
gcloud components install cloud-sql-proxy
4.1.1.2. Logg inn
gcloud auth login --update-adc
4.1.1.3. Start proxy
cloud-sql-proxy dolly-dev-ff83:europe-north1:testnav-APP_NAME-local -p 5432

La prosessen kjøre i eget vindu.

4.1.1.4. Kjøre applikasjon lokalt

Start applikasjonen (profile local). Passord hentes automatisk fra Secret Manager.

4.1.1.5. Hente passord manuelt
gcloud secrets versions access latest --secret=testnav-APP_NAME-local
4.1.1.6. JDBC URL

jdbc:postgresql://localhost:5432/testnav-APP_NAME-local?user=testnav-APP_NAME-local

4.2. Hvordan sette opp en lokal PSQL for egen testing

Dette er en kort beskrivelse på hvordan du setter opp PostgreSQL i Docker og fyller den med innhold hentet fra enten GCP eller FSS.

pg_dump does not block other users accessing the database (readers or writers).

4.2.1. Eksportere fra GCP

Her bruker vi dolly-backend som eksempel. Vi bruker også NAIS CLI som igjen avhenger av gcloud CLI. Eksport gjøres med pg_dump.

Først: logg inn med gcloud CLI (NAIS CLI avhenger av dette):

gcloud auth login --update-adc

Sett opp proxy mot databasen definert i applikasjonen dolly-backend. La proxy kjøre videre i eget vindu mens du eksporterer:

nais postgres proxy dolly-backend

Eksporter:

pg_dump --username=YOUR_NAV_EMAIL_ADDRESS \
  --clean --create --no-owner --no-privileges --verbose \
  --file=~/dump.sql testnav-dolly-backend

Output havner i ~/dump.sql og brukes ved import.

Flaggene --clean --create --no-owner --no-privileges gjør at skriptet kan kjøres lokalt og at tabeller får korrekt lokal eier (postgres).

4.2.2. Eksportere fra FSS

Eksempel: dolly-backend-dev. Databasen er definert i config.test.yml i applikasjonen.

pg_dump --host=dev-pg.intern.nav.no \
  --username=USERNAME_FROM_VAULT \
  --clean --create --no-owner --no-privileges --verbose \
  --exclude-table=idents_from_* --exclude-table=diff_idents --exclude-table=test \
  --file=~/dump.sql dolly-test

Brukernavn og passord hentes fra Vault (f.eks. postgresql/preprod-fss/credentials/dolly-test-admin).

--exclude-table er brukt fordi enkelte tabeller hadde annen eier og ikke kunne eksporteres med Vault‑credentials. I de fleste tilfeller kan disse parameterne utelates.

4.2.3. Sette opp PostgreSQL i Docker (engangs)

Opprett container (autentisering slått av fra Docker host – kun til lokal utvikling):

docker run --name postgres -e POSTGRES_HOST_AUTH_METHOD=trust -p 5432:5432 postgres

Kjør gjerne uten --detach første gang for å følge med på logger.

4.2.4. Importere i PostgreSQL

Import gjøres med psql. (Alternativet pg_restore krever eksport med --format=custom).

Eksisterende database blir erstattet. Du kan ha flere databaser samtidig for ulike scenario. Eksempel: testnav-dolly-backend og dolly-test.

psql --username=postgres --file=~/dump.sql

Når import er ferdig kan du inspisere databasen med ønsket klient (IntelliJ Database, psql, DBeaver, etc.).

4.3. Kjøring lokalt

Dette er felles for alle applikasjoner som er ment å kunne kjøres lokalt.

  • Bruk Spring profile local.

  • Bruk JVM option: --add-opens java.base/java.lang=ALL-UNNAMED (kan settes i IntelliJ Run Configuration VM options).

  • Swagger (hvis satt opp) er normalt tilgjengelig på http://localhost:8080/swagger .

4.3.1. Anbefalinger

  • Hold avhengigheter oppdatert – kjør dependency upgrade regelmessig.

  • Unngå å hardkode secrets – bruk Secret Manager (se egen seksjon) eller miljøvariabler.

  • Start færrest mulig eksterne tjenester lokalt; bruk stubber der det er mulig.

4.4. OpenSearch lokalt

Enkelte applikasjoner trenger OpenSearch kjørende lokalt i Docker.

4.4.1. Starte OpenSearch

docker run -p 9200:9200 -p 9600:9600 \
  -e "discovery.type=single-node" \
  -e "plugins.security.disabled=true" \
  -e "OPENSEARCH_INITIAL_ADMIN_PASSWORD=YLAgOm}rz#o6#Aq" \
  --name opensearch -d opensearchproject/opensearch:latest

Passordet må være sterkt ellers starter ikke OpenSearch.

4.5. Google Cloud Secret Manager

Noen hemmeligheter lagres i Secret Manager, som tilsvarer tidligere Vault. Disse hentes automatisk av applikasjonen ved oppstart lokalt gitt at man autentiserer seg med gcloud CLI først.

4.5.1. Sette prosjekt

For Dolly er prosjektet dolly-dev-ff83:

gcloud config set project dolly-dev-ff83

4.5.2. Innlogging

gcloud auth login --update-adc

NB: --update-adc er viktig. Se dokumentasjon om Application Default Credentials.

Alternativt via NAIS CLI:

nais login

4.5.3. Avhengighet

Legg til dependency på com.google.cloud:spring-cloud-gcp-starter-secretmanager (allerede inkludert via interne plugins hvis du bruker dem).

4.5.4. Spring konfigurasjon

Eksempel i application-local.yml:

AZURE_APP_CLIENT_ID: ${sm://azure-app-client-id}
AZURE_APP_CLIENT_SECRET: ${sm://azure-app-client-secret}

spring:
  config:
    import: "sm://"

Ingen ekstra kode kreves; verdier injiseres som vanlige properties.