Checkov - a DevOps detektív

Bevezető

A modern felhő-infrastruktúra fejlesztésében egyre fontosabb szerepet kap a biztonság. Az Infrastructure as Code (IaC) megközelítés ugyan sok előnnyel jár, de magában hordoz biztonsági kockázatokat. A konfiguráció ellenőrzését a Checkov-val automatizálhatjuk.

Mi az a Checkov?

A Checkov egy nyílt forráskódú, Python alapú statikus kódelemző eszköz, amely segít azonosítani és megelőzni a biztonsági hibákat már a fejlesztési fázisban. Több mint 1000 előre definiált biztonsági és megfelelőségi szabályt tartalmaz. Képes elemezni Terraform (és Terragrunt) konfigurációkat, CloudFormation sablonokat, Kubernetes YAML fájlokat, Docker fájlokat és Helm chart-okat is.

Hogyan működik a Checkov?

A Checkov működése három egyszerű lépésre bontható.

1. Fájlok beolvasása és elemzése

   A Checkov statikus kódelemzést végez, ami azt jelenti, hogy beolvassa a konfigurációs fájlokat, de nem futtatja vagy telepíti őket. Az eszköz automatikusan felismeri a különböző formátumokat, mint a Terraform, Kubernetes YAML vagy Dockerfile fájlokat. Ezt követően feldolgozza a kód szerkezetét, és megérti az erőforrások közötti kapcsolatokat.

2. Biztonsági szabályok alkalmazása

   Minden erőforráshoz hozzárendeli a megfelelő biztonsági szabályokat, és ellenőrzi, hogy a konfiguráció megfelel-e a bevett gyakorlatoknak. Például egy S3 bucket esetében vizsgálja, hogy engedélyezve van-e a naplózás, be van-e kapcsolva a verziókezelés, aktív-e a titkosítás, vagy működik-e a replikáció.

3. Eredmények összesítése

   A szkennelés végén részletes jelentést készít, amely megmutatja, hogy mely beállítások feleltek meg (PASSED), melyek tartalmaztak biztonsági hiányosságot (FAILED), mely ellenőrzéseket hagytuk ki (SKIPPED), illetve mely esetek nem voltak értelmezhetők (UNKNOWN).

Hogyan kell használni?

Vegyünk példaként egy egyszerű, Terraform alapú infrastruktúrát, amelyet az AWS-ben kívánunk létrehozni:

# Terraform module mappa szerkezet
.
└── vpc
    ├── main.tf
    ├── outputs.tf
    ├── providers.tf
    └── variables.tf

A terraform plan/terraform apply parancs futtatása előtt Checkov-val meg tudjuk vizsgálni hogy milyen hibákat vétettünk és milyen bevett biztonsági gyakorlatokat szalasztottunk el. Ehhez azonban telepítenünk kell, amit megtehetünk a pip csomagkezelővel:

pip install checkov

A Checkov bemenetként képes mappát, fájlokat, illetve a terraform plan által kimenetként létrehozott .json fájlokat is fogadni (lásd alább a megjegyzéseket és parancsokat):

# Mappa konfigurálása
checkov --directory /vpc

# Fájl vagy fájlok konfigurálása
checkov -f /vpc/main.tf -f /vpc/providers.tf

Az ellenőrzés futtatását követően a következőhöz hasonló kimenet jelenik meg:

A Checkov minden erőforrást megvizsgál, és az alábbi kimenetek egyikével tér vissza:

• PASSED → megfelel a szabálynak

• FAILED → nem felel meg, javítás szükséges (pl. VPC Flow Logs hiányzik)

• SKIPPED → szándékos kihagyás --skip-check-kel vagy checkov:skip kommenttel (pl. checkov -d vpc/ --skip-check CKV_AWS_20)

Terragrunt kompatibilitás

A Code Factorynál a Terragrunt-ot használjuk az Infrastructure as Code projektjeinkben. Mivel a Checkov alapértelmezetten a .tf kiterjesztésű fájlokat ismeri fel, a Terragrunt által használt .hcl fájlokat nem mindig kezeli megfelelően. A bevett gyakorlat ezért az, hogy először a Terragrunt segítségével generálunk egy Terraform plan-t, majd ezt JSON formátumba alakítva futtatjuk rajta a Checkovot:

# JSON formátumú Terraform Plan konfigurálása
terraform init
terraform plan -out tf.plan
terraform show -json tf.plan  > tf.json 
checkov -f tf.json

