Wallarm Sidecar'ı Dağıtma¶

Kubernetes kümesinde Pod olarak dağıtılmış bir uygulamayı güvenceye almak için, uygulamanın önünde sidecar denetleyicisi olarak NGINX tabanlı Wallarm düğümünü çalıştırabilirsiniz. Wallarm sidecar denetleyicisi, uygulama Pod'una gelen trafiği filtreleyerek yalnızca meşru istekleri kabul eder ve kötü niyetli olanları sınırlar.

Wallarm Sidecar çözümünün ana özellikleri:

Uygulamalara benzer bir dağıtım formatı sağlayarak ayrık mikro hizmetlerin ve bunların replikalarının ve shard'larının korunmasını basitleştirir
Herhangi bir Ingress controller ile tamamen uyumludur
Genellikle service mesh yaklaşımı için yaygın olan yüksek yükler altında kararlı çalışır
Uygulamalarınızı güvenceye almak için minimum hizmet yapılandırması gerektirir; korumak istediğiniz uygulama pod'una yalnızca bazı açıklamalar (annotations) ve etiketler ekleyin
Wallarm konteyner dağıtımının iki modunu destekler: Wallarm servislerinin tek konteynerde çalıştığı orta yükler ve Wallarm servislerinin birkaç konteynere bölündüğü yüksek yükler için
Wallarm sidecar çözümü için yerel veri analitiği arka ucu olan ve belleğin çoğunu tüketen postanalytics modülü için özel bir varlık sağlar

Kullanım senaryoları¶

Desteklenen tüm Wallarm dağıtım seçenekleri arasında, bu çözüm aşağıdaki kullanım senaryoları için önerilir:

