Kontenery poufne (wersja zapoznawcza) z Azure Kubernetes Service (AKS)

Kontenery poufne udostępniają zestaw funkcji i możliwości w celu dalszego zabezpieczania standardowych obciążeń kontenerów w celu osiągnięcia wyższych celów dotyczących bezpieczeństwa danych, prywatności danych i integralności kodu środowiska uruchomieniowego. Azure Kubernetes Service (AKS) obejmuje funkcję kontenerów poufnych (CoCo) (wersja zapoznawcza).

Kontenery poufne wykorzystują technologię Kata Confidential Containers oraz szyfrowanie oparte na sprzęcie do szyfrowania pamięci kontenerów. Poufne kontenery w usłudze AKS używają AMD SEV-SNP i obecnie obsługują wyłącznie system Azure Linux. Ustanawia nowy poziom poufności danych, uniemożliwiając, aby dane w pamięci podczas obliczeń były w czytelnej formie. Zaufanie jest uzyskiwane w kontenerze za pośrednictwem zaświadczania sprzętowego, co umożliwia dostęp do zaszyfrowanych danych przez zaufane jednostki.

Usługa AKS obsługuje dwie funkcje oparte na technologii Kata Containers: kontenery poufne i izolację podów. Chociaż izolacja zasobnika zabezpiecza zasobnik przed działaniem we współdzielonym jądrze, nie chroni go przed atakami z uprawnieniami administratora. Kontenery poufne zapewniają dodatkową warstwę wzmacniania zabezpieczeń.

Zrzut ekranu diagramu architektury przedstawiającego kontenery poufne i piaskownicowanie zasobników w usłudze AKS.

Co sprawia, że kontener jest poufny:

  • Przezroczystość: możesz zobaczyć i sprawdzić, czy poufne środowisko kontenera z uruchomioną wrażliwą aplikacją jest bezpieczne. Microsoft udostępnia jako open source wszystkie składniki zaufanej bazy systemu komputerowego (TCB).
  • Możliwość audytu: możesz zweryfikować i sprawdzić, która wersja pakietu środowiska CoCo, w tym gościnnego systemu operacyjnego Linux i wszystkich składników, jest obecnie używana. Microsoft podpisuje system operacyjny gościa i środowisko uruchomieniowe kontenera, aby można je było zweryfikować za pomocą zaświadczania. Microsoft również publikuje bezpieczny algorytm wyznaczania wartości skrótu (SHA) kompilacji systemu operacyjnego gościa w celu zapewnienia silnej inspekcji i historii kontroli.
  • Pełna atestacja: procesor obejmuje pomiarem wszystko, co stanowi część TEE, z możliwością zdalnej weryfikacji. Raport sprzętowy procesora AMD SEV-SNP odzwierciedla warstwy kontenera oraz skrót konfiguracji środowiska uruchomieniowego kontenera w deklaracjach poświadczenia. Aplikacja może pobrać raport sprzętowy lokalnie, w tym raport, który odzwierciedla obraz systemu operacyjnego gościa i środowisko uruchomieniowe kontenera.
  • Integralność kodu: egzekwowanie w czasie wykonywania jest zawsze dostępne dzięki zasadom definiowanym przez klienta, dotyczącym kontenerów i ich konfiguracji, takim jak zasady niezmienności i podpisywanie kontenerów.
  • Izolacja od operatora: Architektury zabezpieczeń, które opierają się na zasadzie najmniejszych uprawnień i najwyższym poziomie izolacji, zapewniając ochronę przed wszystkimi niezaufanymi podmiotami, w tym administratorami klientów i dzierżawców. Obejmuje on wzmocnienie zabezpieczeń istniejącego dostępu do płaszczyzny kontroli kubernetes (kubelet) do poufnych zasobników.

Korzystając z tych możliwości z innymi środkami zabezpieczeń lub mechanizmami kontroli ochrony danych w ramach ogólnej architektury, możesz pomóc spełnić wymagania dotyczące zgodności z przepisami, branżą lub ładem w celu zabezpieczenia poufnych informacji.

Ten artykuł ułatwia zrozumienie funkcji Kontenery poufne oraz sposób implementowania i konfigurowania następujących zadań:

  • Wdróż lub uaktualnij klaster usługi AKS przy użyciu Azure CLI.
  • Dodaj adnotację do zasobnika YAML, aby oznaczyć zasobnik jako uruchamiany jako poufny kontener.
  • Dodaj zasady zabezpieczeń do zasobnika YAML.
  • Wdróż aplikację w przetwarzaniu poufnym.

Obsługiwane scenariusze

