LLM Operasyon Güvenliği

Kubernetes LLM Güvenliği: Model Servisini Sertleştirme

Kubernetes LLM güvenliği için ağ politikası, Pod Security Standards, Secret şifreleme, GPU düğümü yalıtımı ve imaj doğrulamasıyla model servisini koruyun.

Fevzi Ege YurtsevenlerYapay Zekâ Güvenliği Araştırmacısı · AltaySec Kurucusu

13 Ekim 2026 · altaysec.com.tr

Kubernetes LLM güvenliği, model servisini sıradan bir web uygulaması gibi görmeyi bırakmakla başlar. Bir LLM servisi pahalı GPU donanımı kullanır, değerli model ağırlıkları taşır, dışarıdan gelen metni işler ve çoğu zaman araçlara ya da iç servislere bağlanır. Bu yüzeyi daraltan beş katman şunlardır: ağ politikası, pod güvenliği, sır yönetimi, GPU düğümü yalıtımı ve imaj doğrulaması. Her katman bir öncekinin kaçırdığını yakalar.

Kubernetes LLM güvenliği hangi yüzeylerle başlar?

LLM servisi kümede dört yüzey açar: istek yolu, model ağırlıklarının durduğu depolama, düğümdeki GPU yığını ve servisin kullandığı sırlar. Saldırgan bunlardan birini ele geçirirse diğerlerine geçmeye çalışır. Uygulama katmanındaki istem enjeksiyonu savunmaları ayrı bir konudur. Altyapı kontrolleri ise o katmanda bir hata olduğunda zararı sınırlayan son hattır.

Yüzey	Tipik risk	Temel kontrol	Sorumlu
İstek yolu	Kimlik doğrulamasız API, yatay hareket	NetworkPolicy, ağ geçidi	Platform ekibi
Model ağırlıkları	Kopyalanma, değiştirilme	Salt okunur depo, özet doğrulama	ML platform ekibi
GPU yığını	Konteynerden ana makineye kaçış	Ayrı düğüm havuzu, sürüm takibi	Altyapı ekibi
Sırlar	API anahtarı ve parola sızıntısı	etcd şifrelemesi, RBAC, harici depo	Güvenlik ekibi

Model servisini LoadBalancer ya da NodePort türünde bir Service ile doğrudan dışarı açmayın. Dış trafik yalnız kimlik doğrulama, kota ve kayıt uygulayan ağ geçidinden girsin, model sunucusu yalnız küme içi adreste kalsın. Bu ayrım, model sunucusunun kendi kimlik doğrulaması olmadığında bile dışarıdan doğrudan çağrılmasını önler.

Aynı model sunucusu kümede değil tek bir makinede çalışıyorsa önce yerel LLM sunucusu maruziyet denetimi adımlarını uygulayın.

Ağ politikası ile trafik nasıl daraltılır?

NetworkPolicy, hangi pod'un hangi pod, ad alanı ya da IP bloğuyla konuşabileceğini tanımlar. Kubernetes belgeleri önemli bir koşulu açıkça yazar: politikaları ağ eklentisi uygular ve NetworkPolicy desteklemeyen bir eklentide oluşturulan politika hiçbir etki yaratmaz. İşe bu doğrulamayla başlayın.

Ardından ad alanındaki tüm giriş ve çıkışı kapatan politikayı uygulayın:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: varsayilan-reddet
  namespace: llm
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

Politikalar birbirini dışlamaz, toplanır. Bir pod'a uygulanan politikaların izin verdiği bağlantıların birleşimi geçerli olur. Bu yüzden izinleri ayrı ve dar politikalarla ekleyin. Aşağıdaki örnek, model sunucusuna yalnız ağ geçidi ad alanından girişe ve yalnız küme DNS'ine çıkışa izin verir:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: llm-sunucu-izinleri
  namespace: llm
spec:
  podSelector:
    matchLabels:
      app: llm-server
  policyTypes: ["Ingress", "Egress"]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: llm-gateway
      ports:
        - port: 8000
          protocol: TCP
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - port: 53
          protocol: UDP
        - port: 53
          protocol: TCP

Standart NetworkPolicy'nin sınırlarını da bilin. Belgeye göre bu API hizmetleri adla hedefleyemez, TLS ile ilgili hiçbir şey yapmaz ve engellenen ya da izin verilen bağlantıları kaydetmez. Dış model sağlayıcısına çıkış gerekiyorsa trafiği kayıt tutan bir çıkış vekili ya da ağ geçidi üzerinden geçirin. Ajan iş yüklerinde ek yalıtım katmanları için ajan sandbox izolasyon katmanları yazısına bakın.

