Polityka jako kodeks i pełnomocnik ds. polityki otwartej

Kobieta Technologia

Polityka jako kod jest naturalną ewolucją infrastruktury jako kodu. Kiedy zaczynasz zarządzać infrastrukturą jako kodem, szybko zdajesz sobie sprawę, że proces ten wymaga solidnego zarządzania i egzekwowania polityk w skali. Tradycyjne podejście polegające na definiowaniu i egzekwowaniu polityk za pomocą ręcznych procesów lub uciążliwych interfejsów GUI nie sprawdzi się.

Policy as code oznacza, że definiuje się polityki deklaratywnie, używając plików tekstowych, które są sprawdzane w kontroli źródeł i mogą być przeglądane i audytowane. Następnie za egzekwowanie zasad odpowiada silnik polityk.

W tym artykule skupimy się na tym, jak polityka jako kod działa w Kubernetes. Przyjrzymy się temu, co jest wbudowane w Kubernetes i jak Open Policy Agent – z Gatekeeper – pomaga operatorom Kubernetes w dalszym egzekwowaniu polityk.

Model polityki jako kodu pasuje do Kubernetes jak ulał, ponieważ Kubernetes opiera się na deklaratywnych definicjach na każdym poziomie. Administrator lub programista definiuje zasoby, zazwyczaj jako pliki YAML, a Kubernetes przechowuje je w swoim magazynie stanu, etcd. Następnie kontrolery Kubernetes obserwują te zasoby i uzgadniają stan świata z tymi zasobami.

Na przykład, jeśli utworzysz zasób Deployment z obrazem i określoną liczbą replik, Kubernetes utworzy strąki, które uruchomią obraz i upewnią się, że działa odpowiednia liczba replik.

Polisy to kolejny typ zasobów

Kubernetes sam definiuje pewne zasady, takie jak zasady bezpieczeństwa strąków i zasady sieciowe. Jednak rozszerzalna natura Kubernetes umożliwia korzystanie z polityk i silników polityk innych firm.

Kontrolerzy dostępu jako egzekutorzy polityk

W Kubernetes cykl życia żądania przebiega przez uwierzytelnienie, autoryzację i dopuszczenie. Kiedy przychodzi żądanie, Kubernetes najpierw je uwierzytelnia, aby sprawdzić, kto je zgłasza. Następnie żądanie przechodzi przez autoryzację, aby sprawdzić, czy podmiot żądający jest uprawniony do złożenia tego żądania. Na tym etapie żądanie może zostać odrzucone. Jeśli żądanie jest autoryzowane, to przechodzi ono przez dopuszczenie, które sprawdza bardziej dynamiczne warunki. Również na tym etapie autoryzowane żądanie może zostać odrzucone.

Przyjęcie jest etapem, na którym następuje egzekwowanie zasad. Mechanizmy polityki mogą być zaimplementowane jako kontrolery dopuszczenia, które będą oznaczać, ostrzegać i/lub odrzucać żądania naruszające zasady.

Polityki bezpieczeństwa dla strąków

Kubernetes posiadał polityki bezpieczeństwa dla strąków, ale zostały one wycofane w wersji Kubernetes 1.21 i zostaną zastąpione przez nowszy projekt. Egzekwowanie ustawień bezpieczeństwa na strąkach jest ważnym zagadnieniem, którego nie można wykonać za pomocą istniejących mechanizmów, takich jak uwierzytelnianie, autoryzacja czy kontekst bezpieczeństwa strąków. Dobrym przykładem takiej polityki jest zakaz uruchamiania strąków w określonej przestrzeni nazw z uprawnieniami roota.

Zasady sieciowe

Kontrolowanie wejścia i wyjścia z sieci to kolejna krytyczna funkcjonalność. Kubernetes udostępnia wbudowane polityki sieciowe. Polityka sieciowa działa na poziomie strąków (używając selektorów etykiet) i może kontrolować dostęp (wejście i wyjście) na poziomie przestrzeni nazw, strąków lub bloków IP. Należy pamiętać, że Kubernetes nie dostarcza kontrolera, który egzekwowałby te polityki. Aby korzystać z polityk sieciowych, klaster musi posiadać plugin sieciowy, który obsługuje polityki sieciowe.

Chociaż wbudowane polityki Kubernetes są dobrym początkiem, nie są wystarczające dla wielu organizacji z zaawansowanymi wymaganiami dotyczącymi zarządzania. To właśnie w tym przypadku silniki polityk firm trzecich

ja w. Open Policy Agent, który jest projektem CNCF, jest natywnym silnikiem polityk chmurowych, który może egzekwować polityki dla wielu różnych celów, w tym Kubernetes, Envoy, Terraform, HTTP API, baz danych SQL, aplikacji Plain, Kafka i innych.

W tym artykule omawiamy Gatekeeper, kontroler dostępu Kubernetes, który ocenia polityki OPA w oparciu o niestandardowe definicje zasobów (CRD) Kubernetes.

Komponenty G

atekeepera Gatekeeper

składa się z trzech podstawowych komponentów

:

  1. Kontroler, odpowiedzialny za tworzenie niestandardowych zasobów Constraint.
  2. Audytor, który skanuje klaster i wykrywa naruszenia zasad.
  3. Webhook walidujący, który jest odpowiedzialny za odrzucanie żądań naruszających zasady.