Kontenery poufne (wersja zapoznawcza) są odpowiednie dla scenariuszy wdrażania obejmujących poufne dane. Na przykład dane osobowe (PII) lub wszelkie dane z silnymi zabezpieczeniami wymaganymi do zapewnienia zgodności z przepisami. Oto niektóre typowe scenariusze z kontenerami:

  • Uruchamianie analizy danych big data przy użyciu platformy Apache Spark w celu rozpoznawania wzorców oszustw w sektorze finansowym.
  • Uruchamianie własnych modułów uruchamianych w usłudze GitHub w celu bezpiecznego podpisywania kodu w ramach praktyk DevOps ciągłej integracji i ciągłego wdrażania (CI/CD).
  • Wnioskowanie i trenowanie modeli uczenia maszynowego przy użyciu zaszyfrowanego zestawu danych z zaufanego źródła. Odszyfrowuje tylko wewnątrz poufnego środowiska kontenera, aby zachować prywatność.
  • Tworzenie czystych środowisk big data na potrzeby dopasowywania identyfikatorów w ramach obliczeń wielostronnych w branżach takich jak handel detaliczny z wykorzystaniem reklam cyfrowych.
  • Tworzenie stref docelowych zgodnych z zasadami Zero Trust dla poufnego przetwarzania, aby spełnić przepisy dotyczące prywatności podczas migracji aplikacji do chmury.

Limitations

Kwestie wymagające rozważenia

  • Czas uruchamiania zasobnika jest dłuższy w porównaniu z zasobnikami runc i izolowanymi przez jądro.
  • Obrazy kontenerów korzystające ze schematu manifestu obrazu Docker w wersji 1 (v1) nie są obsługiwane.
  • Aby używać efemerycznych kontenerów i innych metod rozwiązywania problemów, takich jak exec do kontenera, dzienniki kontenera i stdio, musisz zmodyfikować tę zasadę i wdrożyć ją ponownie, aby włączyć ExecProcessRequest, WriteStreamRequest, ReadStreamRequest i CloseStdinRequest.
  • Ponieważ zasady zabezpieczeń zawierają zakodowane pomiary warstw obrazu kontenera, nie używaj tagu latest podczas określania kontenerów.
  • Usługi, load balancery i EndpointSlices obsługują tylko protokół TCP.
  • Generator zasad obsługuje tylko zasobniki używające adresów IPv4.
  • Nie można zmieniać zmiennych środowiskowych zasobnika na podstawie obiektów ConfigMap i Secret po wdrożeniu zasobnika.
  • Zasób requests w manifestach zasobnika nie jest obsługiwany. Zamiast tego użyj zasobu limits, ponieważ containerd nie przekazuje żądań do shim Kata.
  • Dzienniki kończenia zasobników nie są obsługiwane. Chociaż zasobniki zapisują logi zakończenia do /dev/termination-log (lub do lokalizacji niestandardowej ustawionej w manifeście zasobnika), host i kubelet nie mogą odczytać tych logów, a zmiany, które zasobnik wprowadza w tym pliku, nie są widoczne na hoście.
  • Dostęp do sieci hosta nie jest obsługiwany. Nie można bezpośrednio uzyskać dostępu do konfiguracji sieci hosta z poziomu maszyny wirtualnej zasobnika.
  • Microsoft Defender dla kontenerów nie ocenia zasobników środowiska uruchomieniowego Kata.
  • Kontenery Kata mogą nie osiągać limitów wydajności IOPS, jakie osiągają tradycyjne kontenery na platformie Azure Files i na lokalnych dyskach SSD o wysokiej wydajności.

Omówienie alokacji zasobów

Ważne jest, aby zrozumieć zachowanie alokacji zasobów pamięci i procesora w tej wersji.

  • CPU: Shim przypisuje jeden vCPU do bazowego systemu operacyjnego wewnątrz poda. Jeśli nie określisz zasobu limits, obciążenia nie mają przypisanych oddzielnych udziałów procesora CPU, a procesor wirtualny jest współużytkowany z tym obciążeniem. Jeśli określisz limity użycia procesora, system przydzieli obciążeniom udziały CPU.
  • Pamięć, program obsługi Kata-CC: Program obsługi przydziela systemowi operacyjnemu pomocniczej maszyny wirtualnej (UVM) 2 GB pamięci oraz pamięć odpowiadającą zasobowi limits określonemu w manifeście YAML. Jeśli nie określisz limitu, program obsługi tworzy maszynę wirtualną o rozmiarze 2 GB bez niejawnej pamięci dla kontenerów.
  • Pamięć, moduł obsługi Kata: moduł obsługi przydziela systemowi operacyjnemu UVM 256 MB pamięci bazowej oraz pamięć odpowiadającą zasobowi limits określonemu w manifeście YAML. Jeśli nie określisz limitu, program obsługi doda niejawny limit wynoszący 1792 MB, co spowoduje, że maszyna wirtualna o rozmiarze 2 GB ma 1792 MB niejawnej pamięci dla kontenerów.

W tej wersji określanie żądań zasobów w manifestach "pod" nie jest obsługiwane. containerd nie przekazuje żądań do Kata Shim, a w związku z tym rezerwowanie zasobów na podstawie prośby o zasoby manifestu zasobnika nie jest wdrażane. Użyj zasobu limits zamiast zasobu requests , aby przydzielić pamięć lub zasoby procesora CPU dla obciążeń lub kontenerów.

Dzięki lokalnemu systemowi plików kontenera wspieranemu przez pamięć maszyny wirtualnej zapisywanie w systemie plików kontenera (w tym rejestrowanie) może wypełnić dostępną pamięć udostępnioną zasobnikowi. Ten warunek może spowodować potencjalne awarie zasobnika.

Następne kroki

  • Last updated on