Biztonsági szabályzat bizalmas tárolókhoz az Azure Kubernetes Service-ben

A Confidential Computing Consortium (CCC) leírása szerint "A bizalmas számítástechnika a használatban lévő adatok védelme hardveralapú, igazolt megbízható végrehajtási környezetben (TEE) végzett számítással." Az AKS bizalmas tárolók úgy vannak kialakítva, hogy megvédjék a használatban lévő Kubernetes-podok adatait a podokon kívülről történő jogosulatlan hozzáféréstől. Az egyes podokat az AMD SEV-SNP TEE által védett segédprogram virtuális gépen (UVM) hajtja végre a rendszer a használatban lévő adatok titkosításával, és megakadályozza az adatokhoz való hozzáférést a gazdagép operációs rendszere (OS) által. A Microsoft mérnökei együttműködtek a Bizalmas tárolók (CoCo) és a Kata Containers nyílt forráskódú közösségeivel a bizalmas tárolók tervezésében és megvalósításában.

A biztonsági szabályzat áttekintése

A Kata Containers rendszerarchitektúra egyik fő összetevője a Kata-ügynök. Ha a Kata-tárolókat bizalmas tárolók implementálásához használja, az ügynök a hardveralapú TEE-ben lesz végrehajtva, ezért a pod megbízható számítási bázisának (TCB) része. Az alábbi ábrán látható módon a Kata-ügynök ttrpc API-k készletét biztosítja, amelyek lehetővé teszik a TEE-n kívüli rendszerösszetevők számára a bizalmas alapú Kubernetes-podok létrehozását és kezelését. Ezek a többi összetevő (például a Kata Shim) nem részei a pod TCB-jének. Ezért az ügynöknek meg kell védenie magát a potenciálisan hibás vagy rosszindulatú API-hívásoktól.

Az AKS Bizalmas tárolókban a Kata agent API önvédelem a bizalmas podok tulajdonosai által meghatározott biztonsági szabályzattal (más néven Kata-ügynökszabályzattal) valósul meg. A szabályzatdokumentum az egyes podokhoz tartozó szabályokat és adatokat tartalmazza az iparági szabvány Rego szabályzatnyelv használatával. A szabályzat kényszerítése a segédprogram virtuális gépén (UVM) az Open Policy Agent (OPA) használatával valósul meg, amely a Cloud Native Computing Foundation (CNCF) diplomás projektje.

Szabályzat tartalma

A biztonsági szabályzat ismerteti az ügynök ttrpc API-jainak (és ezen API-hívások paramétereinek) a bizalmas pod létrehozásához és kezeléséhez várt összes hívást. Az egyes podok szabályzatdokumentuma egy szöveges fájl, amely a Rego nyelvet használja. A szabályzatdokumentumnak három magas szintű szakasza van.

Adatok

A szabályzat adatai az egyes podokra vonatkoznak. Például a következőket tartalmazza:

• A podban várhatóan létrejövő tárolók listája.
• A szabályzat által alapértelmezés szerint letiltott API-k listája (bizalmassági okokból).

Példák a podban lévő tárolókra vonatkozó szabályzatdokumentumban szereplő adatokra:

• Képintegritási információk.
• A tárolóban végrehajtott parancsok.
• Tárolókötetek és csatlakoztatások.
• Végrehajtási biztonsági környezet. Például a gyökér fájlrendszer írásvédett?
• A folyamat új jogosultságokat szerezhet?
• Környezeti változók.
• Az Open Container Initiative (OCI) tároló futtatókörnyezet konfigurációjának egyéb mezői.

Szabályok

A Rego formátumban megadott szabályzatszabályokat az OPA hajtja végre minden Kata agent API-híváshoz a segédprogram virtuális gépén (UVM) kívülről. Az ügynök minden API-bemenetet biztosít az OPA-nak, az OPA pedig a szabályok alapján ellenőrzi, hogy a bemenetek összhangban vannak-e a szabályzatadatokkal. Ha a szabályzatszabályok és az adatok nem engedélyezik az API-bemeneteket, az ügynök elutasítja az API-hívást egy "szabályzat által blokkolva" hibaüzenettel. Íme néhány példa a szabályra:

• Minden tárolóréteg írásvédett virtio blokkeszközként jelenik meg a segédprogram virtuális gép (UVM) számára. A blokkeszközök integritását a Linux kernel dm-csúcstechnológiája védi. A dm-verity kivonatfának várt gyökérértéke szerepel a szabályzatadatokban, és futásidőben ellenőrzi a szabályzatszabályok.
• A szabályok elutasítják a tároló létrehozását, ha váratlan parancssort, tároló csatlakoztatását, végrehajtási biztonsági környezetet vagy környezeti változót észlel.

