Private Kubernetes Deployment for Autonomous Reliability Infrastructure
Run Zof execution-compatible agents in customer-managed Kubernetes clusters. Control plane and execution plane stay separable; Zof does not claim to install a full Kubernetes platform for you.
Klastry zarządzane przez klienta
Rozdzielenie płaszczyzny sterowania i wykonawczej
Wzorce izolacji przestrzeni nazw
Zgodność z modelami hybrydowymi i enklawowymi
Dlaczego przedsiębiorstwa wymagają prywatnej orkiestracji
Wiele zespołów już standaryzuje platformy wewnętrzne na Kubernetesie. Zof wspiera umieszczanie wykonania w tych klastrach, nie wymagając rezygnacji z dotychczasowych inwestycji w orkiestrację.
- -Istniejące standardy klastrów i potoki GitOps
- -Odpowiedzialność zespołu platformowego za węzły i sieć
- -Potrzeba trzymania wrażliwych obciążeń poza wielodostępnym wykonaniem SaaS
- -Środowiska regulowane z izolacją na poziomie przestrzeni nazw
Uruchamianie infrastruktury wykonawczej w klastrach zarządzanych przez klienta
Agenci wykonawczy mogą być wdrażani jako obciążenia w klastrach, którymi zarządzasz. Planowanie i zatwierdzenia mogą działać w płaszczyznach sterowania w chmurze, chmurze prywatnej lub on-premises w zależności od polityki.
- -Agenci szeregowani jak inne usługi wewnętrzne
- -Zgodność z CNI klienta oraz silnikami polityk
- -Brak wymogu dostępu przychodzącego do klastra
- -Wsparcie dla flot wieloklastrowych w czasie
Rozdzielenie płaszczyzny sterowania i płaszczyzny wykonawczej
Płaszczyzna sterowania przechowuje polityki, kontekst grafu, zatwierdzenia i harmonogramowanie. Płaszczyzna wykonawcza uruchamia podpisane kapsuły wobec aplikacji w klastrze lub w połączonych sieciach.
Wykonywanie w prywatnym Kubernetes
Agenty zgodne z wykonywaniem w klastrach zarządzanych przez klienta, bez pełnej instalacji platformy.
- -Wyraźna granica przeglądu bezpieczeństwa
- -Wrażliwe dane środowiska uruchomieniowego pozostają w przestrzeniach nazw wykonawczych
- -API płaszczyzny sterowania nie uruchamiają testów bezpośrednio wobec chronionych aplikacji
- -Podziały hybrydowe są częste we wdrożeniach korporacyjnych
Agenci wykonawczy Kubernetes
Agenci są projektowani z myślą o zgodności z Kubernetesem klienta, a nie jako zamiennik zespołu platformowego. Wymiarowanie, wysoka dostępność i aktualizacje przebiegają zgodnie ze standardami Twojego klastra.
- -Wdrożenie za pomocą zatwierdzonych przez klienta manifestów lub operatorów
- -Przestrzeganie limitów zasobów i polityk bezpieczeństwa podów
- -Tożsamość runnera i listy dozwolonych hostów wykonawczych
- -Etapowe wdrożenia na poziomie przestrzeni nazw lub klastra
Bezpieczne granice wykonania
Przestrzenie nazw, polityki sieciowe i konta usług izolują wykonanie od niepowiązanych obciążeń. Sekrety są montowane w czasie uruchomienia, a nie przechowywane w Zof Cloud.
- -RBAC w zakresie przestrzeni nazw
- -Integracja z zewnętrznymi menedżerami sekretów tam, gdzie jest wspierana
- -Opcjonalne dopasowanie do service mesh
- -Audyt zdarzeń cyklu życia agenta
Testowanie aplikacji wyłącznie wewnętrznych
Weryfikuj mikrousługi, wewnętrzne API i interfejsy administracyjne dostępne z sieci klastra, nie wystawiając ich na publiczny internet.
- -Testy usługa-usługa wewnątrz klastra
- -Tylko ingress, gdy zezwala na to polityka
- -Łączenie z runnerami edge dla starszych systemów poza klastrem
- -Celowanie świadome grafu ogranicza szum
Izolacja przestrzeni nazw
Zespoły mapują jednostki biznesowe lub środowiska na przestrzenie nazw z odrębnymi politykami, retencją i trybami dowodowymi.
- -Rozdzielenie dev / staging / prod
- -Limity i ograniczenia współbieżności na zespół
- -Magazyny dowodów ograniczone do przestrzeni nazw
- -Procesy promocji między przestrzeniami nazw
Obsługa sekretów
Poświadczenia są pośredniczone w czasie wykonania poprzez PAM lub integracje z sekretami klastra. Długotrwałe sekrety domyślnie nie są kopiowane do zewnętrznego SaaS.
- -Preferowane krótkotrwałe tokeny
- -Wzorce zgodne z PAM
- -Brak trwałego przechowywania sekretów w płaszczyźnie planowania bez zatwierdzenia
- -Rotacja zgodna z Twoimi standardami
Routing artefaktów
Artefakty testowe i pakiety pozostają w pamięci kontrolowanej przez klienta, chyba że skonfigurujesz oczyszczony ruch wychodzący lub ruch tylko metadanych.
Architektura wykonywania hybrydowego
Orkiestracja w chmurze z rozproszonymi lokalnymi flotami wykonawczymi.
- -Wolumeny zgodne z S3, NFS lub wolumeny w klastrze
- -Polityki retencji na przestrzeń nazw
- -Sumy kontrolne i podpisywanie pakietów
- -Opcjonalna promocja do centralnego katalogu dowodów
Granice telemetrii
Metryki i logi z agentów mogą pozostawać w stosach obserwowalności wewnątrz klastra. Centralne pulpity mogą otrzymywać podsumowania zawierające wyłącznie metadane.
- -Wzorce zgodne z OpenTelemetry tam, gdzie są wspierane
- -Redakcja przed eksportem poza granicę
- -Identyfikatory korelacji na potrzeby audytu
- -Brak obowiązkowej eksfiltracji pełnych logów
Nadzór korporacyjny
Podpisywanie kapsuł, zatwierdzenie przez człowieka oraz bramki remediacji obowiązują jednolicie, niezależnie od tego, czy wykonanie odbywa się na maszynach wirtualnych, bare metal czy w Kubernetesie.
- -Wersja polityki przypięta do uruchomień
- -Łańcuchy zatwierdzeń dla ścieżek produkcyjnych
- -Integracja z rekordami zmian ITSM
- -Eksport na potrzeby GRC i audytu wewnętrznego
Wzorce architektury hybrydowej
Wykonanie w Kubernetesie często współistnieje z runnerami VPC, lokalizacjami edge oraz agentami punktów końcowych w ramach jednej płaszczyzny sterowania.
- -Jeden graf i orkiestracja floty
- -Spójny model kapsuł na wszystkich powierzchniach
- -Polityki dowodowe na poszczególne powierzchnie
- -Przegląd architektury określa kolejność wdrożenia
Pytania dotyczące wdrożenia on-premises
Najczęstsze pytania zespołów infrastruktury i bezpieczeństwa.
Omów bezpieczne wdrożenie z Zof
Przeanalizuj segmentację, nadzór nad kapsułami i rozmieszczenie runnerów z zespołami, które wspierają regulowane przedsiębiorstwa.