Mevcut Ingress controller'lı (ör. AWS ALB Ingress Controller) altyapıya dağıtılacak bir güvenlik çözümü arıyorsunuz ve bu durum Wallarm NGINX tabanlı Ingress Controller veya Kong Ingress controller için Wallarm bağlayıcı dağıtımını engelliyor
Her mikro hizmetin (dahili API'ler dahil) güvenlik çözümüyle korunmasını gerektiren sıfır güven (zero-trust) ortamı

Trafik akışı¶

Wallarm Sidecar ile trafik akışı:

Çözüm mimarisi¶

Wallarm Sidecar çözümü aşağıdaki Deployment nesneleriyle düzenlenir:

Sidecar controller (wallarm-sidecar-controller), Pod'a Wallarm sidecar kaynaklarını enjekte eden, onu Helm chart değerleri ve pod açıklamalarına göre yapılandıran ve düğüm bileşenlerini Wallarm Cloud'a bağlayan mutating admission webhook'tur.

Kubernetes'te wallarm-sidecar: enabled etiketi bulunan yeni bir pod başlatıldığında, denetleyici gelen trafiği filtreleyen ek konteyneri otomatik olarak pod'a enjekte eder.
Postanalytics modülü (wallarm-sidecar-postanalytics), Wallarm sidecar çözümü için yerel veri analitiği arka ucudur. Modül, bellek içi depolama wstore'u ve saldırı dışa aktarma servisleri gibi bazı yardımcı konteynerleri kullanır.

Wallarm Sidecar'ın yaşam döngüsünde 2 standart aşama vardır:

Başlangıç aşamasında, denetleyici Wallarm sidecar kaynaklarını Pod'a enjekte eder, onu Helm chart değerleri ve pod açıklamalarına göre yapılandırır ve düğüm bileşenlerini Wallarm Cloud'a bağlar.
Çalışma zamanında, çözüm postanalytics modülünü kullanarak istekleri analiz eder ve proxy'ler/iletir.

Çözüm, Alpine Linux ve Alpine'in sağladığı NGINX sürümüne dayalı Docker imajlarını kullanır. Şu anda en yeni imajlar, NGINX kararlı sürüm 1.28.0'ı içeren Alpine Linux sürüm 3.22'yi kullanmaktadır.

Gereksinimler¶

Kubernetes platform version 1.19-1.29
Helm v3 package manager
An application deployed as a Pod in a Kubernetes cluster
Access to https://us1.api.wallarm.com for working with US Wallarm Cloud or to https://api.wallarm.com for working with EU Wallarm Cloud
Access to https://charts.wallarm.com to add the Wallarm Helm charts
Access to the Wallarm repositories on Docker Hub https://hub.docker.com/r/wallarm
Access to the IP addresses and their corresponding hostnames (if any) listed below. This is needed for downloading updates to attack detection rules and API specifications, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers
US CloudEU Cloud
node-data0.us1.wallarm.com - 34.96.64.17 node-data1.us1.wallarm.com - 34.110.183.149 us1.api.wallarm.com - 35.235.66.155 34.102.90.100 34.94.156.115 35.235.115.105
node-data1.eu1.wallarm.com - 34.160.38.183 node-data0.eu1.wallarm.com - 34.144.227.90 api.wallarm.com - 34.90.110.226
Access to the account with the Administrator role in Wallarm Console for the US Cloud or the EU Cloud

Dağıtım¶

Wallarm Sidecar çözümünü dağıtmak için:

Bir filtreleme düğümü belirteci (token) oluşturun.
Wallarm Helm chart'ını dağıtın.
Wallarm Sidecar'ı uygulama Pod'una ekleyin.
Wallarm Sidecar çalışmasını test edin.

Adım 1: Bir filtreleme düğümü belirteci oluşturun¶

Sidecar pod'larını Wallarm Cloud'a bağlamak için uygun türde bir filtreleme düğümü belirteci oluşturun:

API tokenNode token

Wallarm Console → Settings → API tokens bölümünü US Cloud veya EU Cloud içinde açın.
Kullanım türü Node deployment/Deployment olan bir API token'ı bulun veya oluşturun.
Bu token'ı kopyalayın.

Wallarm Console → Nodes bölümünü US Cloud veya EU Cloud içinde açın.
Wallarm node türünde bir filtreleme düğümü oluşturun ve üretilen token'ı kopyalayın.

Adım 2: Wallarm Helm chart'ını dağıtın¶

Wallarm chart deposunu ekleyin:

helm repo add wallarm https://charts.wallarm.com
helm repo update wallarm

Wallarm Sidecar yapılandırmasını içeren values.yaml dosyasını oluşturun. Minimum yapılandırmaya sahip dosya örneği aşağıdadır.

API token kullanırken, nodeGroup parametresinde bir düğüm grup adı belirtin. Sidecar pod'ları için oluşturulan düğümleriniz, Wallarm Console'un Nodes bölümünde gösterilen bu gruba atanacaktır. Varsayılan grup adı defaultSidecarGroup'tur. Gerekirse, daha sonra korudukları uygulamaların pod'ları için sidecar.wallarm.io/wallarm-node-group açıklamasını kullanarak filtreleme düğümü grup adlarını pod bazında ayrı ayrı ayarlayabilirsiniz.
US CloudEU Cloud
config: wallarm: api: token: "<NODE_TOKEN>" host: "us1.api.wallarm.com" # nodeGroup: "defaultSidecarGroup"
config: wallarm: api: token: "<NODE_TOKEN>" # nodeGroup: "defaultSidecarGroup"
<NODE_TOKEN>, Kubernetes'te çalışacak Wallarm düğümünün token'ıdır.

Using one token for several installations

You can use one token in several installations regardless of the selected platform. It allows logical grouping of node instances in the Wallarm Console UI. Example: you deploy several Wallarm nodes to a development environment, each node is on its own machine owned by a certain developer.
Wallarm Helm chart'ını dağıtın:
```
helm install --version 6.5.1 <RELEASE_NAME> wallarm/wallarm-sidecar --wait -n wallarm-sidecar --create-namespace -f <PATH_TO_VALUES>
```
- <RELEASE_NAME>, Wallarm Sidecar chart'ının Helm sürüm adı
- wallarm-sidecar, Wallarm Sidecar chart'ının Helm sürümünün dağıtılacağı yeni ad alanı; ayrı bir ad alanına dağıtılması önerilir
- <PATH_TO_VALUES>, values.yaml dosyasının yolu

Adım 3: Wallarm Sidecar'ı uygulama Pod'una ekleyin¶

Wallarm'ın uygulama trafiğini filtrelemesi için, ilgili uygulama Pod'una wallarm-sidecar: enabled etiketini ekleyin:

kubectl edit deployment -n <APPLICATION_NAMESPACE> <APP_LABEL_VALUE>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        wallarm-sidecar: enabled
    spec:
      containers:
        - name: application
          image: kennethreitz/httpbin
          ports:
            - name: http
              containerPort: 80

wallarm-sidecar uygulama Pod etiketi disabled olarak ayarlanmışsa veya açıkça belirtilmemişse, Wallarm Sidecar konteyneri bir pod'a enjekte edilmez ve dolayısıyla Wallarm trafiği filtrelemez.
wallarm-sidecar uygulama Pod etiketi enabled olarak ayarlanmışsa, Wallarm Sidecar konteyneri bir pod'a enjekte edilir ve dolayısıyla Wallarm gelen trafiği filtreler.

Adım 4: Wallarm Sidecar çalışmasını test edin¶

Wallarm Sidecar'ın doğru çalıştığını test etmek için:

Başarıyla başlatıldığını kontrol etmek üzere Wallarm kontrol düzlemi ayrıntılarını alın:

kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar

Her pod aşağıdakileri göstermelidir: READY: N/N ve STATUS: Running, ör.:

NAME                                             READY   STATUS    RESTARTS   AGE
wallarm-sidecar-controller-54cf88b989-gp2vg      1/1     Running   0          91m
wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k   3/3     Running   0          91m

Wallarm sidecar konteynerinin başarıyla enjekte edildiğini kontrol etmek için uygulama pod ayrıntılarını alın:
```
kubectl get pods -n <APPLICATION_NAMESPACE> --selector app=<APP_LABEL_VALUE>
```
Çıktı, başarılı sidecar konteyner enjeksiyonunu gösteren READY: 2/2 ve Wallarm Cloud'a başarılı bağlantıyı gösteren STATUS: Running içermelidir:
```
NAME                     READY   STATUS    RESTARTS   AGE
myapp-5c48c97b66-lzkwf   2/2     Running   0          3h4m
```
Wallarm'ın trafiği filtrelemek üzere etkin olduğu uygulama kümesi adresine test amaçlı bir Path Traversal saldırısı gönderin:
```
curl http://<APPLICATION_CLUSTER_IP>/etc/passwd
```
Wallarm proxy varsayılan olarak monitoring filtreleme modunda çalıştığından, Wallarm düğümü saldırıyı engellemeyecek ancak kaydedecektir.

Saldırının kaydedildiğini kontrol etmek için Wallarm Console → Attacks bölümüne gidin:

ARM64 dağıtımı¶

Sidecar proxy'nin Helm chart sürümü 4.10.2 ile ARM64 işlemci uyumluluğu sunulmuştur. Başlangıçta x86 mimarileri için ayarlanmış olan dağıtım, ARM64 düğümlerinde Helm chart parametrelerinin değiştirilmesini gerektirir.

ARM64 ayarlarında, Kubernetes düğümleri genellikle arm64 etiketi taşır. Kubernetes zamanlayıcısının Wallarm iş yükünü uygun düğüm türüne atamasına yardımcı olmak için bu etikete Wallarm Helm chart yapılandırmasında nodeSelector, tolerations veya affinity kuralları kullanılarak referans verin.

Aşağıda, ilgili düğümler için kubernetes.io/arch: arm64 etiketini kullanan Google Kubernetes Engine (GKE) için Wallarm Helm chart örneği bulunmaktadır. Bu şablon, kendi ARM64 etiketleme kurallarına saygı göstererek diğer bulut yapılandırmalarıyla uyum için değiştirilebilir.

nodeSelectortolerations

config:
  wallarm:
    api:
      token: "<NODE_TOKEN>"
      # API token kullanıyorsanız, aşağıdaki satırın yorum işaretini kaldırın ve düğüm grup adınızı belirtin
      # nodeGroup: "defaultSidecarGroup"
  postanalytics:
    nodeSelector:
      kubernetes.io/arch: arm64
  controller:
    nodeSelector:
      kubernetes.io/arch: arm64

config:
  wallarm:
    api:
      token: "<NODE_TOKEN>"
      # API token kullanıyorsanız, aşağıdaki satırın yorum işaretini kaldırın ve düğüm grup adınızı belirtin
      # nodeGroup: "defaultSidecarGroup"
  postanalytics:
    tolerations:
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
  controller:
    tolerations:
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule

OpenShift'te Security Context Constraints (SCC)¶

Sidecar çözümünü OpenShift üzerinde dağıtırken, platformun güvenlik gereksinimlerine uygun özel bir Security Context Constraint (SCC) tanımlamak gerekir. Varsayılan kısıtlamalar Wallarm çözümü için yetersiz olabilir ve hatalara yol açabilir.

Aşağıda, OpenShift'e uyarlanmış Wallarm Sidecar çözümü için önerilen özel SCC bulunmaktadır. Bu yapılandırma, iptables kullanılmadan ayrıcalıksız modda çözümü çalıştırmak için tasarlanmıştır.

Sidecar'ı dağıtmadan önce SCC'yi uygulayın

SCC'nin Wallarm Sidecar çözümünü dağıtmadan önce uygulanmış olduğundan emin olun.

Özel SCC'yi aşağıdaki gibi wallarm-scc.yaml dosyasında tanımlayın:

allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: false
allowPrivilegedContainer: false
allowedCapabilities:
- NET_BIND_SERVICE
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  type: MustRunAs
groups: []
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: wallarm-sidecar-deployment
  name: wallarm-sidecar-deployment
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities:
- ALL
runAsUser:
  type: MustRunAsRange
  uidRangeMin: 101
  uidRangeMax: 65532
seLinuxContext:
  type: MustRunAs
seccompProfiles:
- runtime/default
supplementalGroups:
  type: RunAsAny
users: []
volumes:
- configMap
- emptyDir
- secret

Bu politikayı kümeye uygulayın:
```
kubectl apply -f wallarm-scc.yaml
```
Sidecar'ın dağıtılacağı bir Kubernetes ad alanı oluşturun, ör.:
```
kubectl create namespace wallarm-sidecar
```

Wallarm Sidecar iş yüklerinin SCC politikasını kullanmasına izin verin:

oc adm policy add-scc-to-user wallarm-sidecar-deployment \
  -z <RELEASE_NAME>-wallarm-sidecar-postanalytics -n wallarm-sidecar

oc adm policy add-scc-to-user wallarm-sidecar-deployment \
  -z <RELEASE_NAME>-wallarm-sidecar-admission -n wallarm-sidecar

<RELEASE_NAME>: helm install sırasında kullanacağınız Helm sürüm adı.

wallarm-sidecar sürüm adında geçiyorsa

Sürüm adı wallarm-sidecar içeriyorsa, bunu servis hesabı adlarından çıkarın.

Hesap adları wallarm-sidecar-postanalytics ve wallarm-sidecar-admission olacaktır.
-n wallarm-sidecar: Sidecar'ın dağıtılacağı ad alanı (yukarıda oluşturuldu).

Örneğin, ad alanı wallarm-sidecar ve Helm sürüm adı wlrm-sidecar ise:

oc adm policy add-scc-to-user wallarm-sidecar-deployment \
  -z wlrm-sidecar-wallarm-sidecar-postanalytics -n wallarm-sidecar

oc adm policy add-scc-to-user wallarm-sidecar-deployment \
  -z wlrm-sidecar-wallarm-sidecar-admission -n wallarm-sidecar

Yukarıda belirtilen ad alanını ve Helm sürüm adını kullanarak Wallarm Sidecar'ı dağıtın.

Ayrıcalıklı iptables konteyneri çalıştırmaktan kaçınmak için iptables kullanımını devre dışı bırakın. Bu, values.yaml içinde global olarak veya anotasyonlar aracılığıyla pod bazında yapılabilir.

iptables'ı values.yaml üzerinden devre dışı bırakmaPod anotasyonu ile iptables'ı devre dışı bırakma

values.yaml içinde config.injectionStrategy.iptablesEnable değerini false olarak ayarlayın.

config:
  injectionStrategy:
    iptablesEnable: false
  wallarm:
    api:
      ...

Uygulamanızın Service manifest'inde spec.ports.targetPort değerini proxy olarak ayarlayın. iptables devre dışıyken, Sidecar bu portu açığa çıkarır.
```
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
  namespace: default
spec:
  ports:
    - port: 80
      targetPort: proxy
      protocol: TCP
      name: http
  selector:
    app: myapp
```
Uygulamayı bir OpenShift Route üzerinden yayımlarken, spec.ports.targetPort değerini 26001 olarak ayarlayın.

Pod'un açıklamasında sidecar.wallarm.io/sidecar-injection-iptables-enable anahtarını "false" olarak ayarlayarak iptables'ı pod bazında devre dışı bırakın.
Uygulamanızın Service manifest'inde spec.ports.targetPort değerini proxy olarak ayarlayın. iptables devre dışıyken, Sidecar bu portu açığa çıkarır.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        wallarm-sidecar: enabled
      annotations:
        sidecar.wallarm.io/sidecar-injection-iptables-enable: "false"
    spec:
      containers:
        - name: application
          image: kennethreitz/httpbin
          ports:
            - name: http
              containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
  namespace: default
spec:
  ports:
    - port: 80
      targetPort: proxy
      protocol: TCP
      name: http
  selector:
    app: myapp

Uygulamayı bir OpenShift Route üzerinden yayımlarken, spec.ports.targetPort değerini 26001 olarak ayarlayın.

Güncellenmiş yapılandırma ile uygulamayı dağıtın:

kubectl -n <APP_NAMESPACE> apply -f <MANIFEST_FILE>

Doğru SCC'nin Wallarm pod'larına uygulandığını doğrulayın:

WALLARM_SIDECAR_NAMESPACE="wallarm-sidecar"
POD=$(kubectl -n ${WALLARM_SIDECAR_NAMESPACE} get pods -o name -l "app.kubernetes.io/component=postanalytics" | cut -d '/' -f 2)
kubectl -n ${WALLARM_SIDECAR_NAMESPACE}  get pod ${POD} -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}'

