Hva er Dapla-team?

For å kunne jobbe på Dapla må man være en del av et Dapla-team. Et Dapla-team er en gruppe personer som har tilgang til spesifikke ressurser på Dapla. Ressursene kan være data, kode eller tjenester. Følgelig er teamet helt sentral for tilgangsstyringen på Dapla. Derfor er det viktig at alle som jobber på Dapla gjør seg godt kjent med innholdet i denne delen.

Opprette Dapla-team

Alle Dapla-team tilhører en seksjon og opprettes av seksjonslederen i den seksjonen. Dapla-team opprettes i applikasjonen Dapla-Ctrl.

Dapla-team opprettes av dataeier for teamets kildedata. I de fleste tilfeller vil dette være en seksjonsleder i SSB. Selve opprettelsen av teamet gjøres i Manager-portalen.

Under arbeid

Dapla-Ctrl er under arbeid og foreløpig . I mellomtiden kan man bruke den gamle portalen for å opprette Dapla-team.

Autonomitetsnivå

Et team på Dapla er i en av følgende autonomitetsnivåer:

  1. Managed
  2. Semi-Managed
  3. Self-Managed

Nivået er definert i metadataene til teamet og vises i Teamvisningen i Dapla Ctrl. Det er kun plattformteamene som kan endre nivået til et team.

Formålet med å definere autonomiten til et team er å tydeliggjøre hvem som har hvilket ansvar for de produktene teamet benytter på Dapla. Nivået settes når teamet opprettes, men kan også endres senere ved behov.

Et Managed team benytter seg kun av tjenestene/features som tilbys av plattformen, og kan være sikker på at disse er satt opp i iht de krav som gjelder i SSB. Typisk vil de fleste statistikkteam være managed, og eksempler på tjenester er standard lagringsbøtter, Transfer Service, Kildomaten, osv.. Et Managed team kan kun benytte seg av tilgangsgruppene managers, data-admins og developers.

Et Semi-Managed team benytter seg av tjenestene som tilbys på plattformen, akkurat som et Managed team, men de ønsker også ta i bruk noe funksjonalitet som ikke tilbys enda. F.eks. kan det være et statistikkproduserende team som ønsker å ta i bruk en Google-tjeneste som ikke tilbys på Dapla. I disse tilfellene kan teamet velge å ta et større ansvar for denne tjenesten og få noe bredere tilganger på plattformen. Ansvaret fordrer at teamet har kompetansen til å ta dette ansvaret, og de spesifikke detaljene vil avhenge hvilken tjeneste det er snakk om, og om de ønsker å benytte tjenesten i prod- eller test-miljøet til teamet.

Et Self-Managed team vil typisk være team som består IT-utviklere med god kompetanse på skyutvikling i Google Cloud Platform. Teamet har kompetanse til å ta i bruk de tjenestene de mener er best for å løse sine oppgaver.

I resten av dette kapitlet beskrives hovedsakelig Managed teams.

Siden hvert team får definert sine ressurser i et eget IaC-repo, så er det nær sammenheng mellom Autonomitetsnivå og hvilke tilganger teamet har til å gjøre endringer i IaC-repoet. Tabell 1 viser hvilke tilganger de ulike nivåene gir.

Tabell 1: Autonomitet og tilganger i IaC-repo
Managed Semi-Managed Self-Managed
Kan lage PR på IaC-kode Ja Ja Ja
Tilgang på IaC-kode Kun yaml-“støttefiler” (team-info, iam, buckets-shared, projects) og filer de endrer (dapla-filer) Ja Ja
Kan ta i bruk funksjonalitet utover dapla-features Nei Ja Ja
IaC-filstruktur (under infra-mappen) Predefinert Predefinert + egne filer Fritt

Les mer her.

Roller i teamet

Medlemskap i et Dapla-team gir tilgang på spesifikke ressurser på Dapla. Men siden kildedataene til alle team er klassifisert som sensitive, så kan ikke alle på teamet ha lik tilgang til alle ressurser. Av den grunn er det definert 3 ulike roller på et team. To av disse, data-admins og developers, er forbeholdt de som jobber med data på teamet. Mens den tredje, managers, skal innehas av de som er ansvarlige for teamet. I de fleste tilfeller vil managers være seksjonslederen som er ansvarlige for statistikkproduktene teamet leverer. Under forklarer vi nærmere hva de ulike rollene innebærer.

Managers

Rollen managers skal bestå av en eller flere data-ansvarlige (ofte omtalt som data-eiere eller seksjonsledere). managers har ansvar for følgende i teamet:

  • opprette teamet
  • hvem i teamet som får tilgang til hvilke data og tjenester.
  • at teamet følger SSBs retningslinjer for tilgangsstyring.
  • at teamet følger SSBs retningslinjer for klassifisering av data.
  • vedlikehold og monitorering av tilganger.
  • at teamet følger og forstår hvordan sensitive data skal behandles i SSB.

Manager-rollen krever ingen tilgang til data eller databehandlende tjenester på Dapla.

Data-admins

