#Admission Control (Kabul Denetimi)

Admission control, iş yüklerinin kümede çalışmasına izin verme — ya da engelleme — sürecidir. Bunu kendi kurallarınızı uygulamak için kullanabilirsiniz. Onaylı bir registry'den imaj kullanmayan tüm container'ları engellemek, ya da belirtiminde kaynak limitleri bulunmayan Pod'ları engellemek isteyebilirsiniz.

Bunu admission controller webhook'larıyla yapabilirsiniz — küme içinde çalışan ve nesneler oluşturulduğunda kuralları uygulamak üzere API tarafından çağrılan HTTP sunucuları. Admission controller'lar sizin kendi mantığınızı kullanabileceği gibi Open Policy Agent gibi standart bir aracı da kullanabilir.

#Kaynaklar

• Admission controller kullanmak
• OPA Gatekeeper
• Gatekeeper politika kütüphanesi

#Validating ve Mutating Webhook'lar

Kendi admission control mantığınızı kümede çalıştırdığınız bir REST API içinde yazabilir ve Kubernetes nesnelerine uygulanacak kurallar yapılandırabilirsiniz:

• şu ValidatingWebhookConfiguration

  kümede Pod oluşturulduğunda veya güncellendiğinde devreye giriyor ve özel bir webhook sunucusundaki validate metodunu çağırıyor; sunucu, işlemin devam etmesine izin verilip verilmediğini döndürüyor

• şu MutatingWebhookConfiguration —

  Pod oluşturulduğunda veya güncellendiğinde devreye giriyor ve sunucudaki mutate uç noktasını çağırıyor; bu, Kubernetes işlemi yürütmeden önce belirtimi düzenleyip değişiklikleri geri gönderebilir.

