Zasady zabezpieczeń dla kontenerów poufnych w usłudze Azure Kubernetes Service
Zgodnie z opisem w konsorcjum Confidential Computing Consortium (CCC) "Poufne przetwarzanie to ochrona danych używanych przez wykonywanie obliczeń w środowisku zaufanym wykonywania opartym na sprzęcie (TEE). Kontenery poufne usługi AKS są przeznaczone do ochrony danych zasobników Kubernetes używanych przed nieautoryzowanym dostępem spoza tych zasobników. Każdy zasobnik jest wykonywany w poufnej maszynie wirtualnej (CVM) chronionej przez TEE AMD SEV-SNP przez szyfrowanie używanych danych i zapobieganie dostępowi do danych przez system operacyjny hosta. Inżynierowie firmy Microsoft współpracowali ze społecznościami open source confidential containers (CoCo) i Kata Containers w zakresie projektowania i implementacji kontenerów poufnych.
Omówienie zasad zabezpieczeń
Jednym z głównych składników architektury systemu Kata Containers jest agent Kata. W przypadku używania kontenerów Kata do implementowania kontenerów poufnych agent jest wykonywany wewnątrz sprzętowego modelu TEE i dlatego jest częścią zaufanej bazy obliczeniowej zasobnika (TCB). Jak pokazano na poniższym diagramie, agent Kata udostępnia zestaw interfejsów API ttrpc , które umożliwiają składnikom systemu spoza środowiska TEE tworzenie zasobników Kubernetes opartych na cvm i zarządzanie nimi. Te inne składniki (na przykład podkładka Kata) nie są częścią zestawu TCB zasobnika. W związku z tym agent musi chronić się przed potencjalnie błędami lub złośliwymi wywołaniami interfejsu API.
W kontenerach poufnych usługi AKS samoobsługa interfejsu API agenta Kata jest implementowana przy użyciu zasad zabezpieczeń (znanych również jako zasady agenta kata) określonych przez właścicieli poufnych zasobników. Dokument zasad zawiera reguły i dane odpowiadające poszczególnym zasobnikom przy użyciu standardowego języka zasad rego w branży. Wymuszanie zasad wewnątrz CVM jest implementowane przy użyciu Open Policy Agent (OPA) — ukończony projekt Cloud Native Computing Foundation (CNCF).
Zawartość zasad
Zasady zabezpieczeń opisują wszystkie wywołania interfejsów API ttrpc agenta (oraz parametry tych wywołań interfejsu API), które są oczekiwane do tworzenia zasobnika Poufne i zarządzania nim. Dokument zasad każdego zasobnika jest plikiem tekstowym korzystającym z języka Rego. W dokumencie zasad znajdują się trzy sekcje wysokiego poziomu.
Dane
Dane zasad są specyficzne dla każdego zasobnika. Zawiera on na przykład:
- Lista kontenerów powinna zostać utworzona w zasobniku.
- Lista interfejsów API zablokowanych przez zasady domyślnie (ze względów poufności).
Przykłady danych zawartych w dokumencie zasad dla każdego kontenera w zasobniku:
- Informacje o integralności obrazu.
- Polecenia wykonywane w kontenerze.
- Woluminy magazynu i instalacja.
- Kontekst zabezpieczeń wykonywania. Na przykład czy główny system plików jest tylko do odczytu?
- Czy proces może uzyskać nowe uprawnienia?
- Zmienne środowiskowe.
- Inne pola z konfiguracji środowiska uruchomieniowego kontenera Open Container Initiative (OCI).
Reguły
Reguły zasad określone w formacie Rego są wykonywane przez OPA dla każdego wywołania interfejsu API agenta Kata spoza CVM. Agent udostępnia wszystkie dane wejściowe interfejsu API do OPA, a OPA używa reguł do sprawdzania, czy dane wejściowe są zgodne z danymi zasad. Jeśli reguły zasad i dane nie zezwalają na wprowadzanie danych interfejsu API, agent odrzuca wywołanie interfejsu API, zwracając komunikat o błędzie "zablokowany przez zasady". Oto kilka przykładów reguł:
- Każda warstwa kontenera jest uwidoczniona jako urządzenie blokowe tylko do odczytu do CVM. Integralność tych urządzeń blokowych jest chroniona przy użyciu technologii dm-verity jądra systemu Linux. Oczekiwana wartość główna drzewa skrótów dm-verity jest uwzględniana w danych zasad i weryfikowana w czasie wykonywania przez reguły zasad.
- Reguły odrzucają tworzenie kontenera po wykryciu nieoczekiwanego wiersza polecenia, instalacji magazynu, kontekstu zabezpieczeń wykonywania lub zmiennej środowiskowej.
Domyślnie reguły zasad są wspólne dla wszystkich zasobników. Narzędzie genpolicy generuje dane zasad i jest specyficzne dla każdego zasobnika.
Wartości domyślne
Podczas oceniania reguł rego przy użyciu danych zasad i danych wejściowych interfejsu API jako parametrów usługa OPA próbuje znaleźć co najmniej jeden zestaw reguł, który zwraca true wartość na podstawie danych wejściowych. Jeśli reguły nie zwracają true, funkcja OPA powróci do agenta jako wartość domyślną tego interfejsu API. Przykłady wartości domyślnych z zasad:
default CreateContainerRequest := false— oznacza, że każde wywołanie interfejsu API CreateContainer jest odrzucane, chyba że zestaw reguł zasad jawnie zezwala na to wywołanie.default GuestDetailsRequest := true— oznacza, że wywołania spoza teE do interfejsu API GuestDetails są zawsze dozwolone, ponieważ dane zwracane przez ten interfejs API nie są wrażliwe na poufność obciążeń klienta.
Wysyłanie zasad do agenta Kata
Wszystkie poufne kontenery AKS CVM są uruchamiane przy użyciu ogólnych, domyślnych zasad zawartych w głównym systemie plików CVMs. W związku z tym zasady zgodne z rzeczywistym obciążeniem klienta muszą być udostępniane agentowi w czasie wykonywania. Tekst zasad jest osadzony w pliku manifestu YAML zgodnie z wcześniejszym opisem i jest dostarczany w ten sposób do agenta na wczesnym etapie inicjowania CVM. Adnotacja zasad jest przenoszona przez składniki kubelet, containerd i Kata w systemie AKS Confidential Containers. Następnie agent pracujący razem z OPA wymusza zasady dla wszystkich wywołań własnych interfejsów API.
Zasady są udostępniane przy użyciu składników, które nie są częścią TCB, więc początkowo te zasady nie są zaufane. Wiarygodność zasad należy ustanowić za pomocą zaświadczania zdalnego, zgodnie z opisem w poniższej sekcji.
Ustanawianie zaufania w dokumencie zasad
Przed utworzeniem narzędzia CVM zasobnika Kata oblicza skrót SHA256 dokumentu Zasad i dołącza tę wartość skrótu do teE. Ta akcja tworzy silne powiązanie między zawartością zasad a CVM. To pole TEE nie jest modyfikowalne później przez oprogramowanie wykonane wewnątrz CVM lub poza nim.
Po otrzymaniu zasad agent weryfikuje skrót zasad zgodny z niezmiennym polem TEE. Agent odrzuca zasady przychodzące, jeśli wykryje niezgodność skrótu.
Przed obsługą informacji poufnych obciążenia muszą wykonać kroki zaświadczania zdalnego, aby udowodnić każdej jednostki uzależnionej, że obciążenie jest wykonywane przy użyciu oczekiwanych wersji tee, systemu operacyjnego, agenta, OPA i głównego systemu plików. Zaświadczenie jest implementowane w kontenerze uruchomionym wewnątrz CVM, który uzyskuje podpisane dowody zaświadczania ze sprzętu AMD SEV-SNP. Jednym z pól z dowodów zaświadczania jest opisane wcześniej pole skrótu zasad TEE. W związku z tym usługa zaświadczania może zweryfikować integralność zasad, porównując wartość tego pola z oczekiwanym skrótem zasad zasobnika.
Egzekwowanie zasad
Agent Kata jest odpowiedzialny za wymuszanie zasad. Firma Microsoft przyczyniła się do społeczności Kata i CoCo kodu agenta odpowiedzialnego za sprawdzenie zasad dla każdego wywołania interfejsu API ttrpc agenta. Przed wykonaniem akcji odpowiadających interfejsowi API agent używa interfejsu API REST OPA, aby sprawdzić, czy reguły zasad i dane zezwalają na wywołanie lub blokują je.