Kubernetes API Server Audit Log: Politika ve SIEM Pipeline

Kubernetes’te güvenlik konuşurken çoğu ekip RBAC, network policy ve image signing’e odaklanır. Bunlar doğru; ama “kim, ne zaman, ne yaptı?” sorusuna net cevap veremiyorsanız olay yönetiminde kör kalırsınız. Bu körlüğü kapatan ana sinyal kaynaklarından biri API Server audit log’larıdır.

Bu yazıda hedefim “audit log açtık” seviyesinde değil, işletilebilir bir audit log hattı tasarlamak:

• Gürültüyü kontrol etmek (maliyet + sinyal kalitesi)
• Hassas veriyi maskelemek (response body/secret sızıntısı)
• SIEM’de korelasyon kurmak (IDP + cluster + node)
• Operasyonel runbook’u netleştirmek (doğrulama, rollback, saklama)

1) Audit log’dan ne bekliyoruz?

Audit log’un en büyük değeri, güvenlik ekibinin “şüpheli” dediği bir aksiyonu kanıta bağlayabilmesidir:

• create tokenreviews / create subjectaccessreviews artışı
• create/patch clusterrolebinding gibi yetki genişletme
• exec/portforward gibi “interactive” erişimler
• get secrets gibi hassas nesnelere erişim

2) Audit policy tasarımı: “her şeyi logla” tuzağı

Kubernetes audit’te dört temel level vardır:

• None: hiç loglama
• Metadata: kim/ne/nerede (body yok)
• Request: request body dahil
• RequestResponse: request + response body dahil

Üretimde pratik yaklaşım genelde şudur:

• Default: Metadata
• Çok gürültülü endpoint’ler: None
• Çok kritik bazı aksiyonlar: Request (nadiren)
• RequestResponse: çok istisnai (çoğu kurumda gereksiz risk)

Örnek audit policy (başlangıç)

Bu dosya bir “çekirdek” policy örneğidir; kendi ortamınıza göre genişletin:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  # 1) Gürültüyü kes: healthz/readyz/livez
  - level: None
    nonResourceURLs:
      - "/healthz*"
      - "/readyz*"
      - "/livez*"
      - "/version"

  # 2) Sistem bileşenleri: default metadata
  - level: Metadata
    userGroups:
      - "system:authenticated"

  # 3) Secret erişimini görünür tut: metadata (body yok)
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]

  # 4) Yetki değişiklikleri: metadata + daha sıkı izleme
  - level: Metadata
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]

  # 5) Interactive aksiyonlar: metadata
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/exec", "pods/portforward", "pods/attach"]

  # 6) Fallback: metadata
  - level: Metadata

3) Pipeline: API Server → collector → SIEM

En stabil yaklaşım: audit log’u node diskine yazdır, ajan ile topla, normalize et ve gönder.

Basit mimari:

• API Server: audit file output (rotate enabled)
• Node: log collector (Vector/Fluent Bit/Alloy) ile tail
• Pipeline: parse + normalize + redaction
• SIEM: index + correlation + alert

Normalizasyon: SIEM’in sevdiği alanlar

SIEM’de arama/korelasyon için şu alanları standardize etmek işinizi büyütür:

• cluster: prod-eu-1 gibi sabit kimlik
• user.username, user.groups
• sourceIPs (varsa LB/ingress gerçek client IP)
• verb, objectRef.resource, objectRef.namespace, objectRef.name
• responseStatus.code
• requestURI
• userAgent

4) Saklama ve maliyet: log’u “yakma”

Audit log maliyeti hızla büyür. O yüzden:

• Gürültülü non-resource URL’leri None yap
• RequestReceived stage’ini omit et (korelasyon için çoğu zaman şart değil)
• Sadece kritik kuralları alert seviyesinde işle, geri kalanı “searchable” kalsın
• Retention katmanla: sıcak (7-14 gün), soğuk (30-90 gün), arşiv (uyum gereği)

5) Alarm fikirleri (sahada işe yarayanlar)

Başlangıç için pratik sinyaller:

• clusterrolebinding create/patch (özellikle cluster-admin bağlama)
• secrets list/get artışı (kullanıcı bazlı anomali)
• pods/exec çoklanması (özellikle prod namespace’lerinde)
• tokenreviews patlaması (şüpheli auth probing)
• “break-glass” kullanıcı ile yapılan aksiyonlar (beklenen, ama görünür)

6) Doğrulama ve runbook

Değişiklikleri güvenli devreye almak için mini runbook:

1. Canary control-plane node’da policy aktif et (mümkünse)
2. 15-30 dakika log hacmini ve SIEM ingestion’ı izle
3. Secrets body sızıntısı olmadığını doğrula (örnek arama: \"kind\":\"Secret\" + data: gibi)
4. Gürültü noktalarını tespit et, policy’de None/Metadata ayarla
5. “Rollback” hazırlığı: policy dosyasını eski haline döndür + apiserver restart prosedürü

Audit log doğru tasarlanırsa güvenlik ekibi için bir “sinyal üretim hattı”, platform ekibi için ise “operasyonel hafıza” olur. Yanlış tasarlanırsa sadece maliyet ve risk üretir. Bu yüzden policy + pipeline + runbook’u birlikte kur.