Örnek sorular
Cse Container Workload SecurityZorluk 1
Bir container image'ı registry'ye push edilmeden önce kriptografik olarak imzalamanın temel güvenlik amacı nedir?
- aTüketicilerin image'ın güvenilir bir yayıncı tarafından üretildiğini ve imzalandıktan sonra değiştirilmediğini doğrulamasını sağlar✓
- bYavaş ağ bağlantılarında pull işlemlerinin daha hızlı tamamlanması için image layer'larını sıkıştırır
- cSon image layer'larındaki bilinen açıklı paketleri otomatik olarak kaldırır
- dImage'ı imza dosyasının içine gömerek container registry ihtiyacını ortadan kaldırır
Açıklama:Image imzalama (ör. cosign/Sigstore veya Notary ile) kriptografik bir imzayı image digest'ine bağlar. Deploy anında bir admission controller bu imzayı güvenilir bir anahtar/identity'ye karşı doğrulayarak provenance ve bütünlüğü kanıtlayabilir; ama sıkıştırma, açık yamalama veya registry'nin yerini alma gibi işlevleri yoktur.
Cse Container Workload SecurityZorluk 1
Bir container image için SBOM (Software Bill of Materials) ne sağlar?
- aImage'a ait pod'ların son 30 günde hangi Kubernetes node'larına schedule edildiğinin kaydını
- bO image'ı çalıştıran herhangi bir pod'a uygulanması gereken CPU ve bellek limitlerini
- cWorkload'ın kullandığı service account'a bağlanmış RBAC rollerinin listesini
- dImage içine gömülü kütüphanelerin, paketlerin ve bunların sürümlerinin yapılandırılmış bir envanterini✓
Açıklama:SBOM, bir image'a gömülmüş her bileşeni (OS paketleri, dil kütüphaneleri, transitive bağımlılıklar) ve sürümlerini listeler. Güvenlik ekiplerinin yeni bir CVE açıklandığında tam olarak neyin etkilendiğini anlamak için açık veritabanlarıyla karşılaştırdığı şey budur; scheduling, kaynak limiti veya RBAC hakkında bir şey söylemez.
Cse Container Workload SecurityZorluk 1
OPA Gatekeeper veya Kyverno gibi bir Kubernetes admission controller'ının güvenlik açısından rolü nedir?
- aHer gece çalışan container dosya sistemlerini tarar ve bir malware imzasıyla eşleşen her dosyayı siler
- bAuthentication/authorization sonrası API server isteklerini yakalar ve nesne kalıcı hale gelmeden önce doğrulayabilir ya da mutate ederek policy zorlar.✓
- cNetwork policy kurallarına göre pod'lar arası trafiği yönlendirmek için kube-proxy'nin yerini alır
- dkubelet'in API server'a authenticate olabilmesi için node'lara TLS sertifikası verir
Açıklama:Admission controller'lar (validating ve mutating webhook'lar), authentication ve authorization'dan sonra ama nesne etcd'ye yazılmadan önce API istek hattında yer alır. OPA Gatekeeper veya Kyverno gibi policy motorları bu hook'u kural zorlamak (ör. privileged: true'yu reddetmek) ya da manifestleri mutate etmek (ör. default değer enjekte etmek) için kullanır. Çalışan dosya sistemi tarayıcısı, network router veya sertifika otoritesi değildir.
Cse Container Workload SecurityZorluk 1
Kubernetes Pod Security Standards üç policy seviyesi tanımlar. En izin verici olandan en kısıtlayıcıya doğru doğru isimlendirme hangisidir?
- aPrivileged, Baseline, Restricted✓
- bBasic, Standard, Premium
- cPublic, Internal, Confidential
- dOpen, Locked, Sealed
Açıklama:Pod Security Standards tam olarak üç seviye tanımlar: Privileged (kısıtsız, güvenilir sistem workload'ları için), Baseline (geniş uyumluluğu korurken bilinen privilege escalation yollarını engeller) ve Restricted (tüm capability'leri düşürmek ve non-root zorunluluğu gibi güncel pod hardening en iyi pratiklerini zorunlu kılar).
Cse Container Workload SecurityZorluk 2
Falco gibi bir runtime container güvenlik aracı temel olarak nasıl çalışır?
- aImage build edilmeden önce Dockerfile'ı statik olarak parse ederek güvensiz base image'ları işaretler
- bRuntime'da kernel seviyesindeki syscall'ları ve container event'lerini izler, kurallarla eşleştirerek anormal davranışları işaretler.✓
- cRegistry'deki ardışık image tag'lerini diff'leyerek beklenmeyen layer değişikliklerini tespit eder
- dÇalışan container'ın process listesini imzalar ve bir transparency log'a attestation olarak gönderir
Açıklama:Falco (ve benzer runtime güvenlik araçları) kernel syscall'larına (eBPF veya kernel modülü üzerinden) ve Kubernetes audit event'lerine erişir, bunları gerçek zamanlı olarak tespit kurallarına karşı değerlendirir -- ör. hiç shell açmayan bir container'da shell açıldığında ya da hassas bir dosya okunduğunda uyarı verir. Bu runtime davranışsal tespittir; statik Dockerfile analizi, registry diff'leme veya attestation imzalama değildir.
Cse Container Workload SecurityZorluk 1
Hassas bir değeri, ek bir kontrol olmadan düz bir Kubernetes Secret nesnesinde saklamak neden tek başına yeterli bir gizlilik koruması değildir?
- aSecret'lar sadece Secret'ın oluşturulduğu node üzerinde çalışan pod'lar tarafından tüketilebilir
- bKubernetes Secret'ları tek yönlü hash ile saklanır, bu yüzden orijinal değer cluster yöneticisi tarafından bile hiçbir zaman geri alınamaz
- cSecret'lar cluster'daki her namespace'e otomatik olarak senkronize edilir, bu yüzden erişimi kısıtlamak imkansızdır
- dSecret'ın değeri varsayılan olarak sadece base64 ile encode edilmiştir; Secret nesnesini okuyabilen herkes bunu kolayca geri çevirebilir.✓
Açıklama:Varsayılan olarak Kubernetes Secret verisi şifrelenmez, sadece base64 ile encode edilir -- encoding hiçbir gizlilik sağlamaz. Secret nesnesine RBAC ile okuma erişimi olan ya da şifrelenmemiş etcd'ye doğrudan erişimi olan herkes anında decode edebilir. Bu yüzden Secret soyutlamasına ek olarak rest'te şifreleme ve RBAC kısıtlamaları (ya da harici bir secret store) gereklidir.