OPA: En policy för allmänt ändamål för moln-native

När din organisation omfamnar molnet kan du upptäcka att dynamiken och skalan för den cloud-native stacken kräver ett mycket mer komplicerat säkerhets- och efterlevnadslandskap. Med exempelvis plattformar för containerorkestrering som Kubernetes som får dragkraft har utvecklare och devops-team nytt ansvar för policyområden som tillträdeskontroll samt mer traditionella områden som beräkning, lagring och nätverk. Under tiden kräver varje applikation, mikrotjänst eller servicenätverk en egen uppsättning behörighetspolicyer som utvecklare är på.

Det är av dessa skäl som jakten pågår för ett enklare, mer tidseffektivt sätt att skapa, genomdriva och hantera policy i molnet. Ange Open Policy Agent (OPA). Skapat för fyra år sedan som en öppen källkod, domänagnostisk policymotor, OPA blir de facto-standarden för molnintegrerad politik. I själva verket är OPA redan anställd i produktion av företag som Netflix, Pinterest och Goldman Sachs, för användningsfall som Kubernetes antagningskontroll och mikrotjänster API-auktorisering. OPA driver också många av de molninbyggda verktygen du redan känner till och älskar, inklusive Atlassian-sviten och Chef Automate.

[Också på: Där webbplatsens tillförlitlighetsteknik möter devops]

OPA tillhandahåller molnbaserade organisationer ett enhetligt policyspråk - så att beslut om auktorisering kan uttryckas på ett gemensamt sätt, över appar, API: er, infrastruktur och mer, utan att behöva hårdkoda skräddarsydd policy till vart och ett av dessa olika språk och verktyg individuellt . Dessutom, eftersom OPA är specialbyggt för auktorisering, erbjuder det en växande samling prestandaoptimeringar så att policyförfattare kan tillbringa merparten av sin tid på att skriva korrekt, underhållsbar policy och lämna prestanda till OPA.

OPA-auktoriseringspolicy har många, många användningsfall över hela stacken - från att placera skyddsräcken runt containerorkestrering, till att kontrollera SSH-åtkomst eller tillhandahålla kontextbaserad servicenätbehörighet. Det finns dock tre populära användningsfall som ger en bra startplatta för många OPA-användare: applikationsbehörighet, Kubernetes inträdeskontroll och mikrotjänster. 

OPA för ansökan om tillstånd

Auktoriseringspolicy är allestädes närvarande, eftersom praktiskt taget alla applikationer kräver det. Emellertid rullar utvecklare vanligtvis sin egen kod, vilket inte bara är tidskrävande utan resulterar i ett lapptäcke av verktyg och policyer som är svåra att underhålla. Medan auktorisering är avgörande för varje app innebär tid att skapa policy mindre tid att fokusera på användarvändande funktioner.

OPA använder ett specialbyggt deklarativt policyspråk som gör tillståndsutvecklingspolicy enkel. Du kan till exempel skapa och genomdriva policyer så enkla som "Du kan inte läsa PII om du är en entreprenör" eller "Jane kan komma åt det här kontot." Men det är bara början. Eftersom OPA är kontextmedvetet kan du också bygga en policy som tar hänsyn till vad som helst på planeten - till exempel ”Aktiehandeln efterfrågad under den sista timmen på handelsdagen, vilket kommer att resultera i över en miljon dollar transaktion, kan bara genomföras specifika tjänster i ett givet namnområde. ”

Naturligtvis har många organisationer skräddarsydda tillstånd redan på plats. Men om du hoppas att sönderdela dina applikationer och skala mikrotjänster i molnet samtidigt som du behåller effektiviteten för utvecklare, kommer det att finnas ett behov av ett distribuerat auktoriseringssystem. För många är OPA den saknade pusselbiten.

OPA för Kubernetes antagningskontroll