Beklenen çıktı wallarm-sidecar-deployment'tır.

Enjekte edilen Sidecar konteyneri bu UID aralığında çalıştığından, uygulama pod'unuza wallarm-sidecar-deployment ile aynı SCC'yi verin; gerekli UID aralığına izin verdiğinden emin olun.

wallarm-sidecar-deployment politikasını atamak için aşağıdaki komutu kullanın:
```
APP_NAMESPACE=<APP_NAMESPACE>
POD_NAME=<POD_NAME>
APP_POD_SERVICE_ACCOUNT_NAME=$(oc get pod $POD_NAME -n $APP_NAMESPACE -o jsonpath='{.spec.serviceAccountName}')
oc adm policy add-scc-to-user wallarm-sidecar-deployment \
  system:serviceaccount:$APP_NAMESPACE:$APP_POD_SERVICE_ACCOUNT_NAME
```
Prod ortamında, uygulamanızın ve Wallarm'ın ihtiyaçlarına uygun özel bir SCC oluşturun.

Özelleştirme¶

Wallarm pod'ları, varsayılan values.yaml ve 2. dağıtım adımında belirttiğiniz özel yapılandırmaya göre enjekte edilmiştir.

Wallarm proxy davranışını hem global hem de pod bazında daha da özelleştirerek, şirketiniz için Wallarm çözümünden en iyi şekilde yararlanabilirsiniz.

Sadece Wallarm proxy çözümü özelleştirme kılavuzuna ilerleyin.