Pod güvenliği hangi ayarlarla zorunlu kılınır?

Pod Security Standards üç profil tanımlar: privileged, baseline ve restricted. Restricted profil; allowPrivilegeEscalation: false, runAsNonRoot: true, tüm Linux yeteneklerinin bırakılmasını ve RuntimeDefault ya da Localhost türünde seccomp profilini zorunlu kılar. Baseline ise ayrıcalıklı konteyneri, hostNetwork kullanımını ve hostPath birimlerini zaten yasaklar. Ad alanını pod-security.kubernetes.io/enforce: restricted etiketiyle bu profile bağladığınızda, kurala uymayan pod'lar kabul aşamasında reddedilir.

Salt okunur kök dosya sistemi restricted profilin parçası değildir, ayrıca eklenmelidir. Model sunucuları çoğu zaman önbellek için yazılabilir dizin ister. Bunu emptyDir birimiyle verin:

spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: llm-server
      image: registry.example.com/llm-server@sha256:<ozet>
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          memory: "32Gi"
          nvidia.com/gpu: 1
      volumeMounts:
        - name: cache
          mountPath: /cache
  volumes:
    - name: cache
      emptyDir: {}

automountServiceAccountToken: false, Kubernetes API'sine ihtiyacı olmayan servisin hesap jetonunu pod'a bağlamaz. Bellek sınırı olmayan bir pod, uzun istem saldırısında düğümü tüketebilir. Token kotası ise ağ geçidinde uygulanır.

Sırlar ve model ağırlıkları nasıl korunur?

Kubernetes belgeleri bu konuda nettir: Secret nesneleri varsayılan olarak etcd'de şifrelenmeden saklanır. API erişimi olan herkes Secret'ı okuyabilir. Bir ad alanında pod ya da Deployment oluşturabilen herkes de o ad alanındaki Secret'lara dolaylı olarak erişir. Belgenin önerdiği asgari adımlar şunlardır:

Secret'lar için bekleme halinde şifrelemeyi açın.
Secret erişimini en az yetkili RBAC kurallarıyla sınırlayın.
Secret'ı yalnız ihtiyaç duyan konteynere bağlayın.
Harici bir sır deposu sağlayıcısını değerlendirin.

Sırları ortam değişkeni yerine bağlanmış dosya olarak vermeyi tercih edin. OWASP Secrets Management Cheat Sheet, ortam değişkenlerinin genellikle tüm süreçlerce okunabildiğini, günlüklere ve bellek dökümlerine girebildiğini belirtir. Sızıntı şüphesinde izlenecek adımlar LLM API anahtarı sızdı yazısında anlatılır.

Model ağırlıklarını imaja gömmeyin. İmajı çekebilen herkes modele de ulaşır. Ağırlıkları erişimi kayıtlı bir nesne deposunda tutun, okuma yetkisini yalnız servisin iş yükü kimliğine verin ve indirme sonrası özet değerini doğrulayın. Ham istek ve yanıtları varsayılan olarak günlüğe yazmayın, çünkü kişisel veri ve sır içerebilirler.

GPU düğümleri nasıl yalıtılır?

Model servisleri için ayrı bir GPU düğüm havuzu açın. Havuza taint ekleyin ve yalnız model servislerine uygun toleration verin. Böylece sıradan iş yükleri bu düğümlere yerleşemez.

GPU paylaşımında yalıtım düzeyini bilerek seçin. NVIDIA GPU Operator belgelerine göre zaman paylaşımında (time-slicing) replikalar arasında bellek ya da hata yalıtımı yoktur. MIG ise GPU'yu donanım düzeyinde bellek ve hata yalıtımı olan örneklere böler. Farklı güven düzeyindeki kiracıları aynı zaman paylaşımlı GPU'ya koymayın.

GPU yığınının kendisi de saldırı yüzeyidir. NVIDIA Container Toolkit'in 1.16.1 ve öncesinde, özel hazırlanmış bir konteyner imajının ana makine dosya sistemine erişmesine yol açan CVE-2024-0132 açığı yayımlandı. 1.17.7 ve öncesini etkileyen CVE-2025-23266 ise konteyner başlatma kancalarında yetki yükseltmeli kod çalıştırmaya izin veriyordu. Toolkit ve GPU Operator sürümlerini envanterde tutun, bültenleri izleyin.

GPU havuzu yalnız model servislerine ayrılmış mı?
Taint ve toleration başka iş yüklerini dışarıda tutuyor mu?
Zaman paylaşımı yalnız aynı güven düzeyindeki iş yükleri için mi açık?
Container Toolkit ve GPU Operator sürümleri güncel mi?
Düğümlere SSH erişimi kapalı ya da denetimli mi?

