Programmering

OPA: En politik til generel anvendelse til cloud-native

Da din organisation omfavner skyen, kan du opleve, at dynamikken og omfanget af den cloud-native stack kræver et langt mere kompliceret sikkerheds- og compliance-landskab. For eksempel med containerorkestrationsplatforme som Kubernetes, der får trækkraft, har udviklere og devops-hold nyt ansvar over politikområder som adgangskontrol samt mere traditionelle områder som beregning, opbevaring og netværk. I mellemtiden kræver hver applikation, mikroservice eller servicenetværk sit eget sæt autorisationspolitikker, som udviklere er på krogen for.

Det er af disse grunde, at jagten på en enklere, mere tidseffektiv måde at skabe, håndhæve og administrere politik i skyen på. Indtast Open Policy Agent (OPA). OPA blev oprettet for fire år siden som en open source-domæne-agnostisk politikmotor og bliver de facto-standarden for cloud-native politik. Faktisk er OPA allerede ansat i produktion af virksomheder som Netflix, Pinterest og Goldman Sachs til brugssager som adgangskontrol til Kubernetes og API-godkendelse til mikroservices. OPA driver også mange af de cloud-native værktøjer, du allerede kender og elsker, inklusive Atlassian-pakken og Chef Automate.

[Også på: Hvor pålidelighed på stedet møder devops]

OPA giver cloud-native organisationer et samlet politiksprog - så godkendelsesbeslutninger kan udtrykkes på en fælles måde på tværs af apps, API'er, infrastruktur og mere uden at skulle hardcode skræddersyet politik til hvert af disse forskellige sprog og værktøjer individuelt . Derudover, fordi OPA er specialbygget til godkendelse, tilbyder det en voksende samling af ydeevneoptimeringer, så politikforfattere kan bruge det meste af deres tid på at skrive en korrekt, vedligeholdelig politik og overlade performance til OPA.

OPA-godkendelsespolitik har mange, mange brugssager på tværs af stakken - fra at placere beskyttelseslister omkring containerorkestrering, til at kontrollere SSH-adgang eller give kontekstbaseret servicemesh-autorisation. Der er dog tre populære brugssager, der giver en god startpude til mange OPA-brugere: applikationsgodkendelse, Kubernetes adgangskontrol og mikrotjenester.

OPA til ansøgningstilladelse

Autorisationspolitik er allestedsnærværende, fordi stort set alle applikationer kræver det. Imidlertid “udvikler udviklere typisk deres egen” kode, hvilket ikke kun er tidskrævende, men resulterer i et patchwork quilt af værktøjer og politikker, der er vanskelige at vedligeholde. Mens autorisation er afgørende for hver app, betyder det, at tid brugt til at skabe politik betyder mindre tid til at fokusere på brugernes funktioner.

OPA bruger et specialbygget deklarativt politiksprog, der gør udviklingen af ​​autorisationspolitik enkel. For eksempel kan du oprette og håndhæve politikker så lige som "Du kan ikke læse PII, hvis du er en entreprenør" eller "Jane kan få adgang til denne konto." Men det er bare starten. Fordi OPA er kontekstbevidst, kan du også opbygge en politik, der tager højde for alt på planeten - som f.eks. "Aktiehandler, der er anmodet om i den sidste time på handelsdagen, hvilket vil resultere i en transaktion på over en million dollars, kan kun udføres den specifikke tjenester i et givet navneområde. ”

Selvfølgelig har mange organisationer allerede skræddersyet tilladelse. Men hvis du håber at nedbryde dine applikationer og skalere mikrotjenester i skyen og samtidig bevare effektiviteten for udviklere, vil der være behov for et distribueret autorisationssystem. For mange er OPA det manglende puslespil.

OPA for Kubernetes adgangskontrol

Mange brugere bruger også OPA til at oprette gelænder til Kubernetes. Kubernetes selv er blevet mainstream og missionskritisk, og organisationer søger måder til at definere og implementere sikkerhedsvælger for at mindske sikkerheds- og overholdelsesrisiko. Ved hjælp af OPA kan administratorer indstille klare politikker, så udviklere kan fremskynde produktion af rørledninger og hurtigt bringe nye tjenester på markedet uden at bekymre sig om drifts-, sikkerheds- eller overholdelsesrisiko.

OPA kan bruges til at oprette politikker, der afviser enhver indtrængning, der bruger det samme værtsnavn, eller som kræver, at alle containerbilleder kommer fra en betroet registreringsdatabase, eller for at sikre, at al lagerplads altid er markeret med krypteringsbitten, eller at hver app udsættes til internettet skal du bruge et godkendt domænenavn - for blot at nævne et par eksempler.

Da OPA integreres direkte med Kubernetes API-server, kan den afvise enhver ressource, som politikken ikke tillader, på tværs af beregning, netværk, opbevaring osv. Særligt fordelagtigt for udviklere, kan du udsætte disse politikker tidligere i udviklingscyklussen, såsom i CI / CD-pipelinen, så udviklere kan få feedback tidligt og afhjælpe problemer inden runtime. Desuden kan du endda validere dine politikker uden for båndet og sikre, at de opnår deres tilsigtede effekt og ikke utilsigtet skaber problemer.

OPA til mikrotjenester

Endelig er OPA blevet meget populært for at hjælpe organisationer med at kontrollere deres mikrotjenester og servicearkitekturer. Med OPA kan du oprette og håndhæve autorisationspolitikker direkte for en mikroservice (typisk som et sidevogn), opbygge service-til-service-politikker inden for servicenettet eller fra et sikkerhedsmæssigt synspunkt oprette politikker, der begrænser lateral bevægelse inden for servicenettet arkitektur.

Bygning af en samlet politik for cloud-native arkitekturer

Generelt er det overordnede mål, når du bruger OPA, at skabe en samlet tilgang til at skabe politik på tværs af din cloud-native stak - så du ikke behøver løbende at styre politik på snesevis af placeringer ved hjælp af forskellige sprog og tilgange gennem en annonce hoc-blanding af stammeviden, wikier og PDF-filer eller et virvar af uoverensstemmende værktøjer.

[Også på: 7 bedste fremgangsmåder for fjerntliggende agile teams]

Bortset fra at forenkle udvikling og hurtigere levering er dette også en stor nyhed for sikkerheden, da OPA reducerer antallet af værktøjer, du har brug for for at kontrollere, om du f.eks. Har mistanke om, at der blev forsøgt uautoriseret adgang. Tilsvarende gør OPA fra både en operation og et overholdelsesperspektiv lettere at trække og analysere information i et heterogent miljø - hvilket hjælper dig med hurtigt at identificere problemer og løse dem hurtigere.

Udviklere er på jagt efter en enklere og mere effektiv måde at oprette og administrere politikbaserede kontroller til deres cloud-native miljøer. For mange er denne løsning OPA. Hvis du finder dig selv i at berøre autorisationspolitik flere steder, på flere sprog eller på tværs af flere hold, kan OPA hjælpe med at eliminere redundans og hurtig levering til dig, ligesom det har gjort for dem.

Tim Hinrichs er medstifter af Open Policy Agent-projektet og CTO for Styra. Før det var han medstifter af OpenStack Congress-projektet og var softwareingeniør hos VMware. Tim tilbragte de sidste 18 år med at udvikle deklarative sprog til forskellige domæner såsom cloud computing, softwaredefineret netværk, konfigurationsstyring, websikkerhed og adgangskontrol. Han fik sin ph.d. i datalogi fra Stanford University i 2008.

New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle forespørgsler til [email protected].

$config[zx-auto] not found$config[zx-overlay] not found