Ezzel elkerülhető a .hcl fájlok közvetlen értelmezése, és egységes, támogatott bemenetet kap a Checkov. A módszer teljes mértékben kompatibilis a Terragrunt alapú projektekkel, és ugyanazokat a szabályokat alkalmazza, mint a hagyományos Terraform munkafolyamatokban.

Egyedi szabályok (Custom Policies)

A Checkov egyik legnagyobb erőssége, hogy nem csak a beépített szabályokat használhatjuk, hanem teljesen saját, testreszabott ellenőrzéseket is írhatunk. Ezeket egyedi szabályoknak (custom policies) nevezzük, és arra szolgálnak, hogy a szervezetünk belső előírásait – például tagekre, elnevezési konvenciókra vagy biztonsági beállításokra vonatkozó követelményeket – automatizáltan betartassuk.

Az egyedi szabályok YAML formátumban készíthetők el, amelyben meg kell adni a szabály azonosítóját (vagy indexét), nevét, kategóriáját, súlyosságát, majd definiálni kell a vizsgálandó erőforrás típusát, attribútumát és az elvárt értéket. A szabályok futtatása az --external-checks-dir paraméter megadásával történik, amely meghatározza azt a könyvtárat, ahol az egyedi szabályok találhatók.

Ezáltal a saját ellenőrzések ugyanúgy végrehajtásra kerülnek, mint a Checkov alapértelmezett szabályai.

1. Custom Policy Példa:

Az első egyedi szabály egy általános tag-elési előírást határoz meg: minden erőforrásnak rendelkeznie kell egy ‘project: checkov-test’ címkével. A szabály minden erőforrástípusra vonatkozik, és azt ellenőrzi, hogy a ‘tags.project’ attribútum értéke pontosan ‘checkov-test’ legyen. Ez a megközelítés biztosítja a következetes projektazonosítást az infrastruktúra teljes területén, támogatva a szervezeti szintű erőforrás-kezelést és költségkövetést.

2. Custom Policy Példa:

A második egyedi szabály kifejezetten az AWS VPC alhálózatokra vonatkozik, és az EKS (Elastic Kubernetes Service) belső load balancer működéséhez szükséges konfigurációt ellenőrzi. A szabály előírja, hogy az ‘aws_subnet’ erőforrások rendelkezzenek a ‘kubernetes.io/role/internal-elb’ címkével, amelynek értéke ‘1’.

Ez a címke kulcsfontosságú a Kubernetes környezetekben, mivel az AWS Load Balancer Controller ennek alapján azonosítja a belső load balancerekhez használható alhálózatokat. Hiányában az EKS nem tudná helyesen kiválasztani a megfelelő subneteket a belső load balancer biztosításához.

Szabály indexek (Policy Indices)

Az egyedi szabályok azonosítására a Checkov úgynevezett policy indexeket használ, amelyek a ‘metadata.id’ mezőben vannak megadva.

Ezek az egyedi azonosítók biztosítják, hogy a szabályok egyértelműen hivatkozhatók és nyomon követhetők legyenek a riportokban vagy a CI/CD folyamatokban.

A szabályazonosítók konvenciója szabadon választható, de célszerű egységes mintát alkalmazni (például prefixek használata adott szabálycsoportokhoz), hogy később is könnyen beazonosítható legyen, mely szervezeti irányelvhez tartozik egy-egy ellenőrzés.

A fentebbi példákban a ‘CKV2_TAG_1’ és ‘CKV2_TAG_2’ indexek utalnak arra, hogy tagekkel kapcsolatos ellenőrzésekről van szó, így a policy-k funkciója már azonosító alapján is jól látható.

Súlyosság (Severity)

A Checkov súlyossági szintek (severity levels) rendszere négy kategóriát különböztet meg: CRITICAL, HIGH, MEDIUM és LOW amelyek lehetővé teszik a szabályok fontosság szerinti hierarchikus rendezését. Ezek a szintek különösen fontossá válnak a soft fail és hard fail mechanizmus működésében.

A soft fail esetében a Checkov figyelmeztetéseket jelenít meg a sikertelen ellenőrzésekről, de nem szakítja meg a futást és nem ad vissza hibás kilépési kódot, így lehetővé teszi a deployment folyamat folytatását.

A hard fail viszont megszakítja a végrehajtást és nem nulla kilépési kóddal tér vissza, amely megakadályozza a további lépések végrehajtását a CI/CD pipeline-ban.