Många användare använder också OPA för att skapa skyddsräcken för Kubernetes. Kubernetes själv har blivit mainstream och uppdragskritiskt, och organisationer letar efter sätt att definiera och implementera säkerhetsräcken för att minska risken för säkerhet och efterlevnad. Med hjälp av OPA kan administratörer fastställa tydliga policyer så att utvecklare kan påskynda produktion av rörledningar och snabbt ta ut nya tjänster på marknaden utan att oroa sig för drifts-, säkerhets- eller efterlevnadsrisk.

OPA kan användas för att skapa policyer som avvisar intrång som använder samma värdnamn, eller som kräver att alla containeravbildningar kommer från ett pålitligt register, eller för att säkerställa att all lagring alltid är markerad med krypteringsbiten eller till internet använder ett godkänt domännamn - för att bara nämna några exempel.

Eftersom OPA integreras direkt med Kubernetes API-server kan den avvisa alla resurser som principen inte tillåter, över beräkning, nätverk, lagring och så vidare. Särskilt fördelaktigt för utvecklare kan du exponera dessa policyer tidigare i utvecklingscykeln, till exempel i CI / CD-pipelinen, så att utvecklare kan få feedback tidigt och åtgärda problem före körning. Dessutom kan du till och med validera dina policyer utanför bandet och se till att de uppnår sin avsedda effekt och inte av misstag orsakar problem.

OPA för mikrotjänster

Slutligen har OPA blivit mycket populärt för att hjälpa organisationer att kontrollera sina mikrotjänster och servicearkitekturer. Med OPA kan du skapa och genomdriva auktoriseringspolicyer direkt för en mikrotjänst (vanligtvis som en sidovagn), bygga service-till-tjänst-policyer inom servicenätet eller, från säkerhetssynpunkt, skapa policyer som begränsar sidorörelse inom servicenätet arkitektur.

Bygga enhetlig policy för molninbyggda arkitekturer

I allmänhet är det övergripande målet när du använder OPA att skapa en enhetlig strategi för att skapa policy över din cloud-native stack - så att du inte behöver ständigt hantera policy på dussintals platser, med hjälp av olika språk och metoder, genom en annons hoc-blandning av stamkunskap, wikier och PDF-filer eller en virvel av felaktiga verktyg.

[Också på: 7 bästa metoder för avlägsna agila team]

Bortsett från att förenkla utvecklingen och snabba leveranser är det också stora nyheter för säkerheten, eftersom OPA minskar antalet verktyg du behöver för att kontrollera om du till exempel misstänker att obehörig åtkomst har försökt. På samma sätt, både ur ett verksamhets- och efterlevnadsperspektiv, gör OPA det lättare att hämta och analysera information i en heterogen miljö - vilket hjälper dig att snabbt identifiera problem och lösa dem snabbare.

Utvecklare letar efter ett enklare och mer effektivt sätt att skapa och hantera policybaserade kontroller för sina molnmiljöer. För många är den lösningen OPA. Om du befinner dig vidrör auktoriseringspolicyn på flera platser, på flera språk eller i flera team kan OPA hjälpa till att eliminera redundans och snabb leverans för dig, precis som det har gjort för dem.

Tim Hinrichs är en av grundarna av Open Policy Agent-projektet och CTO för Styra. Dessförinnan grundade han OpenStack Congress-projektet och var programvaruingenjör på VMware. Tim tillbringade de senaste 18 åren med att utveckla deklarativa språk för olika domäner som molndator, programvarudefinierat nätverk, konfigurationshantering, webbsäkerhet och åtkomstkontroll. Han fick sin doktorsexamen. i datavetenskap från Stanford University 2008.

-

New Tech Forum är en plats för att utforska och diskutera framväxande företagsteknologi i oöverträffat djup och bredd. Urvalet är subjektivt, baserat på vårt val av den teknik som vi anser vara viktig och av största intresse för läsarna. accepterar inte marknadsföringssäkerhet för publicering och förbehåller sig rätten att redigera allt innehåll som har bidragit. Skicka alla förfrågningar till [email protected]