Alapértelmezés szerint a szabályzatszabályok az összes podra jellemzőek. A genpolicy eszköz létrehozza a szabályzatadatokat, és az egyes podokra jellemző.

Alapértelmezett értékek

Amikor a Rego-szabályokat a szabályzatadatok és API-bemenetek paraméterként való kiértékelésekor értékeli, az OPA megpróbál megtalálni legalább egy olyan szabálykészletet, amely a bemeneti adatok alapján ad vissza egy true értéket. Ha a szabályok nem adnak vissza true, az OPA az adott API alapértelmezett értékét adja vissza az ügynöknek. Példák a házirend alapértelmezett értékeire:

• default CreateContainerRequest := false – azt jelenti, hogy a CreateContainer API-hívásokat a rendszer elutasítja, kivéve, ha a szabályzatszabályok kifejezetten engedélyezik ezt a hívást.

• default GuestDetailsRequest := true – azt jelenti, hogy a TEE-n kívülről a GuestDetails API-ba irányuló hívások mindig engedélyezettek, mert az API által visszaadott adatok nem bizalmasak az ügyfél számítási feladatainak bizalmassága szempontjából.

A szabályzat elküldése Kata-ügynöknek

Az összes AKS Bizalmas tároló segédprogram virtuális gép (UVM) egy általános, alapértelmezett szabályzattal indul el, amely a segédprogram virtuális gép (UVM) gyökér fájlrendszerében található. Ezért a tényleges ügyfélterhelésnek megfelelő szabályzatot futásidőben kell megadni az ügynöknek. A szabályzat szövege a korábban ismertetett módon van beágyazva a YAML-jegyzékfájlba, és a segédprogrambeli virtuális gép (UVM) inicializálása során már így adták meg az ügynöknek. A szabályzatjegyzet az AKS Bizalmas tárolók rendszer kubelet, containerd és Kata shim összetevőin halad át. Ezután az OPA-val együttműködő ügynök kikényszeríti a szabályzatot a saját API-kba irányuló összes híváshoz.

A szabályzat olyan összetevők használatával érhető el, amelyek nem részei a TCB-nek, ezért kezdetben ez a szabályzat nem megbízható. A szabályzat megbízhatóságát távoli igazolással kell megállapítani, az alábbi szakaszban leírtak szerint.

Megbízhatóság létrehozása a szabályzatdokumentumban

A Segédprogram virtuális gép (UVM) létrehozása előtt a Kata shim kiszámítja a szabályzatdokumentum SHA256 kivonatát, és csatolja ezt a kivonatértéket a TEE-hez. Ez a művelet erős kötést hoz létre a szabályzat tartalma és a segédprogram virtuális gépe (UVM) között. Ezt a TEE-mezőt később nem módosíthatja a segédprogram virtuális gépén (UVM) belül vagy azon kívül végrehajtott szoftver.

A szabályzat fogadása után az ügynök ellenőrzi, hogy a szabályzat kivonata megegyezik-e a nem módosítható TEE mezővel. Az ügynök elutasítja a bejövő szabályzatot, ha kivonateltérést észlel.

A bizalmas információk kezelése előtt a számítási feladatoknak távoli igazolási lépéseket kell végrehajtaniuk annak igazolásához, hogy a számítási feladat végrehajtása a TEE, az operációs rendszer, az ügynök, az OPA és a gyökér fájlrendszerverziók várt verzióival történik. Az igazolás a segédprogram virtuális gépén (UVM) futó tárolóban történik, amely aláírt igazolási bizonyítékokat szerez be az AMD SEV-SNP hardverből. Az igazolási bizonyíték egyik mezője a korábban ismertetett szabályzatkivonat TEE-mezője. Ezért az Igazolási szolgáltatás ellenőrizheti a szabályzat integritását, ha összehasonlítja ennek a mezőnek az értékét a podházirend várt kivonatával.

Szabályzatbetartatás

A szabályzat betartatásáért a Kata-ügynök felel. A Microsoft hozzájárult a Kata- és CoCo-közösséghez az ügynökkódhoz, amely az egyes ügynök ttrpc API-hívások szabályzatának ellenőrzéséért felelős. Az API-nak megfelelő műveletek végrehajtása előtt az ügynök az OPA REST API használatával ellenőrzi, hogy a szabályzatszabályok és az adatok engedélyezik-e vagy letiltják-e a hívást.

Következő lépések

Bizalmas tároló üzembe helyezése az AKS-ben