Megosztás a következőn keresztül:

Bizalmas tárolók (előzetes verzió) az Azure Kubernetes Service-lel (AKS)

  • Cikk

A bizalmas tárolók számos funkciót és képességet biztosítanak a standard tárolók számítási feladatainak további védelméhez, hogy magasabb szintű adatbiztonságot, adatvédelmet és futtatókörnyezeti kódintegritási célokat érjenek el. Az Azure Kubernetes Service (AKS) bizalmas tárolókat (előzetes verzió) tartalmaz az AKS-en.

A bizalmas tárolók a Kata Bizalmas tárolókra és a hardveralapú titkosításra épülnek a tárolómemória titkosításához. Új adattitkossági szintet hoz létre azáltal, hogy megakadályozza, hogy a számítások során a memóriában lévő adatok egyértelmű, olvasható formátumban legyenek. A megbízhatóság a tárolóban hardverigazoláson keresztül jön létre, így megbízható entitások férhetnek hozzá a titkosított adatokhoz.

A Pod-tesztkörnyezettel együtt az Azure-ban elkülönített bizalmas számítási feladatokat is futtathat az adatok és a számítási feladatok védelme érdekében. Mi teszi bizalmassá a tárolót?

  • Átláthatóság: Az a bizalmas tárolókörnyezet, ahol a bizalmas alkalmazás meg van osztva, láthatja és ellenőrizheti, hogy biztonságos-e. A Megbízható számítási alap (TCB) minden összetevőjét nyílt forráskód kell használni.
  • Ellenőrizhetőség: Ellenőrizheti és megtekintheti, hogy a CoCo-környezetcsomag melyik verziója, beleértve a Linux vendég operációs rendszert és az összes összetevőt. A Microsoft bejelentkezik a vendég operációs rendszerre és a tároló futtatókörnyezetére az igazoláson keresztüli ellenőrzés céljából. Emellett egy biztonságos kivonatoló algoritmust (SHA) is kiad a vendég operációs rendszer buildjeiből, hogy sztring-audibility és control storyt hozzon létre.
  • Teljes igazolás: A TEE részét képező adatokat a CPU-nak kell teljes mértékben mérnie, és képesnek kell lennie távolról ellenőrizni. Az AMD SEV-SNP processzor hardverjelentésének tükröznie kell a tárolórétegeket és a tároló futtatókörnyezet konfigurációjának kivonatát az igazolási jogcímeken keresztül. Az alkalmazás helyileg lekérheti a hardverjelentést, beleértve a vendég operációs rendszer rendszerképét és a tároló futtatókörnyezetét tükröző jelentést is.
  • Kódintegritás: A futtatókörnyezet kényszerítése mindig elérhető az ügyfél által meghatározott tároló- és tárolókonfigurációkon keresztül, például nem módosítható szabályzatokkal és tároló-aláírással.
  • Elszigetelés az operátortól: Olyan biztonsági kialakítások, amelyek a legkisebb jogosultságot és a legmagasabb elkülönítési védelmet feltételezik az összes nem megbízható féltől, beleértve az ügyfél-/bérlői rendszergazdákat is. Ez magában foglalja a meglévő Kubernetes-vezérlősík hozzáférésének (kubelet) a bizalmas podokhoz való korlátozását.

Az általános architektúra részeként egyéb biztonsági intézkedésekkel vagy adatvédelmi vezérlőkkel ezek a képességek segítenek megfelelni a bizalmas információk védelmére vonatkozó szabályozási, iparági vagy szabályozási megfelelőségi követelményeknek.

Ez a cikk segít megérteni a Bizalmas tárolók funkciót, valamint az alábbiak implementálását és konfigurálását:

  • AKS-fürt üzembe helyezése vagy frissítése az Azure CLI használatával
  • Megjegyzés hozzáadása a pod YAML-éhez, hogy a podot bizalmas tárolóként futtatottként jelölje meg
  • Biztonsági szabályzat hozzáadása a pod YAML-hez
  • A biztonsági szabályzat kényszerítésének engedélyezése
  • Az alkalmazás üzembe helyezése bizalmas számítástechnikában

Támogatott esetek

