Pad alá esik-e két szék között a Cloud Custodian?

Bevezető

A felhő üzemeltetés nemcsak arról szól, hogy az alkalmazásaink futnak. Rengeteg szempontot kell figyelembe vennünk, legyen szó költségoptimalizálásról, biztonsági szabályokról vagy szabványok követéséről. Vajon mindenre az AWS natív szolgáltatásai nyújtják a legjobb választ? Mi van, ha egy nyílt forráskódú szoftver hatékonyabb, mint amit a platform alapból kínál? Ebben a cikkben a Cloud Custodian-t vizsgáljuk meg és megnézzük, hogy hol a helye a Policy-as-Code eszközök között.

Probléma

Egy felhőarchitektúrát jól üzemeltetni sokrétű feladat. Nem elég, hogy az alkalmazásaink megbízhatóan működnek, figyelembe kell vennünk a biztonsági szempontokat, különböző nemzetközi szabványokat, mint a GDPR, vagy a HIPAA, és természetesen a költségek is számítanak.

Még egy olyan alapvető komponensnél is, mint az EC2, rengeteg mindenre kell figyelni. A feladat nem ér véget a sikeres indítással. A megfelelő instance típus kiválasztása, a tagelés és az EBS-ek titkosítása csak a belépő szint. Az igazi kihívást az üzemeltetés folytonossága jelenti. Hiába konfigurálunk ugyanis mindent tökéletesen a telepítéskor, fel kell készülnünk azokra a nem várt módosításokra vagy rendszerszintű hibákra is, amelyek az indítás után boríthatják fel a rendszert.

Amikor rendszereket tervezünk az AWS felhőben, általában szeretjük a platform saját szolgáltatásait használni, mert nagyon megbízhatóak és szorosan integrálva vannak az AWS rendszerébe. A Well Architected Framework ajánlásai szerint SCP-ket (Service Control Policy) és Config-ot használunk szabályok felállítására, Security Hub-ot a talált sérülékenységek összegyűjtésére, CloudWatch-al gyűjtjük a logokat és metrikákat és állítunk be Alarm-okat. Az egész egy jól megtervezett rendszer, amiben rengeteg segítséget, például előre összeállított szabálycsomagokat és példákat is kapunk a platform részéről. Ugyanakkor ezek a szolgáltatások néha elég költségesek tudnak lenni, főleg ha egy fiókokon és régiókon átívelő nagy organizációról van szó.

Itt jön a képbe a Cloud Custodian, ami két fronton is levett minket a lábunkról, a személyre szabhatóság és a központosított kezelés terén. Míg az AWS-nél gyakran öt-hat különböző konzol között kell zsonglőrködnünk a szabályok érvényesítéséhez, a Custodian lehetővé teszi, hogy egyetlen, egységes keretrendszerben (Policy-as-Code) kezeljük az összes szabályunkat. Ez a fajta rugalmasság és átláthatóság az, ami miatt egy ponton túl már nemcsak költséghatékonyabb, hanem kényelmesebb döntés is lehet az open source irányba indulni.

Egy lehetséges megoldás

A Cloud Custodian egy nyílt forráskódú Policy-as-Code (PaC) megoldás, amely lehetővé teszi a felhőalapú erőforrások egységes és automatizált felügyeletét. A rendszer YAML-alapú szabályokon keresztül határozza meg a biztonsági, megfelelőségi és költséghatékonysági elvárásokat. Azokra az erőforrásokra, amik nem felelnek meg a szabályoknak, “action”-öket állíthatunk be.

• Standard action: Használhatunk kész megoldásokat, például egy szabálytalan EC2 azonnali leállítását, egy nem titkosított S3 bucket törlését vagy automatikus „Owner” tagek elhelyezését.
• Egyedi automatizációk: Ha a beépített eszköztár nem elég, a rendszer szinte korlátlanul bővíthető. Mivel a Custodian képes AWS Lambda függvényeket vagy Step Function folyamatokat indítani, bármilyen egyedi üzleti logikát ráépíthetünk. Küldhetünk üzenetet egy külső rendszernek vagy akár elindíthatunk egy többlépéses automatikus hibajavítási folyamatot.

A szabályok így épülnek fel:

policies:
  - name: szabály-neve          
    resource: aws.ec2                 
    description: "Rövid leírás"       
    filters:                          
      - type: value
        key: InstanceType
        op: not-in
        value: [t2.micro, t3.micro]
    actions:                          
      - type: tag
        key: NonCompliant
        value: "true"

Nagy előnye az eszköznek, hogy azon felül, hogy natív módon együttműködik az AWS, Azure és GCP szolgáltatásaival, olyan népszerű eszközökkel is integrálva van, mint mondjuk a Slack vagy a Jira.

Összehasonlítás más eszközökkel

Biztonsági szabályok

Még ha az alapoktól kezdve biztonságosan is építettük ki a rendszerünket, elengedhetetlen az erőforrások folyamatos monitorozása a későbbi módosítások miatt. Az AWS natív megoldása erre elsősorban a CloudWatch Alarm, amely kiválóan teljesít, ha egyszerű, metrika-alapú figyelmeztetéseket akarunk beállítani, például ha szeretnénk figyelmeztetést kapni egy gép túl magas CPU-használata esetén.

Vannak azonban olyan kritikus esetek, ahol a CloudWatch önmagában már nem elegendő, mert nem egy küszöbértéket, hanem az erőforrások konfigurációjának változásait kell vizsgálnunk. A CloudWatch például nehezen birkózik meg az olyan összetett szűrésekkel, mint például egy publikus S3 bucket azonosítása, amiről hiányzik a “Security Approved” tag.