İmajlar ve bağımlılıklar nasıl doğrulanır?

İmaj taraması dağıtımdan önce bilinen açıkları yakalar, ama tek seferlik tarama yetmez. Yeni CVE'ler sonradan yayımlanır, bu yüzden kayıt defterindeki imajları düzenli yeniden tarayın. İmajı etiket yerine özet değeriyle çağırın. Böylece aynı etiketin sessizce farklı bir içeriğe işaret etmesi önlenir. İmajları imzalayın ve yalnız imzası doğrulanan imajları kabul eden bir admission denetleyicisi kullanın.

LLM servislerinde imajın içindeki çatılar ve çıkarım sunucuları hızlı sürüm çıkarır. Bunların takibi için LLM framework yama yönetimi yazısındaki envanter ve öncelik düzeni uygulanabilir. Bu kontrolleri dağıtım hattına kapı olarak yerleştirme yöntemi MLSecOps ve güvenlik kapıları yazısında anlatılır.

Sertleştirme sonrası ne izlenmeli ve nasıl sınanmalı?

Sertleştirme bir kerelik iş değildir. Yeni dağıtımlar, yapılandırma sapması ve yeni açıklar korumayı aşındırır. Ağ politikası ve pod ayarlarını altyapı kodu olarak tutun, değişiklikleri gözden geçirmeyle uygulayın.

İzlenecek başlıklar şunlardır:

Beklenmeyen çıkış bağlantıları ve DNS sorguları
Model deposundan olağan dışı indirme
Secret okuma işlemleri ve RBAC değişiklikleri
Restricted profil ihlali nedeniyle reddedilen pod'lar
GPU kullanımında açıklanamayan artış

Son madde hem maliyet hem güvenlik göstergesidir, izinsiz çalışan bir iş yükünü gösterebilir. Yılda en az bir kez bir pod'un ele geçirildiği senaryoyu çalışın. Ağ politikası yatay hareketi durduruyor mu, sırlar hızla döndürülebiliyor mu, model deposuna erişim kayda düşüyor mu? Yanıtlar kuralları doğrular ya da eksikleri gösterir.

Sık Sorulan Sorular

Kubernetes üzerinde LLM servisi güvenliğinde ilk adım nedir?

İlk adım, model servisinin ağdan erişimini daraltmaktır. Ad alanında giriş ve çıkışı varsayılan olarak reddeden bir ağ politikası yazın, sonra yalnız ağ geçidinden gelen trafiğe ve gerekli iç servislere izin verin. Ağ eklentinizin NetworkPolicy desteklediğini doğrulayın, desteklemiyorsa politika etkisiz kalır. Ardından pod yetkilerini düşürün ve sırları korumaya alın.

GPU düğümleri neden ayrı yalıtılmalı?

GPU düğümleri pahalıdır ve çoğu zaman birden fazla iş yükünü taşır. NVIDIA belgelerine göre zaman paylaşımlı GPU kullanımında replikalar arasında bellek ya da hata yalıtımı yoktur, MIG ise donanım düzeyinde yalıtım sağlar. Ayrıca GPU yığınındaki NVIDIA Container Toolkit bileşeninde konteynerden ana makineye erişim sağlayan açıklar yayımlanmıştır. Ayrı havuz ve taint bu riski sınırlar.

Kubernetes Secret nesneleri varsayılan olarak şifreli mi?

Hayır. Kubernetes belgelerine göre Secret nesneleri varsayılan olarak etcd'de şifrelenmeden saklanır. API erişimi olan ya da ad alanında pod oluşturabilen herkes o ad alanındaki Secret'ları okuyabilir. Bu yüzden etcd için bekleme halinde şifrelemeyi açın, Secret erişimini en az yetkili RBAC kurallarıyla sınırlayın ve harici bir sır deposunu değerlendirin.

Çıkış trafiği neden kısıtlanmalı?

Ele geçirilen bir pod ya da istem enjeksiyonuyla yönlendirilen bir ajan, veriyi çıkış trafiği üzerinden dışarı gönderir. Çıkışı yalnız bilinen hedeflere açmak bu yolu kapatır. Standart NetworkPolicy hizmetleri adla hedefleyemez ve engellenen bağlantıları kaydetmez, bu yüzden dış sağlayıcıya çıkış için denetimli bir çıkış vekili ya da ağ geçidi kullanmak daha yönetilebilir olur.

Kaynaklar

İlgili Yazılar

Bu yazı, Türkiye odaklı Yapay Zekâ Güvenliği Rehberi'nin destek makalelerinden biridir.