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 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.
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.
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.
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ő.
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.
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.
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.
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.