checkov -f tf.json --soft-fail-on LOW

checkov -f tf.json --hard-fail-on MEDIUM

A --soft-fail és --soft-fail-on paraméterek segítségével finoman hangolható, hogy mely súlyossági szintű hibák okozzanak soft fail viselkedést, míg a --hard-fail-on paraméterrel megadható, hogy mely szintek esetén legyen hard fail.

Ez a rugalmasság lehetővé teszi a fokozatos policy bevezetést, ahol kezdetben csak figyelmeztetések jelennek meg, később pedig szigorúbb kikényszerítés alkalmazható.

Checkov integrálása CI/CD pipeline-ba

Az előzőekben bemutatott egyedi szabályokat a gyakorlatban is beépítettük a fejlesztési folyamatba a Checkov GitHub Actions workflow-ba integrálásával. Így a Terraform/Terragrunt terveinket a pipeline automatikusan ellenőrzi a beépített és a saját szabályok alapján egyaránt.

A workflow rugalmas bemeneti paramétereket biztosít: megadható, hogy csak egy adott környezetet vizsgáljunk, minden tervet egyszerre futtassunk, vagy kizárólag egy konkrét custom policy-t (például a ‘CKV2_TAG_1’ vagy ‘CKV2_TAG_2’ szabályt) érvényesítsünk.

A folyamat során a Terraform/Terragrunt plan JSON formátumba kerül konvertálásra, majd ezen fut a Checkov elemzés. Az eredmények a GitHub Actions futás összefoglalójában egy táblázatos nézetben jelennek meg, ahol jól elkülönítve láthatók a sikertelen ellenőrzések. A Checkov minden hibához javítási útmutatót is társít egy hivatkozás formájában, amely közvetlenül elérhető a “summary”-ből. Mivel az ellenőrzések alapértelmezés szerint soft fail módban futnak, a pipeline nem áll le, ami lehetővé teszi az egyedi szabályok fokozatos és skálázható bevezetését az infrastruktúra kód teljes életciklusában.

Összegzés

A gyakorlati alkalmazás során a Checkov bizonyítottan hasznos eszköznek tekinthető az infrastruktúra biztonsági ellenőrzések területén.

A legnagyobb előnye a könnyű használat és az, hogy fokozatosan bevezethető anélkül, hogy felborítaná a meglévő munkameneteket. Az egyedi szabályok írása egyszerű, és a súlyossági szintek segítségével jól lehet priorizálni a hibákat.

Az ellenőrzés másodpercek alatt lefut és teljesen offline működik, így nem érinti a production környezetet, könnyen beépíthető CI/CD pipeline-okba is. A lényege, hogy a biztonsági problémákat még azelőtt felfedi, hogy azok a valós infrastruktúrában megjelennének.

Az eszköz korlátai közé tartozik, hogy komplex multi-cloud környezetekben megnövekedett ellenőrzési időt igényelhet, valamint bonyolult infrastruktúra kódok esetében alkalmanként hamis pozitív eredményeket produkálhat. Ugyanakkor a Checkov jól dokumentált, részletes példákkal és magyarázatokkal segíti a használatot, ami megkönnyíti a gyors és zökkenőmentes bevezetését a projektekbe. Az alkalmazás jelentős előnyöket biztosít a kód minőségének javítása és a production környezetbe kerülő biztonsági hibák számának csökkentése terén.

A Checkov használata több mint technikai döntés - ez egy szemléletváltás a “security as code” irányába. Az eszköz segít abban, hogy a biztonság ne csak utólag kerüljön elő, hanem már a fejlesztés során figyelembe vegyük. Az egyedi szabályok és a GitHub Actions integráció együtt lehetővé teszi, hogy minden szervezet a saját szabályai szerint automatizálja a biztonsági ellenőrzéseket, miközben a fejlesztési tempó nem csökken.

Az infrastruktúra kódosításának növekvő trendje mellett az ilyen eszközök használata várhatóan alapkövetelménnyé válik a modern fejlesztési csapatok számára.

Köszönjük, hogy elolvastad ezt a cikket!

Érdekel a téma? Kérdés merült fel a cikkel kapcsolatosan? Foglalj egy ingyenes konzultációt és nézzük meg, hogy a Code Factory csapata miben tud segíteni neked / nektek! A szolgáltatásaink listáját itt találod meg!

Források

• Checkov
• Terragrunt