Rollen data-admins er en priveligert rolle blant de som jobber med data i teamet. Rollen skal kun tildeles 2-3 personer på et team. data-admins har tilgang til samme data og ressurser som developers, med følgende unntak:

  • de er forhåndsgodkjent til å gi seg selv tidsbegrenset tilgang til kildedata ved behov. Tilgang til kildedata skal kun aktiveres i særskilte tilfeller, der eneste løsning er å se på data i klartekst. Tilgang til kildedata skal kun gis i en begrenset periode, og krever en skriftlig begrunnelse. managers skal lett kunne monitere hvem som aktiverer denne tilgangen og hvor ofte.
  • de kan godkjenne endringer i automatiske jobber som prosesserer kildedata til inndata.
  • de kan overføre kildedata mellom bakke og sky.

Developers

Rollen developers er den mest vanlige rollen på et Dapla-team. Denne rollen skal tildeles alle som jobber med data i teamet som ikke har data-admins-rollen. developers har tilgang til følgende ressurser:

  • alt av teamets data, med unntak av kildedata.
  • alle ressurser som behandler datatilstandene fra inndata til utdata.

Ressurser

Når du oppretter et dapla-team så får man en grunnpakke med ressurser som de fleste i SSB vil trenge for å kunne jobbe med data på Dapla. I tillegg kan teamet selvbetjent skru på andre tjenester hvis man ønsker det. I det følgende forklarer vi hva som er inkludert i grunnpakken, og hva som er tilgjengelig for å skru på ved behov.

Grunnpakken

Figur 1 viser et overordnet bilde av hvilke ressurser som er inkludert i “grunnpakken”. Et Dapla-team får et testmiljø og prodmiljø. Det er i prodmiljøet at man jobber med skarpe data, mens testmiljøet er forbeholdt arbeid med testdata. I hvert miljø får teamet to Google-prosjekter. Ett for kildedata og et for datatilstandene inndata, klargjorte data, statistikkdata og utdata. Sistnevnte prosjekt kaller vi for standardprosjektet, siden det er her mesteparten av databehandlingen skjer.

Diagram som viser hvilke miljøer, prosjekter og bøtter et team får.
Figur 1: Diagram over hvilke miljøer, Google-prosjekter og bøtter et Dapla-team som et får ved opprettelse.

Av Figur 1 ser vi at prosjektene i prodmiljøet får noen flere bøtter enn prosjektene i testmiljøet. Disse ekstrabøttene er forbeholdt synkronisering av data mellom bakke og sky, noe vi ikke legger til rette for i testmiljøet1. Les mer om overføring av data mellom bakke og sky her.

Ressursene som opprettes for et Dapla-team reflekterer i stor grad at kildedata er klassifisert som sensitive. Dette er grunnen til at det opprettes et eget prosjekt for kildedata, og at det kun er data-admins som potensielt kan få tilgang til dataene her. Opprettelsen av et eget testmiljø skyldes at Dapla-team i større grad enn før forventes å jobbe med testdata istedenfor skarpe data.

Alle ressursene som opprettes for teamet er definert i tekstfiler i et GitHub-repo. Dette repoet kaller vi for et IaC-repo (Infrastructure as Code). IaC-repoet er en del av grunnpakken, og er tilgjengelig for alle på teamet. Statistikkere trenger ikke å forholde seg til dette repoet i stor grad, med unntak av når de skal aktivere/deaktivere features og når de skal sette opp Kildomaten.

Features

I tillegg til grunnpakken med ressurser, så kan teamet selvbetjent skru på følgende features eller tjenester ved behov:

  • Transfer Service kan skrus på hvis teamet trenger å synkronisere data mellom ulike lagringssystemer. For eksempel mellom bakke og sky, eller mellom to ulike skytjenester.

  • Kildomaten kan skrus på hvis teamet trenger å automatisere overgangen fra kildedata til inndata.

Foreløpig er det kun disse to features som er tilgjengelig. Det vil komme flere etterhvert som behovene melder seg.

Les mer om features her.

GitHub-team

Ved opprettelsen av et Dapla-team så blir det også opprettet et tilsvarende GitHub-team med samme navn som Dapla-teamet. Grunnen til at det blir opprettet et GitHub-team er at GitHub er en sentral del av Dapla. Alle ressurser som skal opprettes på plattformen defineres av GitHub-repoer, og vi ønsker at tilganger her også skal reflektere tilgangene på Dapla.

For eksempel vil et team med navnet dapla-example få et GitHub-team med navnet dapla-example. Alle som er medlem av Dapla-teamet vil automatisk bli medlem av GitHub-teamet. I tillegg vil gruppetilhørighet og tilgangsroller på GitHub-teamet reflektere tilgangsroller på Dapla-teamet. For eksempel så kan dapla-example-data-admins gis tilgang til repo, og da vil alle som er medlem av Dapla-teamet med rollen data-admins få tilgang til repoet. Dette benyttes blant annet for å gi teamet tilgang til automation-mappen i sitt IaC-repo. I tillegg kan teamet bruke GitHub-teamet til å gi tilgang til andre GitHub-repoer som er relevante for teamet, for eksempel kodenbasen til en statistikkproduksjon eller lignende. Fordelen er at tilganger er gitt på teamnivå og ikke på personnivå. For eksempel hvis manager for teamet fjerner en ansatt fra developers-gruppa, så mister de all tilgang til data, tjenester og kode på GitHub som er tilgjengelig for developers.

Fotnoter

  1. Ta kontakt med produkteier for Dapla hvis du trenger å synkronisere testdata mellom bakke og sky↩︎