A legnagyobb különbség mégis a beavatkozás képességében rejlik. Míg a CloudWatch Alarm csak jelez, a Cloud Custodian-ba be vannak építve az automatizált válaszlépések. A hiba javítására tett lépések részét képezik a szabálynak, nem utólag kapcsoljuk rá őket.

Költséghatékonság

A Cloud Custodian nem elsősorban Finops megoldás. Szemben mondjuk az Infracost vagy a Terracost eszközökkel, nem becsüli meg a havi költésünket, nem figyelmeztet, ha költségemelkedés várható az IaC kódunk módosításai alapján, és főleg nem rajzol szép diagrammokat. Nem preventív, hanem reaktív eszköz.

Arra viszont kitűnően alkalmas, hogy szabályokat fektessünk le arra vonatkozóan, hogy az AWS-szolgáltatások, amiket használunk, költséghatékonyan működjenek. Ezeket a szabályokat nekünk kell átgondolnunk és megfogalmaznunk, viszont cserébe nagy rugalmasságot kapunk azzal kapcsolatban, hogy milyen változásra pontosan hogyan szeretnénk reagálni.

Képzeljünk el például egy tesztkörnyezetet, ahol a kollégák saját maguknak indíthatnak gépeket. Fontos, hogy ne szaladjanak el a költségek a túl nagy gépméretek miatt. Megtehetnénk, hogy egy SCP-kkel (Service Control Policy) egyszerűen letiltjuk a drága géptípusokat, de ez néha akadályozhatja a munkát. Ha nem gátolni akarjuk a folyamatokat, csak látni szeretnénk, ha valaki túllépi a kereteket, érdemes a tiltás helyett automatikus riasztást beállítani Cloud Custodiannal.

Szabványosítás

Amikor először találkoztam a Cloud Custodiannal, egyből az AWS Config-gal vetettem össze. Bár mindkét eszköz hasonló célt szolgál, jelentős különbség van a költségszerkezetükben és a rugalmasságukban. A Cloud Custodian esetében a szabályokat nekünk kell definiálnunk, cserébe viszont nagyságrendekkel költséghatékonyabb, különösen nagyvállalati környezetben, ahol az AWS Config kiértékelés-alapú díjazása miatt a költségek gyorsan elszállhatnak.

Mivel a Cloud Custodian natív módon képes a talált eredményeket közvetlenül az AWS Security Hub-ba küldeni. Megmarad a biztonsági csapatok számára az úgynevezett „single pane of glass” (egységes felületi) szemlélet. Az észlelt szabályszegések, akár más AWS biztonsági szolgáltatások jelentéseivel együtt, továbbra is egy helyen jelennek meg.

Mit próbáltunk ki?

A teszt során nem akartunk egy folyamatosan futó szerverrel foglalkozni, ezért a Cloud Custodiant egy rendszeresen lefutó GitHub Workflow-ba integráltuk. Az eszköz amúgy ebből a szempontból elég rugalmas, lehetett volna ez egy dedikált szerveren, AWS Lambda függvényként vagy akár egy EKS-en is.

A működés szemléltetéséhez létrehoztunk két EC2-t és felállítottunk egy egyszerű szabályt: minden gépnek rendelkeznie kell bizonyos kötelező címkékkel (tagekkel). Azt a folyamatot akartuk automatizálni, hogy ha egy gép nem felel meg az előírásoknak, akkor:

1. Kapjon egy automatikus figyelmeztető tag-et.
2. Küldjön nekünk egy email értesítést a szabályszegésről.

policies:
 - name: ec2-missing-tag
   resource: aws.ec2
   filters:
     # Only check instances with Name tag starting with finops-demo-
     - type: value
       key: "tag:Name"
       value: "^finops-demo-"
       op: regex


     # Check if any of the tags are missing
     - or:
       - "tag:Project": absent
       - "tag:Environment": absent
       - "tag:AccountType": absent
       - "tag:Owner": absent
       - "tag:CreatedBy": absent
       - "tag:Version": absent


   actions:
     # Add NonCompliant tag
     - type: tag
       key: NonCompliant
       value: "true"


     # Invoke messaging lambda function
     - type: invoke-lambda
       function: finops-demo-compliance-alert
       async: true

Az értesítés rész tartogatott némi kihívást. A Cloud Custodian natív notify action-je ugyanis alapértelmezés szerint a saját kiegészítő eszközét, a c7n_mailer-t használja. Ez egy jól felépített megoldás, ami SQS queue-ba gyűjti az üzeneteket, majd onnan formázva küldi ki őket a címzetteknek, azonban mi nem szerettünk volna még egy külön komponenst folyamatosan üzemeltetni. Ehelyett egy egyszerűbb utat választottunk, az értesítéseket egy Lambda függvényen keresztül közvetlenül egy SNS topic-ra küldtük fel, így minimalizáltuk az infrastruktúra-igényt, miközben elértük a kívánt riasztási funkciót.

A végére így nézett ki egy workflow futás:

És ilyen lett egy email értesítés:

Vélemény

A Cloud Custodian legnagyobb előnye egyben a legnagyobb hátránya is: a teljes személyre szabhatóság. Ez az eszköz azoknak a csapatoknak ideális, akik hajlandóak energiát fektetni a szabályrendszerek és akciók pontos kidolgozásába, és akik alaposan végig akarják gondolni, pontosan milyen állapotot szeretnék látni az AWS fiókjaikban.

Bár a szabályok megírása egy olyan befektetés, amiért cserébe egy rendkívül költséghatékony és rugalmas rendszert kapunk. Fontos megjegyezni, hogy bár az eszköz multi-cloud képességekkel bír, mi a tesztjeink során kizárólag AWS környezetben vizsgáltuk a működését.

Kérdésed van? Írj nekünk és mi segítünk megtalálni a számodra ideális megoldást.