Dette er et gjesteblogginnlegg skrevet sammen med Patrick Oberherr fra Contentful og Johannes Günther fra Netlight Consulting.
Dette blogginnlegget viser hvordan du kan forbedre sikkerheten i en datapipeline-arkitektur basert på Amazon Managed Workflows for Apache Airflow (Amazon MWAA) og Amazon Elastic Kubernetes Service (Amazon EKS) ved å sette opp finmaskede tillatelser ved å bruke HashiCorp Terraform for infrastruktur som kode.
Mange AWS-kunder bruker Amazon EKS for å utføre dataarbeidsmengdene sine. Fordelene med Amazon EKS inkluderer forskjellige beregnings- og lagringsalternativer avhengig av arbeidsbelastningsbehov, høyere ressursutnyttelse ved å dele underliggende infrastruktur, og et levende åpen kildekode-fellesskap som tilbyr spesialbygde utvidelser. De Data om EKS Project tilbyr en rekke maler og andre ressurser for å hjelpe kundene med å komme i gang med denne reisen. Den inneholder en beskrivelse av bruken Amazon MWAA som jobbplanlegger.
Tilfreds er AWS-kunde og AWS Partner Network (APN) partner. Bak kulissene til deres Software-as-a-Service (SaaS)-produkt, Contentful Composable Content Platform, bruker Contentful innsikt fra data for å forbedre forretningsbeslutninger og kundeopplevelse. Innholdsrikt engasjert Netlight, en APN-konsulentpartner, for å hjelpe med å sette opp en dataplattform for å samle inn denne innsikten.
De fleste av Contentfuls applikasjonsarbeidsmengder kjører på Amazon EKS, og kunnskap om denne tjenesten og Kubernetes er utbredt i organisasjonen. Det er derfor Contentfuls dataingeniørteam bestemte seg for å kjøre datapipelines på Amazon EKS også. For jobb planlegging, startet de med en selvbetjent Apache Airflow på en Amazon EKS-klynge og byttet senere til Amazon MWAA for å redusere ingeniør- og driftskostnader. Jobben gjennomføring forble på Amazon EKS.
Contentful kjører en kompleks datapipeline ved å bruke denne infrastrukturen, inkludert inntak fra flere datakilder og forskjellige transformasjonsjobber, for eksempel ved å bruke DBT. Hele rørledningen deler et enkelt Amazon MWAA-miljø og en enkelt Amazon EKS-klynge. Med et mangfoldig sett med arbeidsbelastninger i ett enkelt miljø, er det nødvendig å bruke prinsippet om minst privilegium, og sikrer at individuelle oppgaver eller komponenter bare har de spesifikke tillatelsene de trenger for å fungere.
Ved å segmentere tillatelser i henhold til roller og ansvar, klarte Contentfuls dataingeniørteam å skape et mer robust og sikkert databehandlingsmiljø, noe som er avgjørende for å opprettholde integriteten og konfidensialiteten til dataene som håndteres.
I dette blogginnlegget går vi gjennom å sette opp infrastrukturen fra bunnen av og distribuere en eksempelapplikasjon ved å bruke Terraform, Contentfuls foretrukne verktøy for infrastruktur som kode.
Forutsetninger
For å følge med på dette blogginnlegget, trenger du den nyeste versjonen av følgende verktøy installert:
Oversikt
I dette blogginnlegget skal du lage en prøveapplikasjon med følgende infrastruktur:
Eksemplet på Airflow-arbeidsflyten viser objekter i kildebøtten, lagrer denne listen midlertidig med Airflow XComs, og skriver listen som en fil til destinasjonsbøtten. Denne applikasjonen kjøres ved hjelp av Amazon EKS-pods, planlagt av et Amazon MWAA-miljø. Du distribuerer EKS-klyngen og MWAA-miljøet i en virtuell privat sky (VPC) og bruk tillatelser med minst privilegier til EKS-podene som bruker IAM -roller for tjenestekontoer. Konfigurasjonsbøtten for Amazon MWAA inneholder kjøretidskrav, samt applikasjonskoden som spesifiserer en Airflow Directed Acyclic Graph (DAG).
Initialiser prosjektet og lag bøtter
Lag en fil main.tf
med følgende innhold i en tom katalog:
Denne filen definerer Terraform AWS-leverandør samt kilde- og destinasjonsområdet, hvis navn eksporteres som AWS Systems Manager-parametere. Den forteller også Terraform å laste opp et tomt objekt med navn dummy.txt
inn i kildebøtten, noe som gjør at Airflow-eksempelapplikasjonen vi vil opprette senere, kan motta et resultat når du viser innhold i bøtte.
Initialiser Terraform-prosjektet og last ned modulavhengighetene ved å utstede følgende kommando:
Lag infrastrukturen:
Terraform ber deg om å anerkjenne endringer i miljøet og begynner deretter å distribuere ressurser i AWS. Etter vellykket distribusjon bør du se følgende suksessmelding:
Opprett VPC
Opprett en ny fil vpc.tf
i samme katalog som main.tf
og sett inn følgende:
Denne filen definerer VPC, et virtuelt nettverk, som senere vil være vert for Amazon EKS-klyngen og Amazon MWAA-miljøet. Merk at vi bruker en eksisterende terra moduler for dette, som omslutter konfigurasjon av underliggende nettverksressurser som subnett, rutetabellerog NAT-porter.
Last ned VPC-modulen:
Distribuer de nye ressursene:
Legg merke til hvilke ressurser som opprettes. Ved å bruke VPC-modulen i Terraform-filen vår, fjernes mye av den underliggende kompleksiteten når vi definerer infrastrukturen vår, men det er fortsatt nyttig å vite nøyaktig hva som blir distribuert.
Merk at Terraform nå håndterer ressurser vi definerte i begge filene, main.tf
og vpc.tf
, fordi Terraform inkluderer alle .tf
filer i gjeldende arbeidskatalog.
Lag Amazon MWAA-miljøet
Opprett en ny fil mwaa.tf
og sett inn følgende innhold:
Som før bruker vi en eksisterende modul for å spare konfigurasjonsinnsats for Amazon MWAA-miljøet. Modulen lager også konfigurasjonsbøtten, som vi bruker til å spesifisere kjøretidsavhengighet for applikasjonen (apache-airflow-cncf-kubernetes) I requirements.txt
fil. Denne pakken, i kombinasjon med den forhåndsinstallerte pakken apache-luftstrøm-amazon, muliggjør interaksjon med Amazon EKS.
Last ned MWAA-modulen:
Distribuer de nye ressursene:
Denne operasjonen tar 20–30 minutter å fullføre.
Opprett Amazon EKS-klyngen
Lag en fil eks.tf
med følgende innhold:
For å lage selve klyngen drar vi nytte av Amazon EKS Blueprints for Terraform prosjekt. Vi definerer også en administrert nodegruppe med én node som målstørrelse. Merk at i tilfeller med varierende belastning, skaler du klyngen din med Snekker i stedet for den administrerte nodegruppetilnærmingen vist ovenfor gjør klyngeskalaen mer fleksibel. Vi brukte administrerte nodegrupper først og fremst på grunn av den enkle konfigurasjonen.
Vi definerer identiteten som Amazon MWAA-utførelsesrolle antar i Kubernetes ved hjelp av map_roles
variabel. Etter å ha konfigurert Terraform Kubernetes-leverandør, gir vi Amazon MWAA-utførelsesrollen tillatelser til å administrere pods i klyngen.
Last ned EKS Blueprints for Terraform-modulen:
Distribuer de nye ressursene:
Denne operasjonen tar omtrent 12 minutter å fullføre.
Opprett IAM-roller for tjenestekontoer
Lag en fil roles.tf
med følgende innhold:
Denne filen definerer to Kubernetes-tjenestekontoer, source-bucket-reader-sa
og destination-bucket-writer-sa
, og deres tillatelser mot AWS API, ved å bruke IAM-roller for tjenestekontoer (IRSA). Igjen bruker vi en modul fra Amazon EKS Blueprints for Terraform-prosjektet for å forenkle IRSA-konfigurasjonen. Merk at begge rollene bare får minimumstillatelsene de trenger, definert ved hjelp av AWS IAM-retningslinjer.
Last ned den nye modulen:
Distribuer de nye ressursene:
Opprett DAG
Lag en fil dag.py
definere Airflow DAG:
DAG er definert til å kjøre på timeplan, med to oppgaver read_bucket
med tjenestekonto source-bucket-reader-sa
og write_bucket
med tjenestekonto destination-bucket-writer-sa
, løper etter hverandre. Begge kjøres ved hjelp av EksPodOperator, som er ansvarlig for å planlegge oppgavene på Amazon EKS, ved å bruke AWS CLI Docker-bilde å kjøre kommandoer. Den første oppgaven viser filer i kildebøtten og skriver listen til Airflow XCom. Den andre oppgaven leser listen fra XCom og lagrer den i destinasjonsbøtten. Merk at service_account_name
parameter skiller hva hver oppgave har lov til å gjøre.
Lag en fil dag.tf
for å laste opp DAG-koden til Amazon MWAA-konfigurasjonsbøtten:
Implementer endringene:
Amazon MWAA-miljøet importerer automatisk filen fra S3-bøtten.
Kjør DAG
I nettleseren din, naviger til Amazon MWAA-konsoll og velg ditt miljø. Velg øverst til høyre Åpne Airflow UI . Du bør se følgende:
For å utløse DAG, i handlinger kolonnen, velg avspillingssymbolet og velg deretter Trigger DAG. Klikk på DAG-navnet for å utforske DAG-kjøringen og dens resultater.
Naviger til Amazon S3-konsoll og velg bøtte som starter med "destinasjon". Den skal inneholde en fil list.json
nylig opprettet av write_bucket
oppgave. Last ned filen for å utforske innholdet, en JSON-liste med en enkelt oppføring.
Rydd opp
Ressursene du opprettet i denne gjennomgangen påløper AWS-kostnader. For å slette de opprettede ressursene, utfør følgende kommando:
Og godkjenne endringene i Terraform CLI-dialogen.
konklusjonen
I dette blogginnlegget lærte du hvordan du kan forbedre sikkerheten til datapipeline som kjører på Amazon MWAA og Amazon EKS ved å begrense tillatelsene til hver enkelt oppgave.
For å dykke dypere, bruk arbeidseksemplet laget i denne gjennomgangen for å utforske emnet videre: Hva skjer hvis du fjerner service_account_name
parameter fra en luftstrømoppgave? Hva skjer hvis du utveksler tjenestekontonavnene i de to oppgavene?
For enkelhets skyld brukte vi i denne gjennomgangen en flat filstruktur med Terraform- og Python-filer i en enkelt katalog. Vi holdt oss ikke til standard modulstruktur foreslått av Terraform, som generelt anbefales. I et virkelighetsprosjekt kan det å dele opp prosjektet i flere Terraform-prosjekter eller -moduler også øke fleksibiliteten, hastigheten og uavhengigheten mellom team som eier ulike deler av infrastrukturen.
Til slutt, sørg for å studere Data om EKS dokumentasjon, som gir andre verdifulle ressurser for å kjøre datapipeline på Amazon EKS, så vel som Amazon MWAA og Apache luftstrøm dokumentasjon for implementering av egne use cases. Nærmere bestemt, ta en titt på dette prøveimplementering av en Terraform-modul for Amazon MWAA og Amazon EKS, som inneholder en mer moden tilnærming til Amazon EKS-konfigurasjon og node automatisk skalering, samt nettverk.
Hvis du har spørsmål, kan du starte en ny tråd på AWS re:Post eller nå ut til AWS-støtte.
Om forfatterne
Ulrich Hinze er løsningsarkitekt hos AWS. Han samarbeider med programvareselskaper for å bygge og implementere skybaserte løsninger på AWS. Før han begynte i AWS, jobbet han for AWS-kunder og partnere innen programvareingeniør-, konsulent- og arkitekturroller i 8+ år.
Patrick Oberherr er en Staff Data Engineer hos Contentful med 4+ års arbeid med AWS og 10+ år i Data-feltet. Hos Contentful er han ansvarlig for infrastruktur og drift av datastakken som ligger på AWS.
Johannes Günther er sky- og datakonsulent hos Netlight med 5+ års arbeid med AWS. Han har hjulpet kunder på tvers av ulike bransjer med å designe bærekraftige skyplattformer og er AWS-sertifisert.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
- PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
- PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
- PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
- kilde: https://aws.amazon.com/blogs/big-data/set-up-fine-grained-permissions-for-your-data-pipeline-using-mwaa-and-eks/
- : har
- :er
- :ikke
- $OPP
- 1
- 10
- 100
- 12
- 16
- 2023
- 27
- 41
- 8
- 9
- a
- I stand
- Om oss
- ovenfor
- Ifølge
- Logg inn
- kontoer
- anerkjenne
- tvers
- handlinger
- asyklisk
- la til
- overholde
- Fordel
- fordeler
- Etter
- en gang til
- mot
- Alle
- langs
- også
- Amazon
- Amazon Web Services
- an
- og
- En annen
- noen
- Apache
- api
- Søknad
- Påfør
- tilnærming
- godkjenne
- arkitektur
- ER
- AS
- antar
- At
- autorisasjon
- Automatisk
- automatisk
- tilgjengelig
- borte
- AWS
- AWS-sertifisert
- AWS-kunde
- basert
- fordi
- før du
- bak
- Bak scenen
- være
- mellom
- Blogg
- både
- nett~~POS=TRUNC leseren~~POS=HEADCOMP
- virksomhet
- men
- by
- CAN
- saker
- Sertifisert
- endret
- Endringer
- valg
- Velg
- klikk
- klienter
- Cloud
- Cluster
- kode
- Kolonne
- kombinasjon
- samfunnet
- Selskaper
- fullføre
- komplekse
- kompleksitet
- komponenter
- Beregn
- konfidensialitet
- Konfigurasjon
- Konsoll
- konsulent
- konsulent
- inneholde
- inneholder
- innhold
- innholdsplattform
- Corner
- korrigere
- Kostnader
- skape
- opprettet
- skaper
- Gjeldende
- kunde
- kundeopplevelse
- Kunder
- DAG
- dato
- dataingeniør
- Dataplattform
- databehandling
- dato tid
- besluttet
- Beslutningstaking
- dypere
- definere
- definert
- definerer
- definere
- avhengig
- Avhengighet
- avhengig
- utplassere
- utplassert
- utplasserings
- distribusjon
- beskrivelse
- utforme
- destinasjonen
- ødelagt
- Dialog
- gJORDE
- forskjellig
- regissert
- dykk
- diverse
- do
- Docker
- dokumentasjon
- nedlasting
- tegning
- hver enkelt
- lette
- savner
- innsats
- tom
- muliggjør
- engasjert
- ingeniør
- Ingeniørarbeid
- sikrer
- entry
- Miljø
- avgjørende
- Eter (ETH)
- nøyaktig
- eksempel
- utveksling
- henrette
- henrettet
- gjennomføring
- erfaring
- utforske
- utvidelser
- falsk
- felt
- filet
- Filer
- Først
- flate
- fleksibilitet
- fleksibelt
- følge
- etter
- Til
- fra
- funksjon
- videre
- samle
- generelt
- få
- GitHub
- Gi
- graf
- Gruppe
- Gruppens
- Gjest
- Gjesteblogg
- Håndterer
- skjer
- Ha
- he
- hjelpe
- hjulpet
- høyere
- vert
- vert
- Hvordan
- Hvordan
- HTML
- HTTPS
- IAM
- Identitet
- if
- iverksette
- implementere
- importere
- import
- forbedre
- in
- inkludere
- inkluderer
- Inkludert
- Øke
- uavhengighet
- individuelt
- bransjer
- Infrastruktur
- innsiden
- innsikt
- i stedet
- integritet
- interaksjon
- Interface
- inn
- utstedelse
- utstedelse
- IT
- DET ER
- selv
- Jobb
- Jobb
- sammenføyning
- reise
- jpg
- JSON
- nøkkel
- Type
- Vet
- kunnskap
- Kubernetes
- seinere
- siste
- lært
- minst
- i likhet med
- Liste
- oppføring
- lister
- laste
- lokal
- logget
- Se
- opprettholde
- gjøre
- GJØR AT
- administrer
- fikk til
- leder
- moden
- Kan..
- melding
- metadata
- minimum
- minutter
- moduler
- Moduler
- mer
- mye
- flere
- navn
- oppkalt
- navn
- Naviger
- nødvendig
- Trenger
- behov
- nettverk
- nettverk
- Ny
- node
- note
- nå
- objekt
- gjenstander
- of
- on
- ONE
- bare
- åpen kildekode
- drift
- Drift
- operatører
- alternativer
- or
- organisasjon
- Annen
- vår
- ut
- produksjon
- egen
- pakke
- parameter
- partner
- partnernettverk
- partnere
- deler
- patch
- banen
- Patrick
- tillatelser
- rørledning
- plattform
- Plattformer
- plato
- Platon Data Intelligence
- PlatonData
- Spille
- pods
- politikk
- portrett
- Post
- primært
- privat
- prosessering
- Produkt
- Profil
- prosjekt
- prosjekter
- foreslått
- leverandør
- tilbydere
- gir
- Python
- spørsmål
- RE
- å nå
- motta
- nylig
- anbefales
- redusere
- region
- fjerne
- Krav
- ressurs
- ressursutnyttelse
- Ressurser
- ansvar
- ansvarlig
- resultere
- Resultater
- robust
- Rolle
- roller
- Regel
- Kjør
- rennende
- går
- SaaS
- samme
- Spar
- Skala
- skalering
- Scener
- planlegge
- planlagt
- planlegging
- skraper
- Sekund
- sikre
- sikkerhet
- se
- Serien
- tjeneste
- Tjenester
- sett
- innstilling
- Aksjer
- deling
- bør
- vist
- Viser
- enkelhet
- forenkle
- enkelt
- enkelt miljø
- Størrelse
- liten
- Software
- software engineering
- Solutions
- kilde
- Kilder
- spesifikk
- spesielt
- fart
- stable
- Staff
- Begynn
- startet
- Start
- starter
- Uttalelse
- Still
- lagring
- lagringsalternativer
- butikker
- struktur
- Studer
- emne
- suksess
- vellykket
- sikker
- bærekraftig
- byttet om
- symbol
- Systemer
- Ta
- tatt
- tar
- Target
- Oppgave
- oppgaver
- lag
- lag
- forteller
- maler
- terra
- tekst
- Det
- De
- Kilden
- deres
- deretter
- Disse
- de
- denne
- Gjennom
- til
- token
- verktøy
- verktøy
- topp
- Tema
- Transformation
- utløse
- sant
- to
- typen
- underliggende
- Oppdater
- upon
- bruke
- brukt
- Bruker
- Brukergrensesnitt
- bruker
- ved hjelp av
- Verdifull
- verdi
- variabel
- ulike
- versjon
- levende
- virtuelle
- gå
- walkthrough
- var
- we
- web
- webtjenester
- VI VIL
- Hva
- når
- hvilken
- hele
- hvem sin
- hvorfor
- utbredt
- vil
- med
- arbeidet
- arbeidsflyt
- arbeidsflyt
- arbeid
- år
- du
- Din
- zephyrnet