Gatekeeper posiada również CLI o nazwie Gator, który może pomóc w lokalnym testowaniu ograniczeń i szablonów ograniczeń.

Biblioteka polity

k

Można zdefiniować własne polityki, ale Gatekeeper jest już dostarczany z pokaźną biblioteką polityk. Biblioteka ta zawiera dużą sekcję polityk ogólnych, które obejmują wiele tematów. Niektóre przykłady to:

Jednym z powodów, dla których Kubernetes zrezygnował ze swojej oryginalnej polityki PodSecurityPolicy, jest to, że ten sam efekt można osiągnąć za pomocą ograniczeń Gatekeeper z biblioteki polityk.

Szablony ograniczeń

Gatekeeper

Szablon ograniczenia to CRD, który określa schemat i definicję ograniczenia w języku Rego. Szablon może być dostosowany przez administratora w celu utworzenia konkretnych ograniczeń, które będą później egzekwowane.

Oto wycinek z szablonu ograniczenia requiredprobes:

apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8srequiredprobes annotations: description: Wymaga, aby Pods posiadał sondy gotowości i/lub liveness. spec: crd: spec: names: kind: K8sRequiredProbes validation: openAPIV3Schema: type: object properties: probes: description: „Lista sond, które są wymagane (ex: `readinessProbe`)” type: array items: type: string probeTypes: description: „Sonda musi definiować pole wymienione w `probeType`, aby spełniała ograniczenie (np. `tcpSocket` spełnia `[’tcpSocket’, 'exec’]`)” type: array items: type: string

Gatekeeper constraints

Po zainstalowaniu szablonu ograniczeń na klastrze można zdefiniować ograniczenia wykorzystujące szabl

ony.

Gatekeeper egzekwuje zasady określone przez ograniczenia.

Oto przykład ograniczenia opartego na szablonie requiredprobes:

apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredProbes metadata: name: must-have-probes spec: match: kinds: – apiGroups: [„”] kinds: [„Pod”] parameters: probes: [„readinessProbe”, „livenessProbe”] probeTypes: [„tcpSocket”, „httpGet”, „exec”]

Ograniczenie to wymaga, aby każdy strąk posiadał sondy gotowości i liveness o podanych typach

. Rego

: deklaratywny język polityki

Język Rego używany do definiowania polityki opiera się na języku zapytań zwanym Datalog, rozszerzając go o obsługę dokumentów strukturalnych. Język Rego jest bardzo wydajny, a jego deklaratywny charakter sprawia, że świetnie nadaje się do zarządzania politykami. Oto przykład z szablonu ograniczenia requiredprobes:

targets: – target: admission.k8s.gatekeeper.sh rego: | package k8srequiredprobes probe_type_set = probe_types { probe_types := {type | type := input.parameters.probeTypes[_]} } violation[{ {„msg”: msg}] { container := input.review.object.spec.containers[_] probe := input.parameters.probes[_] probe_is_missing(container, probe) msg := get_violation_message(container, input.review, probe) } probe_is_missing(ctr, probe) = true { not ctr[probe] } probe_is_missing(ctr, probe) = true { probe_field_empty(ctr, probe) } probe_field_empty(ctr, probe) = true { probe_fields := {field | ctr[probe][field]} diff_fields := probe_type_set – probe_fields count(diff_fields) == count(probe_type_set) } get_violation_message(container, review, probe) = msg { msg := sprintf(„Container <%v>in your <%v> <%v>has no <%v>„, [container.name, review.kind.kind, review.object.metadata.name, probe]) }

OPA/Gatekeeper nie jest jedyną grą w mieście. Istnieją również inne silniki polityk specyficzne dla Kubernetes, których krzywe uczenia się są płytsze:

Kyverno jest natywnym silnikiem polityk Kubernetes. Polityki są definiowane jako YAML przy użyciu CRD Kubernetes. Nie ma specjalnego języka, jak w przypadku Rego. Kyverno posiada polityki do generowania konfiguracji, mutowania istniejących zasobów i walidacji zasobów.

K-Rail jest kolejnym silnikiem polityk typu open-source. Jest on również specyficzny dla Kubernetes i posiada wiele wbudowanych polityk. Nowe polityki są definiowane w języku Go i muszą zostać dodane do silnika.

Polityka jako kod jest ważną najlepszą praktyką dla dużych systemów. Kubernetes jest popularną platformą dla dużych systemów rozproszonych. Istnieje kilka solidnych rozwiązań dla policy as code na Kubernetes. OPA/Gatekeeper posiada potężny język definiowania polityk. Kyverno i K-Rail są specyficzne dla Kubernetes i mogą być prostsze w użyciu. Oceń swoje potrzeby i wybierz odpowiednie rozwiązanie dla danego przypadku użycia.

Chętnie usłyszymy, co o tym sądzisz. Zadaj pytanie lub zostaw komentarz poniżej.
Bądź na bieżąco z Cisco DevNet w serwisach społecznościowych!

LinkedIn | Twitter @CiscoDevNet | Facebook | Developer Video Channel

Share

:

Czytaj dalej: https://blogs.cisco.com/developer/policyascode01

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.