Kümede bir webhook sunucusu çalıştırabilirdik — bu örnekler bir demo NodeJS web uygulamasıyla çalışıyor (GitHub'da kaynak kod) — ama daha yaygın bir alternatif var.

#OPA Gatekeeper'ı çalıştırmak

Özel webhook'ların iki olumsuz tarafı var: kodu kendiniz yazmanız gerekiyor, bu da bakım yükünüze ekleniyor; ve kuralları küme üzerinden keşfedilebilir değil, dolayısıyla harici dökümantasyona ihtiyacınız oluyor.

OPA Gatekeeper, admission control'ü genel kural tanımlarıyla (Rego adında bir dille) uygulayan bir alternatif.

Admission kurallarını — bir başka CNCF projesi olan — Gatekeeper ile dağıtacağız. Kubernetes'i yeni nesne tipleriyle genişletiyor ve kendi kurallarınızı saklamak ve uygulamak için o nesneleri kullanıyorsunuz.

OPA Gatekeeper de karmaşık bir bileşen; onu yönetmenin yükünü kendi controller'larınızı çalıştırmanın sorunlarıyla takas ediyorsunuz:

• opa-gatekeeper/v3.23.1.yaml — admission

  kurallarını tanımlamak için özel kaynaklar, controller için RBAC ve onu çalıştırmak için bir Service ile Deployment dağıtıyor

OPA'yı dağıtın:

kubectl apply -f labs/admission/specs/opa-gatekeeper

📋 Gatekeeper hangi özel kaynak tiplerini kuruyor?

kubectl get crd

#OPA admission kurallarını dağıtmak

Gatekeeper ile kural uygulamanın iki parçası var:

1. Genel bir kısıt tanımlayan bir ConstraintTemplate oluşturmak (örneğin

   belirli bir namespace'teki container'lar yalnızca belirli bir imaj registry'si kullanabilir)

1. Şablondan bir Constraint oluşturmak (örneğin whoami namespace'indeki

   container'lar yalnızca Docker Hub'daki courselabs repolarından imaj kullanabilir)

Kural tanımı Rego genel politika diliyle yapılıyor:

• requiredLabels-template.yaml —

  bir nesnede etiket zorunlu kılan basit (!) bir şablon tanımlıyor

• resourceLimits-template.yaml —

  container nesnelerinde resources tanımlı olmasını zorunlu kılan daha karmaşık bir şablon tanımlıyor

Şablonları oluşturun:

kubectl apply -f labs/admission/specs/opa-gatekeeper/templates

📋 Özel kaynakları yeniden kontrol edin; Gatekeeper kısıtları Kubernetes'te nasıl sakliyor sizce?

kubectl get crd

policyresourcelimits.constraints.gatekeeper.sh

requiredlabels.constraints.gatekeeper.sh

Şablonları kullanan kısıtlar şunlar:

• requiredLabels.yaml —

  Pod'larda app ve version, namespace'lerde ise kubernetes.courselabs.co etiketini zorunlu kılıyor

• resourceLimits.yaml —

  apod namespace'indeki tüm Pod'lar için resources belirtilmesini zorunlu kılıyor

Kısıtları dağıtın:

kubectl apply -f labs/admission/specs/opa-gatekeeper/constraints

📋 Zorunlu etiketler namespace kısıtının ayrıntılarını yazdırın. Neyi zorunlu kıldığı anlaşılıyor mu?

kubectl get requiredlabels

kubectl describe requiredlabels requiredlabels-ns

Rego kolay bir dil değil — ama politika tanımlamanın genel bir yolu. Trivy de hatalı yapılandırma kontrol kütüphanesi için Rego kullanıyor (o kütüphane eskiden appshield adlı bir repoda duruyordu).

#OPA kurallarını doğrulamak

labs/admission/specs/pi klasöründeki bu uygulama YAML'ı, namespace ve Pod'lar için tanımlı tüm OPA kurallarını ihlal ediyor.

📋 Uygulamayı dağıtın. Çalışıyor mu?

kubectl apply -f labs/admission/specs/pi

Bazı politika hataları Kubectl ile oluşturduğunuz nesnelerde oluyor — dolayısıyla böyle net doğrulama hataları görüyorsunuz.

Düzeltme fix-1/01-namespace.yaml dosyasında; namespace'e gereken etiketi ekliyor. Düzeltilmiş sürümü dağıtıp çıktıyı kontrol edin:

kubectl apply -f labs/admission/specs/pi/fix-1

Kubectl çıktısı tüm nesnelerin oluşturulduğunu söylüyor. http://localhost:30031 adresinde dinliyor olmalı. Çalışıyor mu? Hayır... Service oluşturulmuş ama ondan yanıt yok.

📋 Sorunun ne olduğunu görmek için hata ayıklayabilir misiniz?

kubectl describe svc pi-np -n pi

kubectl get po -n pi

kubectl get deploy,rs -n pi

kubectl describe rs -n pi

OPA Gatekeeper politikası Pod'ların oluşturulmasını engelliyor — olaylarda sebebini söyleyen iki uyarı mesajı var:

Error creating: admission webhook "validation.gatekeeper.sh" denied the request: [resource-limits] container <pi-web> has no resource limits

Error creating: admission webhook "validation.gatekeeper.sh" denied the request: [requiredlabels-pods] you must provide labels: {"version"}

Ama bunu Kubectl'de görmüyorsunuz, çünkü Pod'ları doğrudan siz oluşturmuyorsunuz — bir Deployment oluşturuyorsunuz, o bir ReplicaSet oluşturuyor, o da Pod'ları oluşturuyor.

fix-2/deployment.yaml içindeki Pod şablonu gereken etiketleri ve kaynakları ekliyor.

📋 fix-2 YAML'ını dağıtın — uygulama şimdi çalışıyor mu?

kubectl apply -f labs/admission/specs/pi/fix-2

kubectl get pods -n pi

Uygulamayı şimdi http://localhost:30031 adresinde deneyin. Sınırlı miktarda CPU ve bellekle çalışıyor ve operasyon açısından yönetimi kolay, çünkü tutarlı bir etiket kümesine sahip.

#Lab

Sıra bir uygulama dağıtıp admission gereksinimlerini karşıladığından emin olmada sizde.

Bu lab'ın belirtimlerinden demo Astronomy Picture of the Day uygulamasını dağıtmayı deneyin:

kubectl apply -f labs/admission/specs/apod

Kaynaklar, yürürlükteki kısıtları karşılamadığı için başarısız olacak. Göreviniz belirtimleri düzeltip uygulamayı çalıştırmak — politikalarda hiçbir değişiklik yapmadan 🙂

Takıldınız mı? İpuçlarına bakın veya çözümü inceleyin.

#Temizlik

Lab'ın tüm namespace'lerini kaldırın; bu diğer tüm nesneleri de kaldırıyor:

kubectl delete ns -l kubernetes.courselabs.co=admission

CRD'ler hariç:

kubectl delete crd -l gatekeeper.sh/system

kubectl delete crd -l gatekeeper.sh/constraint