-
Notifications
You must be signed in to change notification settings - Fork 0
DORA
DORA står for DevOps Research and Assessment og er et prosjekt fra Google som bruker data fra github/jira/etc for å måle hvordan utviklerteamet gjennomfører utviklingen basert på fire forskjellige metrikker:
- Deployment Frequency: Hvor ofte er det deployments til produksjon?
- Lead Time for Changes: Hvor lang tid tar det før en commit ender opp i produksjon
- Change Failure Rate: Hvor stor prosent av deployments skaper en feil i produksjon
- Time to Restore Service: Hvor lang tid brukes det på å fikse en feil som oppstår i produksjon
Google har sluppet sin implementasjon av dette med bruk av GCP, som man kan finne her.
For å komme i gang med DORA trengs det en aktiv Quicksight subscription på kontoen som skal kjøre prosjektet. For å aktivere dette gå til Quicksight fra AWS konsollen. Velg Quicksight Enterprise og regionen eu-central-1. Man kan finne brukernavnet for Quicksight subscriptionen øverst i høyre hjørne. Dette skal brukes senere.
For at DORA skal fungere er det en del filer som må ligge i prosjektet. I mappen misc_files ligger to filer som må endres på. Fyll inn personlig informasjon under kolonene i dora_users.csv. UserName skal være det samme som det fra QuickSight, mens GropName skal være "Dataplattform". I manifest.json må <Account-id> byttes ut med din egen account-id. Disse kan uploades via et script i dora/scripts. For at dette skal fungere må datalake i infrastrukturmappen være deployet. Det er så bare å kjøre scriptet upload_dora_files.py via python3 upload_dora_files.py.
For å opprette ressurser i Quicksight må en bruker stå som principal for opprettelsene av disse elementene. Denne brukeren settes i Parameter Store på stien -> /dev/dora/quicksight_principal.
Brukernavnet må være med full ARN på følgende format: arn:aws:quicksight:eu-central-1:${AccountID}:user/default/${UserName}. UserName skal være det samme som i Quicksight.
I tillegg trengs det tre-fire parametere for hvert repo som skal legges til prosjektet, der API-nøkkelen må være SecureString. Disse er:
- URL til events fra repoet -> /dev/dora/github/repos/NAVN
- URL for å hente ut default branch name - > /dev/dora/github/defaultBranch/NAVN
- API-nøkkel -> /dev/dora/github/apikey/NAVN
- Hvis prod er i en annen branch enn default branch -> /dev/dora/github/prod/NAVN
For Dataplattform blir dette:
/dev/dora/github/apikey/dataplattform - (finnes i parameter store i knowit-dataplattform-dev, denne skal være "SecureString")
/dev/dora/github/defaultBranch/dataplattform - https://api.github.com/repos/knowit/dataplattform
/dev/dora/github/prod/dataplattform - master
/dev/dora/github/repos/dataplattform - https://api.github.com/repos/knowit/Dataplattform/events
Her er det viktig at navnet er nøyaktig likt i alle tre parameterne for samme repo. Dette fordi navnet vil hentes ut fra /dev/dora/github/repos og så brukes for å hente de andre verdiene.
NB: Dette betyr også at man skal ikke bruke stien /dev/dora/github/repos/ til noe annet enn å legge inn URL til events fra repoet som skal brukes i DORA prosjektet. Denne stien brukes for å hente ut alle github-repo navnene som skal inn i DORA.
Nå skal alt være oppe unntatt selve deploymentsene. Det er fire ting som må deployes. Dette gjøres via sls deploy. Deployments må gjøres i følgende rekkefølge:
- services/infrastructure/kms
- services/infrastructure/glue
- services/infrastructure/events
- services/infrastructure/cloudwatch
- services/infrastructure/athena
- services/infrastructure/dora-glue
- services/ingestion/DORA *
- services/infrastructure/quicksight
- services/infrastructure/cloudtrail
PS: Etter å ha deployet KMS må Quicksight få tilgang til nøkler for kunne dekryptere data. Dette gjøres ved å legge til en policy med denne tilgangen til aws-quicksight-service-role-v0 rollen. Gå inn på IAM --> velg aws-quicksight-service-role-v0 --> Add permissio --> Service: KMS, Action: decrypt, Resources: arn verdien til nøkkelen.
For at quicksight-modulen skal lages må det kjøres en del kommandoer. For å forenkle dette for øyeblikket så er det laget en konfigurasjonslambda. Dette betyr at første gang man deployer DORA, må man kjøre kommandoen sls invoke -f configuration fra dora.
Hvis alt har blitt satt opp riktig skal to datasett dukke opp i Quicksight: DeploymentsNullValues-id og DeploymentFrequency-id. Følg denne guiden for å sette opp analyser for disse datasettene.
For at quicksight skal ha alle tilganger den trenger så må den også ha tilgang til athena og s3. Dette kan dessverre ikke settes gjennom serverless per nå, men gjøres manuelt. Dette gjøres via å gå på "Manage Quicksight" under profilen sin i høyre topphjørne -> Security Permissions. Trykker så på "Manage" under "QuickSight access to AWS services". Her velger man så Athena og S3 (Her må man huke av på både datalake og kms bucket, og gi skreive + lesetillatelse)
Vi implementerer Four Keys inn i dataplattformen. Siden dette betyr at flere andre utviklerteam sin data skal inn i vår plattform er det en viktig regel for implementasjonen av løsningen. Det må skapes en sikkerhet for utviklerteamene som vi henter data fra at vi som utviklere av dataplattform ikke har tilgang til å se deres data. For å gjennomføre dette innføres level 4 sikkerhet i dataplattform.
Dette er sensitiv data som krever et ekstra nivå beskyttelse. Denne skal ikke kun beskyttes mot at personer fra utsiden ikke skal kunne lese den, men også at utviklere og andre med AWS-tilgang ikke skal ha muligheten til å lese den. Dette gjennomføres i Dataplattform med bruk av AWS Key Management Service(KMS). Her kan det skapes nøkler for å kryptere dataen server-side.
Tilgangstyring via roller i IAM er sentralt for å få dette til å fungere på en god måte. Her er det viktig å være obs på at noen roller vil overstyre rolletilgangen satt i selve nøklene. F.eks. vil en bruker med rollen "Admin" alltid ha tilgang til alt innhold som er beskyttet av KMS nøkler selv om det ikke er gitt eksplisitt tilgang til nøkkelen for denne brukeren.
For selve nøkkelen er det kun root-brukeren som er gitt eksplisitt tilgang til nøkkelen. Dette er for en ekstra sikkerhet. Det må da være klart for root at de ikke skal inn på visse mapper. Tiltak mtp. dette beskrives her.
Ellers gis ikke tilgang til nøkkelen til enkeltbrukere. Den gis kun til forskjellige AWS services, f.eks. IngestLambdaen for DORA for at disse tjenestene skal kunne kryptere og dekryptere som nødvendig. Poenget med dette oppsettet er for å minimere nødvendigheten av ekstra koding i lambdaene eller andre tjenester. Dette vil gjøre at vi på sikt kan putte inn eksisterende arkitektur i level 4 hvis nødvendig, uten å endre på annet enn serverless-konfigurasjonen.
Som nevnt tidligere så vil det til en grad være nødvendig at noen brukere har tilgang til dataen. Rett og slett for å kunne utøve resten av rollene de må utøve på AWS. Dette betyr at vi må operere med en grad av tillit til at disse brukerne ikke går inn og ser på data de ikke skal se på.
Samtidig er det viktig for kunder/brukere av DORA eller annet som skal inn i level-4 at vi har kontroll på om noen faktisk går inn og ser på dataen deres. For å kunne tilby denne graden av sikkerhet for dem så brukes CloudTrail. CloudTrail brukes for å logge og monitorere brukeraktivitet på AWS. Dette vil gi oss oversikt om noen går inn på data de ikke skal se på. (DETTE ER IKKE SATT OPP P.D.D)
DORA ligger i tre forskjellige mapper på dataplattform:
-
services/infrastructure/kms: Her ligger opprettelsen av KMS nøkkel og den krypterte bøtta. Her skal så godt som det lar seg gjøre alt som opprettes være så generisk at det kan brukes av andre prosjekter også. Både i form av at vi muligens vil ha mer i samme krypterte bøtte (her må det tas en god diskusjon på konsekvenser), eller bare for generelt gjenbruk av koden på en enkel måte. Det er også ryddigst å beholde mesteparten av avhengighetene til DORA-ingestoren i ingestor-mappen.
-
services/infrastructure/cloudtrail: Her ligger opprettelsen av cloudtrail for å følge med på tilgang i KMS bøtta. Dette er en ren DORA trail for øyeblikket, men sepereres ut i egen infrastrukturmappe fordi det vil være et naturlig samlingspunkt for fremtidige trails på tvers av bruksområder.
-
services/ingestion/DORA: Her ligger lambdaene for ingestor og processor av data som hentes inn til DORA prosjektet. I tillegg er serverless-konfigurasjonen for opprettelse av alle støttefunksjoner som trengs. Sist, men ikke minst er det en egen mappe for forskjellige queries som brukes i prosjektet. Denne mappen er mest for å ha en oversikt over disse, og brukes ikke p.d.d. direkte i noen av kodefilene.
For å ha en oversiktlig arkitektur på serverlessfilen i dora mappen er denne separert inn i flere forskjellige filer. Her kaller hovedfilen på en egen function.yml for å hente funksjoner, mens ressursene er delt inn i yaml filer basert på hva den tilhører. De forskjellige inndelingene er:
- athena.yml -> Athena workgroup, saved queries etc og tilhørende roller.
- Cloudwatch.yml -> Log group for Glue crawler
- function_roles.yml -> Roller for lambdafunksjonene
- glue.yml -> Glue crawler og tilhørende SecurityEncryptionConfiguration
- quicksight.yml -> Ressurser for quicksight setup
- sqs.yml -> Konfigurasjon av event queue
Det er flere queries som må legges inn i athena. Dette kan automatiseres, men per nå må dette manuelt legges inn i athena under workgroupen DoraWorkgroups som blir opprettet når DORA deployes. Dette for å samle alle spørringer i DORA. Spørringer som trengs for DORA kan man finne her.
For å legge til medlemmer i RLS så gjøres dette via scriptet members.py i dora/scripts.
Dette scriptet kan kjøres med tre kommandoer.
- add -> Dette legger til nye medlemmer. Det krever tre argumenter, --name, --email og --group. Her er --name brukernavn.
- remove -> Denne kommandoen sletter en medlem. Det krever kun argumentet --member, som er brukernavn for den man vil slette-
- get -> Denne kommandoen henter alle brukere i csv'en.
For mer informasjon om RLS se: https://github.com/knowit/Dataplattform-issues/wiki/DORA:-Row-level-security