A bizalmas tárolók (előzetes verzió) bizalmas adatokat tartalmazó üzembe helyezési forgatókönyvekhez használhatók. Például személyazonosításra alkalmas adatok (PII) vagy a jogszabályi megfelelőséghez szükséges, erős biztonsággal rendelkező adatok. A tárolókkal kapcsolatos gyakori forgatókönyvek a következők:

  • Big Data-elemzések futtatása az Apache Spark használatával a csalási minták felismeréséhez a pénzügyi szektorban.
  • Saját üzemeltetésű GitHub-futók futtatása a kód biztonságos aláírásához a folyamatos integráció és folyamatos üzembe helyezés (CI/CD) DevOps-eljárások részeként.
  • Gépi tanulási következtetés és gépi tanulási modellek betanítása egy megbízható forrásból származó titkosított adatkészlet használatával. Csak egy bizalmas tárolókörnyezetben fejti vissza az adatvédelmet.
  • Big Data tiszta szobák létrehozása az azonosítók egyeztetéséhez több féltől származó számítás részeként az olyan iparágakban, mint a kiskereskedelem és a digitális reklám.
  • Bizalmas számítási Teljes felügyelet célzónák létrehozása az alkalmazások felhőbe történő migrálására vonatkozó adatvédelmi előírásoknak való megfelelés érdekében.

Megfontolások

A bizalmas tárolók ezen előzetes verziójával kapcsolatban az alábbiakat érdemes figyelembe venni:

  • A podindítási idő növekedése a futtató podokhoz és a kernel által izolált podokhoz képest.
  • Az 1- es verziójú tárolólemezképek nem támogatottak.
  • A titkos kódok és a konfigurációtérképek frissítései nem jelennek meg a vendégben.
  • A rövid élettartamú tárolókhoz és más hibaelhárítási módszerekhez, például exec tárolókhoz, tárolók naplókimeneteihez és (ReadStreamRequest és stdio WriteStreamRequest) szabályzatmódosítást és ismételt üzembe helyezést igényelnek.
  • A szabályzatgenerátor eszköz nem támogatja a cronjob üzembe helyezési típusait.
  • Mivel a tárolórendszerképréteg-mérések a biztonsági szabályzatban kódolva lesznek, a tárolók megadásakor nem javasoljuk a latest címke használatát.
  • A szolgáltatások, a Terheléselosztók és az EndpointSlices csak a TCP protokollt támogatják.
  • A fürtök összes podjában lévő összes tárolót konfigurálni kell a következőre imagePullPolicy: Always: .
  • A szabályzatgenerátor csak az IPv4-címeket használó podokat támogatja.
  • A konfigurációtérképek és titkos kódok értékei nem módosíthatók, ha a környezeti változó metódusát használja a pod üzembe helyezése után. A biztonsági szabályzat megakadályozza azt.
  • A podvégzítési naplók nem támogatottak. Bár a podok leállítási naplókat írnak /dev/termination-log egy egyéni helyre vagy helyre, ha a podjegyzékben meg vannak adva, a gazdagép/kubelet nem tudja olvasni ezeket a naplókat. A vendégről a fájlra vonatkozó módosítások nem jelennek meg a gazdagépen.

Erőforrás-kiosztás áttekintése

Fontos tisztában lenni a memória és a processzor erőforrás-foglalási viselkedésével ebben a kiadásban.

  • CPU: A shim egy vCPU-t rendel az alap operációs rendszerhez a podon belül. Ha nincs megadva erőforrás limits , a számítási feladatokhoz nincs külön cpu-megosztás hozzárendelve, a vCPU meg lesz osztva ezzel a számítási feladattal. Ha a cpu-korlátok meg vannak adva, a processzormegosztások explicit módon vannak lefoglalva a számítási feladatokhoz.
  • Memória: A Kata-CC kezelő 2 GB memóriát használ az UVM operációs rendszer és az X MB további memóriához, ahol X az erőforrás limits , ha a YAML-jegyzékben meg van adva (ami 2 GB virtuális gépet eredményez, ha nincs megadva korlát, a tárolók implicit memóriája nélkül). A Kata-kezelő 256 MB alapmemóriát használ az UVM OS-hez, és X MB további memóriát, ha az erőforrás limits a YAML-jegyzékben van megadva. Ha a korlátok nincsenek meghatározva, a rendszer 1792 MB implicit korlátot ad hozzá, ami 2 GB virtuális gépet és 1792 MB implicit memóriát eredményez a tárolók számára.

Ebben a kiadásban az erőforrás-kérelmek megadása a podjegyzékekben nem támogatott. A Kata-tároló figyelmen kívül hagyja a pod YAML-jegyzékből érkező erőforrás-kérelmeket, ezért a tároló nem továbbítja a kéréseket a rendszerbiztonsági rendszernek. Erőforrás helyett használjon erőforrást limit requests a számítási feladatokhoz vagy tárolókhoz tartozó memória- vagy CPU-erőforrások lefoglalásához.

A virtuálisgép-memória által támogatott helyi tároló fájlrendszerrel a tároló fájlrendszerbe való írás (beleértve a naplózást is) kitöltheti a pod számára rendelkezésre álló memóriát. Ez a feltétel lehetséges podösszeomlásokat eredményezhet.

Következő lépések