# Container ve Kubernetes Güvenliği Nedir? K8s Security ve Container Hardening Nasıl Yapılır?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/sistem-ve-bulut-guvenligi/container-ve-kubernetes-guvenligi

![Container ve Kubernetes Güvenliği Nedir? K8s Security ve Container Hardening Nasıl Yapılır?](/images/bilgi-merkezi/covers/cover-sistembulut-08.webp)

Modern uygulama mimarilerinde artık her servis ayrı bir fiziksel veya sanal sunucu üzerinde çalışmıyor.

Uygulamalar;

Docker container'ları,

Kubernetes cluster'ları,

managed container platformları,

microservice mimarileri

üzerinde çalışabiliyor.

Bu yaklaşım hız, ölçeklenebilirlik ve otomasyon sağlıyor.

Ancak beraberinde yeni bir saldırı yüzeyi de getiriyor.

Zafiyetli container image.

Root olarak çalışan pod.

Privileged container.

Yanlış Kubernetes RBAC.

Açık Kubernetes API Server.

Hatalı secret yönetimi.

Eksik Network Policy.

Gereğinden fazla cloud IAM yetkisi.

Bunlardan biri bile saldırgan için önemli bir giriş veya privilege escalation noktası olabilir.

Bu nedenle **Container Security** ve **Kubernetes Security**, modern sistem ve bulut güvenliğinin en kritik alanlarından biridir.

Buradaki temel gerçek şudur:

**Managed Kubernetes kullanmak, Kubernetes güvenlik sorumluluğunu ortadan kaldırmaz.**

AWS EKS, Azure AKS veya Google GKE control plane'in bazı parçalarını yönetebilir.

Ancak;

workload,

RBAC,

secret,

container image,

network policy,

runtime security,

cloud permission

gibi birçok alan hâlâ kurumun sorumluluğunda olabilir.

Bu nedenle güçlü bir Kubernetes güvenliği yaklaşımı;

**Secure Image + Least Privilege + RBAC + Network Segmentation + Secret Management + Admission Control + Runtime Security + Logging + Continuous Validation**

katmanlarını birlikte ele almalıdır.

#### Container Security Nedir?

**Container Security**, container image'ın oluşturulmasından production runtime'a kadar geçen tüm yaşam döngüsünün güvenli şekilde yönetilmesini ifade eder.

Bu süreç;

- image security,
- registry security,
- runtime security,
- secret management,
- container privilege,
- network access,
- host interaction,
- vulnerability management

gibi alanları kapsar.

Ama container güvenliği sadece Docker image taramak değildir.

Asıl soru şudur:

#### Bu container compromise olursa saldırgan ne kadar ilerleyebilir?

Eğer container root olarak çalışıyor, host filesystem'e erişiyor ve yüksek yetkili cloud identity kullanıyorsa küçük bir application vulnerability çok büyük etkiye dönüşebilir.

### Kubernetes Security Nedir?

**Kubernetes Security – K8s Security**, Kubernetes cluster içerisindeki;

control plane,

worker node,

pod,

service,

RBAC,

secret,

network,

admission,

runtime

bileşenlerinin güvenli şekilde korunmasıdır.

Kubernetes çok güçlüdür çünkü altyapıyı otomatik yönetir.

Ancak aynı nedenle yanlış yetki de çok hızlı etki oluşturabilir.

Örneğin yanlış role sahip bir kullanıcı;

yeni pod oluşturabilir,

secret okuyabilir,

privileged container çalıştırabilir,

service account token kullanabilir.

Bu nedenle Kubernetes security klasik server hardening'den daha farklı bir güvenlik modeli gerektirir.

### Docker Security Nedir?

Docker veya benzeri container runtime'larda güvenlik birkaç temel alanda değerlendirilir.

Bunlar arasında;

image source,

container user,

Linux capabilities,

mount edilen filesystem,

host network,

runtime permission

bulunabilir.

Container isolation güçlü olabilir.

Ancak tam bir sanal makine izolasyonu gibi düşünülmemelidir.

Host kernel birçok container tarafından paylaşılabilir.

Bu nedenle kernel ve runtime güvenliği önemlidir.

### Container Image Nedir?

**Container Image**, uygulamanın çalışması için gereken;

uygulama kodu,

library,

dependency,

runtime

bileşenlerini içeren paketlenmiş yapıdır.

Production container bu image üzerinden oluşturulur.

Bu nedenle image güvenliği supply chain güvenliğinin başlangıç noktalarından biridir.

### Container Image İçinde Güvenlik Açığı Olabilir mi?

Evet.

Image içerisinde;

eski OpenSSL,

zafiyetli Java library,

eski Linux package,

güvenlik açığı bulunan framework

bulunabilir.

Application kodu tamamen güvenli olsa bile base image zafiyetli olabilir.

Bu nedenle container image'ları düzenli olarak vulnerability scan'den geçirilmelidir.

### Image Scanning Nedir?

**Container Image Scanning**, image içerisindeki paket ve dependency'lerin bilinen güvenlik açıklarına karşı analiz edilmesidir.

Örneğin scan sonucu;

Critical CVE,

High CVE,

outdated package

tespit edilebilir.

Ancak yalnızca CVE sayısına bakmak yeterli değildir.

Container'ın production exposure ve privilege seviyesi de değerlendirilmelidir.

### Critical CVE Her Zaman Critical Risk midir?

Hayır.

Örneğin image içerisinde kritik CVE var.

Ancak vulnerable binary hiç çalışmıyor olabilir.

Başka bir container'da orta seviyeli CVE vardır ancak;

internet-facing,

root,

privileged

olarak çalışıyordur.

Gerçek risk ikinci durumda daha yüksek olabilir.

Bu nedenle risk tabanlı container vulnerability management gerekir.

### Base Image Nedir?

Container image genellikle başka bir base image üzerine inşa edilir.

Örneğin;

Ubuntu,

Alpine,

Debian,

distroless

gibi.

Base image güvenliği önemlidir çünkü inherited vulnerability'ler doğrudan uygulamaya taşınabilir.

Bu nedenle minimal base image tercih edilebilir.

### Minimal Image Neden Daha Güvenli Olabilir?

Image içerisinde ne kadar az paket varsa saldırı yüzeyi o kadar küçük olabilir.

Örneğin production container içinde;

compiler,

package manager,

debug tool,

shell

gerekli olmayabilir.

Bu bileşenlerin kaldırılması saldırganın compromise sonrası kullanabileceği araçları azaltabilir.

### Distroless Image Nedir?

**Distroless Image**, yalnızca uygulamanın çalışması için gereken minimum runtime bileşenlerini içeren image yaklaşımıdır.

Shell veya package manager gibi araçlar bulunmayabilir.

Bu durum saldırı yüzeyini azaltabilir.

Ancak operasyonel troubleshooting'i zorlaştırabilir.

Bu nedenle kurumun operasyon modeliyle birlikte değerlendirilmelidir.

### Container Root Olarak Çalışırsa Ne Olur?

Birçok container varsayılan olarak root user ile çalışabilir.

Bu durum container içinde compromise olduğunda saldırganın daha fazla yetkiye sahip olmasına neden olabilir.

Bu nedenle mümkünse container:

**non-root user**

ile çalıştırılmalıdır.

Ama USER directive eklemek tek başına yeterli değildir.

Runtime privilege'lar da kontrol edilmelidir.

### RunAsNonRoot Nedir?

Kubernetes pod security context içerisinde container'ın root kullanıcı olarak çalışmasını engellemeye yardımcı olan kontrol mekanizmalarından biridir.

Örneğin:

**runAsNonRoot: true**

benzeri policy uygulanabilir.

Bu güvenli container baseline'ın önemli parçalarından biridir.

### Privileged Container Nedir?

**Privileged Container**, host üzerinde çok geniş yetkilere sahip şekilde çalışan container'dır.

Bu durumda container isolation önemli ölçüde azalabilir.

Privileged container;

device,

kernel capability,

host resource

erişimlerinde geniş yetkiye sahip olabilir.

Bu nedenle yalnızca zorunlu kullanım durumlarında izin verilmelidir.

### Privileged Container Neden Kritik Risk?

Bir application vulnerability üzerinden container compromise edildiğini düşünelim.

Normal container'da saldırganın hareket alanı sınırlı olabilir.

Ancak privileged container ise host'a erişim veya container escape riski çok daha yüksek olabilir.

Bu nedenle:

#### Internet-facing + Privileged Container

kombinasyonu özellikle kritik değerlendirilmelidir.

### Container Escape Nedir?

**Container Escape**, saldırganın container isolation sınırlarını aşarak host işletim sistemine erişmeye çalıştığı saldırı türüdür.

Bu;

container runtime vulnerability,

kernel vulnerability,

dangerous capability,

privileged mode

gibi faktörlerle ilişkili olabilir.

Host erişimi elde edilirse aynı node üzerindeki diğer workload'lar da risk altında olabilir.

### Linux Capabilities Nedir?

Linux root yetkileri farklı capability'lere bölünebilir.

Örneğin;

NET_ADMIN,

SYS_ADMIN

gibi.

Container'a sadece gerekli capability'ler verilmelidir.

Özellikle **SYS_ADMIN** çok geniş yetkilere sahip olduğu için dikkatli değerlendirilmelidir.

### Drop All Capabilities Yaklaşımı Nedir?

Güvenli container configuration'da bütün capability'ler varsayılan olarak kaldırılıp yalnızca gerekenler tekrar eklenebilir.

Bu yaklaşım:

#### Default Deny

mantığına yakındır.

Ama application compatibility test edilmelidir.

### Read-Only Root Filesystem Nedir?

Container'ın root filesystem'inin sadece okunabilir çalışması, saldırganın container içerisinde kalıcı dosya bırakmasını zorlaştırabilir.

Uygulamanın yazması gereken dizinler ayrı writable volume olarak tanımlanabilir.

Bu özellikle immutable infrastructure yaklaşımıyla uyumludur.

### Container İçinde Secret Saklanmalı mı?

Container image içerisine kesinlikle kalıcı secret gömülmemelidir.

Örneğin;

database password,

API key,

private key

image layer içerisinde bulunabilir.

Image registry'ye gönderildiğinde secret da dağıtılmış olur.

Silinse bile eski layer içinde kalabilir.

Bu nedenle secret runtime sırasında güvenli kaynaktan alınmalıdır.

### Dockerfile İçinde Secret Yazmak Neden Riskli?

Örneğin build sırasında:

ENV DB_PASSWORD=...

gibi yaklaşım kullanılırsa secret image metadata veya layer içerisinde kalabilir.

Bu nedenle build secret mekanizmaları ve secret vault kullanılmalıdır.

### Container Registry Nedir?

Container image'ların saklandığı platformdur.

Örneğin;

AWS ECR,

Azure Container Registry,

Google Artifact Registry,

Harbor

gibi.

Registry güvenliği supply chain security'nin önemli parçasıdır.

### Container Registry Nasıl Korunur?

Şu kontroller değerlendirilebilir:

Authentication.

Least Privilege.

Private registry.

Image scanning.

Image signing.

Immutable tag.

Audit logging.

Amaç saldırganın kötü amaçlı image yüklemesini veya production image'ı değiştirmesini zorlaştırmaktır.

### Public Container Registry Riskli midir?

Public image kullanmak her zaman yanlış değildir.

Ancak production için kullanılan image'ların kaynağı doğrulanmalıdır.

Saldırgan;

benzer isimli malicious image,

typosquatting package,

compromised upstream image

kullanabilir.

Bu nedenle trusted registry ve image provenance önemlidir.

### Image Signing Nedir?

**Image Signing**, container image'ın güvenilir bir kaynak tarafından üretildiğini cryptographic olarak doğrulamaya yardımcı olur.

Deployment sırasında yalnızca imzalı image'ların çalıştırılması policy ile zorunlu hale getirilebilir.

Bu supply chain saldırılarını azaltabilir.

### Software Supply Chain Security Container'da Neden Önemli?

Container image birçok bileşenden oluşur.

Base image.

OS package.

Application dependency.

Build tool.

CI/CD pipeline.

Bu zincirin herhangi bir noktası compromise olabilir.

Bu nedenle container security sadece runtime security değildir.

**Build-to-Run Security** olarak düşünülmelidir.

### SBOM Nedir?

**Software Bill of Materials – SBOM**, yazılımın hangi bileşenlerden oluştuğunu gösteren envanterdir.

Container image için;

paketler,

library'ler,

dependency'ler

listelenebilir.

Yeni güvenlik açığı çıktığında hangi image'ların etkilendiğini hızlı şekilde anlamaya yardımcı olur.

### Kubernetes Cluster Nedir?

Kubernetes cluster genel olarak;

control plane,

worker node

yapısından oluşur.

Control plane cluster yönetimini gerçekleştirir.

Worker node'lar application pod'larını çalıştırır.

Her iki katmanın güvenliği farklıdır.

### Kubernetes Control Plane Nedir?

Control plane;

API Server,

Scheduler,

Controller Manager,

etcd

gibi kritik bileşenleri içerir.

Cluster'ın yönetim beynidir.

Control plane compromise edilirse cluster üzerindeki çok sayıda workload kontrol edilebilir.

Bu nedenle control plane erişimi son derece sınırlı olmalıdır.

### Kubernetes API Server Neden Kritik?

Kubernetes üzerindeki yönetim işlemlerinin büyük bölümü API Server üzerinden yapılır.

Kullanıcı;

pod oluşturur,

secret okur,

deployment değiştirir,

role atar

gibi işlemleri API üzerinden gerçekleştirir.

Bu nedenle API Server doğrudan internetten gereksiz yere erişilebilir olmamalıdır.

### Kubernetes API Server Public Olabilir mi?

Bazı managed Kubernetes yapılarında public endpoint bulunabilir.

Ancak bu durumda;

source IP restriction,

strong authentication,

RBAC,

MFA/SSO,

audit logging

gibi kontroller önemlidir.

Mümkün olan mimarilerde private control plane access değerlendirilebilir.

### Anonymous Kubernetes Access Nedir?

API Server authentication olmadan bazı request'leri kabul ediyorsa anonymous access riski oluşabilir.

Production cluster'da anonymous permission'lar son derece sınırlı olmalıdır.

Özellikle public API endpoint ile birleştiğinde kritik risk oluşturabilir.

### Kubernetes RBAC Nedir?

**Role-Based Access Control – RBAC**, Kubernetes içerisindeki kullanıcı ve service account'ların hangi kaynaklarda hangi işlemleri yapabileceğini belirler.

Örneğin bir kullanıcı;

pod görüntüleyebilir,

ama delete edemez.

Başka kullanıcı namespace administrator olabilir.

RBAC Kubernetes güvenliğinin temel bileşenidir.

### Kubernetes Role ile ClusterRole Arasındaki Fark

#### Role

Belirli namespace içerisinde yetki sağlayabilir.

#### ClusterRole

Cluster genelindeki kaynaklara veya birden fazla namespace'e uygulanabilir.

Bu nedenle ClusterRole permission'ları daha dikkatli yönetilmelidir.

### Cluster-Admin Neden Risklidir?

**cluster-admin** Kubernetes üzerinde çok geniş privilege sağlar.

Developer veya application service account'larına kolaylık amacıyla cluster-admin verilmesi ciddi risk oluşturur.

Minimum privilege uygulanmalıdır.

### Wildcard RBAC Neden Risklidir?

Örneğin role içerisinde:

resources: *

verbs: *

kullanımı çok geniş yetki verebilir.

Bu configuration hızla privilege escalation riskine dönüşebilir.

Ama her wildcard otomatik kritik değildir.

Scope ve identity bağlamında değerlendirilmelidir.

### Service Account Kubernetes'te Nedir?

Pod'lar Kubernetes API ile iletişim kurmak için service account kullanabilir.

Bu identity'nin token'ı pod içinde bulunabilir.

Eğer application compromise edilirse saldırgan service account token'a erişmeye çalışabilir.

Bu nedenle pod service account permission'ları minimum tutulmalıdır.

### Default Service Account Neden Riskli Olabilir?

Birçok workload varsayılan service account ile çalışabilir.

Bu hesap gereksiz permission alırsa çok sayıda pod aynı yetkiye sahip olur.

Bu nedenle kritik workload'lar için özel service account oluşturulması ve minimum RBAC uygulanması tercih edilebilir.

### Service Account Token Nedir?

Kubernetes service account token, pod'un API Server'a kimlik doğrulaması yapmasına yardımcı olabilir.

Bu token'ın güvenliği önemlidir.

Pod'un API erişimine ihtiyacı yoksa token mount edilmemesi düşünülebilir.

**automountServiceAccountToken Nedir?**

Pod'a service account token'ın otomatik mount edilmesini kontrol eder.

Application Kubernetes API kullanmıyorsa token'a ihtiyacı olmayabilir.

Token'ın gereksiz şekilde container içinde bulunması saldırgan için credential exposure oluşturabilir.

### Kubernetes Secrets Nedir?

Kubernetes Secrets;

password,

API key,

certificate,

token

gibi hassas verileri saklamak için kullanılabilir.

Ancak isim “Secret” olduğu için otomatik olarak yüksek güvenlikli kabul edilmemelidir.

Access control ve encryption konfigürasyonu ayrıca önemlidir.

### Kubernetes Secrets Base64 ile Güvenli mi?

Base64 encoding şifreleme değildir.

Secret değeri yalnızca encode edilmiş olabilir.

RBAC yetkisi olan kullanıcı secret'ı okuyabilir.

Bu nedenle Secrets için;

encryption at rest,

RBAC,

external secret manager

değerlendirilebilir.

### External Secret Manager Nedir?

Kubernetes secret'larının doğrudan cluster içinde tutulması yerine;

AWS Secrets Manager,

Azure Key Vault,

Google Secret Manager,

HashiCorp Vault

gibi sistemlerden runtime sırasında alınması yaklaşımıdır.

Bu model secret lifecycle ve rotation açısından daha güçlü olabilir.

**etcd Nedir?**

**etcd**, Kubernetes cluster'ın kritik state verisini tutan dağıtık key-value store'dur.

Secret ve configuration bilgileri burada saklanabilir.

Bu nedenle etcd son derece kritik varlıktır.

Erişimi ve encryption'ı güçlü şekilde korunmalıdır.

**etcd İnternete Açık Olabilir mi?**

Production ortamında doğrudan public exposure ciddi risk oluşturabilir.

etcd yalnızca control plane bileşenleri tarafından erişilebilir olmalıdır.

Network ve authentication kontrolleri uygulanmalıdır.

### Kubernetes Network Policy Nedir?

**Network Policy**, pod'ların hangi pod veya network kaynaklarıyla iletişim kurabileceğini sınırlamaya yardımcı olur.

Varsayılan olarak birçok cluster'da pod'lar birbirleriyle geniş iletişim kurabilir.

Bu lateral movement riskini artırabilir.

### Default Deny Network Policy Nedir?

Tüm pod trafiği varsayılan olarak kapatılır.

Yalnızca gerekli iletişim yolları explicit olarak açılır.

Bu yaklaşım:

#### Zero Trust Networking

mantığına daha yakındır.

Ama uygulama dependency'leri doğru bilinmelidir.

### Kubernetes'te Mikro Segmentasyon Nasıl Yapılır?

Namespace,

label,

Network Policy,

service mesh

gibi mekanizmalarla workload iletişimleri sınırlandırılabilir.

Örneğin:

Frontend yalnızca API'ye.

API yalnızca database'e.

Developer pod'ları production database'e erişemez.

Bu model lateral movement'i azaltır.

### HostNetwork Nedir?

Pod'un host network namespace'ini kullanmasına izin veren konfigürasyondur.

Bu durumda pod doğrudan node network'üne daha yakın erişim kazanabilir.

Gerekli olmadığı sürece kullanılmamalıdır.

### HostPath Nedir?

**hostPath**, host üzerindeki filesystem dizininin container içine mount edilmesini sağlar.

Bu güçlü ama riskli bir özelliktir.

Örneğin container'a:

/

veya

/var/run/docker.sock

gibi kritik host path'ler mount edilirse container compromise host compromise'a dönüşebilir.

### Docker Socket Mount Neden Kritik?

/var/run/docker.sock container'a mount edilirse container Docker daemon üzerinde geniş kontrol elde edebilir.

Bu durum host üzerinde yeni privileged container oluşturma gibi ciddi riskler doğurabilir.

Bu nedenle production workload'larda son derece dikkatli kullanılmalıdır.

### Kubernetes Security Context Nedir?

Pod veya container'ın;

user,

group,

capability,

privilege,

filesystem

gibi güvenlik özelliklerini tanımlar.

Güvenli security context container hardening'in temelidir.

**allowPrivilegeEscalation Nedir?**

Container process'inin mevcut yetkisinden daha yüksek privilege kazanmasını engellemeye yardımcı olan security setting'dir.

Gerekli olmadığı sürece:

**allowPrivilegeEscalation: false**

yaklaşımı tercih edilebilir.

### Seccomp Nedir?

**seccomp**, Linux system call'larını sınırlandırmaya yardımcı olan güvenlik mekanizmasıdır.

Container'ın kullanmasına gerek olmayan system call'lar engellenebilir.

Bu container escape ve exploit etkisini azaltan defense-in-depth kontrolüdür.

### AppArmor ve SELinux Container Güvenliğinde Kullanılır mı?

Evet.

AppArmor ve SELinux gibi Mandatory Access Control mekanizmaları container workload'larının host üzerindeki erişimlerini sınırlandırmaya yardımcı olabilir.

Ancak doğru policy oluşturmak operasyonel uzmanlık gerektirir.

### Pod Security Standards Nedir?

Kubernetes, workload'ların güvenlik seviyelerini tanımlamak için Pod Security Standards yaklaşımını kullanır.

Genel olarak;

Privileged,

Baseline,

Restricted

gibi profiller düşünülebilir.

Production workload'lar için mümkün olduğunca daha sıkı profil tercih edilebilir.

### Pod Security Admission Nedir?

**Pod Security Admission**, pod oluşturulurken belirli Pod Security Standards kurallarının uygulanmasını sağlar.

Örneğin privileged pod veya root container deployment'ı engellenebilir.

Bu preventive security kontrolüdür.

### Admission Controller Nedir?

Kubernetes API request'i kabul edilmeden önce policy uygulayan mekanizmadır.

Örneğin;

unsigned image yasak,

privileged pod yasak,

resource limit zorunlu,

belirli registry dışında image yasak

gibi kontroller uygulanabilir.

Bu sayede güvenlik production'a çıkmadan enforce edilir.

### OPA Gatekeeper Nedir?

**Open Policy Agent – OPA** ve Gatekeeper, Kubernetes üzerinde policy-as-code yaklaşımıyla admission policy uygulamak için kullanılabilir.

Örneğin:

“Production namespace'te root container çalışamaz.”

gibi policy oluşturulabilir.

Bu cloud-native DevSecOps güvenliği açısından değerlidir.

### Kyverno Nedir?

Kyverno, Kubernetes için policy engine olarak kullanılan araçlardan biridir.

Policy'ler Kubernetes native manifest yapısına yakın şekilde tanımlanabilir.

Security teams;

validate,

mutate,

generate

politikaları oluşturabilir.

Ama araçtan daha önemli olan doğru policy tasarımıdır.

### Admission Policy ile CSPM Arasındaki Fark

Admission Policy:

Riskli workload daha oluşmadan engeller.

CSPM/KSPM:

Mevcut cluster configuration'ındaki riskleri tespit eder.

İdeal model:

#### Prevent + Detect

şeklinde ikisini birlikte kullanır.

### KSPM Nedir?

**Kubernetes Security Posture Management – KSPM**, Kubernetes cluster'larının güvenlik konfigürasyonlarını sürekli değerlendiren yaklaşımı ifade eder.

Örneğin;

privileged pod,

open API server,

weak RBAC,

missing Network Policy,

hostPath usage

tespit edilebilir.

KSPM, CSPM'in Kubernetes'e odaklanan uzantısı gibi düşünülebilir.

### CIS Kubernetes Benchmark Nedir?

CIS Kubernetes Benchmark, cluster ve node yapılandırmaları için güvenlik önerileri sunar.

Örneğin;

API Server,

Scheduler,

Controller Manager,

etcd,

worker node

konfigürasyonları değerlendirilir.

Managed Kubernetes servislerinde bazı kontroller provider sorumluluğunda olabilir.

Bu nedenle benchmark platforma göre yorumlanmalıdır.

### EKS Security Nedir?

**Amazon Elastic Kubernetes Service – EKS** üzerinde AWS control plane'in belirli bölümlerini yönetir.

Ancak müşteri;

IAM integration,

RBAC,

node,

pod,

network,

secret,

image

güvenliğinden sorumlu olabilir.

Bu nedenle “managed cluster” güvenlik sorumluluğunu kaldırmaz.

### AKS Security Nedir?

**Azure Kubernetes Service – AKS**, Microsoft Azure'un managed Kubernetes servisidir.

AKS güvenliğinde;

Entra integration,

Azure RBAC,

Network Policy,

Key Vault,

container registry,

Defender/runtime security

gibi alanlar önemlidir.

Identity ile Kubernetes RBAC birlikte doğru tasarlanmalıdır.

### GKE Security Nedir?

**Google Kubernetes Engine – GKE** managed Kubernetes platformudur.

GKE ortamında;

IAM,

Workload Identity,

private cluster,

network policy,

binary authorization,

secret management

gibi kontroller değerlendirilebilir.

Temel güvenlik prensipleri diğer managed Kubernetes servisleriyle benzerdir.

### Managed Kubernetes Kullanmak Güvenli midir?

Managed Kubernetes, control plane patching ve availability gibi alanlarda önemli avantaj sağlar.

Ancak şu hatalar yine müşteriden kaynaklanabilir:

cluster-admin fazla kullanıcı,

public API endpoint,

privileged pod,

open network,

weak secret management,

vulnerable image.

Bu nedenle Shared Responsibility Model burada da geçerlidir.

### Kubernetes Node Security Nedir?

Worker node'lar container workload'larını çalıştırır.

Node compromise edilirse aynı node üzerindeki birçok pod etkilenebilir.

Bu nedenle node'larda;

OS patch,

minimal package,

EDR/runtime sensor,

network restriction,

SSH control

uygulanmalıdır.

### Node'a SSH Erişimi Gerekli mi?

Managed cluster'larda mümkün olduğunca node'ların manuel yönetimi azaltılabilir.

SSH gerekiyorsa;

private network,

Bastion,

JIT,

MFA/PAM

ile kontrol edilmelidir.

Node'un doğrudan internete açık olması gereksiz risk oluşturabilir.

### Immutable Node Nedir?

Node üzerinde manuel değişiklik yapmak yerine yeni güvenli image'dan node oluşturup eskisini kaldırma yaklaşımıdır.

Bu **Immutable Infrastructure** modelidir.

Configuration drift'i azaltabilir.

### Kubernetes Patch Management Nasıl Yapılır?

Kubernetes güvenliği birkaç farklı patch katmanı içerir:

Cluster version.

Node operating system.

Container image.

Application dependency.

Bu katmanların tamamı ayrı lifecycle'a sahiptir.

Bu nedenle patch management merkezi görünürlük gerektirir.

### Kubernetes Version Güncel Tutulmalı mı?

Evet.

Eski Kubernetes sürümleri;

security fix,

support,

compatibility

açısından risk oluşturabilir.

Managed provider'ın desteklediği sürüm takvimi takip edilmelidir.

Ancak upgrade öncesinde application compatibility test edilmelidir.

### Container Runtime Security Nedir?

Runtime security, container production'da çalışırken oluşan davranışları izler.

Örneğin;

beklenmeyen shell açılması,

new process,

sensitive file access,

network connection,

privilege escalation

tespit edilebilir.

Bu nedenle image scan ile runtime security birbirini tamamlar.

### Runtime Detection Neden Gereklidir?

Image tamamen temiz olabilir.

Ancak application vulnerability üzerinden saldırgan runtime sırasında komut çalıştırabilir.

Image scan bunu göremez.

Runtime detection gerçek çalışma davranışını izler.

**eBPF Container Security'de Nasıl Kullanılır?**

**eBPF**, Linux kernel seviyesinde düşük seviyeli telemetry elde etmek için kullanılabilen teknolojidir.

Cloud-native security platformları;

process,

network,

system call

davranışlarını gözlemlemek için eBPF kullanabilir.

Container runtime detection açısından güçlü görünürlük sağlayabilir.

### Kubernetes EDR Var mı?

Geleneksel EDR ajanları bazı node'larda kullanılabilir.

Ancak container dünyasında workload ve runtime davranışı için cloud-native security çözümleri gerekebilir.

Bu nedenle:

**EDR + CWPP + Kubernetes Runtime Security**

birlikte değerlendirilebilir.

### CWPP Kubernetes'te Ne İşe Yarar?

**Cloud Workload Protection Platform – CWPP**, container ve Kubernetes workload'larında;

vulnerability,

runtime behavior,

malware,

configuration

risklerini izleyebilir.

CSPM cloud config'e bakarken CWPP workload davranışına odaklanır.

### CNAPP Kubernetes Güvenliğini Nasıl Kapsar?

Modern CNAPP platformları;

CSPM,

KSPM,

CWPP,

CIEM,

container image security,

IaC scanning

özelliklerini bir araya getirebilir.

Örneğin:

Public Kubernetes Service

Vulnerable Pod

Privileged Container

High-Privilege Cloud Identity

tek attack path olarak gösterilebilir.

### Kubernetes ve Cloud IAM Nasıl Birleşir?

Managed Kubernetes ortamlarında pod'lar cloud servislerine erişebilir.

Örneğin pod;

S3,

Key Vault,

Cloud Storage

kullanabilir.

Bu nedenle Kubernetes service identity ile cloud IAM arasında ilişki vardır.

Yanlış tasarımda pod compromise cloud account compromise'a dönüşebilir.

### Workload Identity Neden Önemlidir?

Pod içerisine static cloud access key koymak yerine workload identity mekanizması kullanılabilir.

Bu sayede;

short-lived credential,

identity binding,

minimum permission

sağlanabilir.

Bu secret exposure riskini azaltır.

### Kubernetes Attack Path Nedir?

Saldırganın düşük yetkili pod veya kullanıcıdan kritik cluster/cloud yetkisine ilerlediği zincirdir.

Örneğin:

Internet-facing Application

↓

RCE

↓

Pod

↓

Service Account Token

↓

Kubernetes Secret Access

↓

Cloud Credential

↓

Production Database

Bu zincir tek tek bulgulardan çok daha değerlidir.

### Kubernetes Lateral Movement Nasıl Gerçekleşir?

Saldırgan bir pod'u ele geçirdikten sonra;

diğer pod'lara,

service'lere,

node'a,

API Server'a,

cloud metadata'ya

erişim arayabilir.

Network Policy ve Least Privilege bu hareketi sınırlandırır.

### Namespace Security Boundary midir?

Namespace organizasyon ve bazı access control işlemleri sağlar.

Ancak tek başına güçlü security boundary olarak düşünülmemelidir.

Özellikle cluster-level RBAC ve shared node yapıları nedeniyle ek kontroller gerekir.

### Multi-Tenant Kubernetes Neden Risklidir?

Farklı ekip veya müşteriler aynı cluster'ı kullanıyorsa isolation kritik hale gelir.

RBAC,

Network Policy,

Pod Security,

Resource Quota

dikkatli tasarlanmalıdır.

Yüksek riskli multi-tenant yapılarda ayrı cluster kullanımı değerlendirilebilir.

### Resource Quota Güvenlikle İlgili mi?

Evet.

Bir namespace veya workload tüm CPU ve memory kaynaklarını tüketirse diğer servisleri etkileyebilir.

ResourceQuota ve Limits availability güvenliğine katkı sağlar.

DoS etkisini azaltabilir.

### CPU ve Memory Limit Neden Önemlidir?

Container'a sınırsız resource bırakmak noisy neighbor veya application bug durumunda cluster kapasitesini etkileyebilir.

Bu nedenle requests ve limits tanımlanmalıdır.

Ancak çok düşük limit de application availability'yi bozabilir.

### Kubernetes DoS Riski

Bir attacker veya kötü yapılandırılmış workload;

çok sayıda pod,

yüksek CPU,

yüksek memory

oluşturabilir.

Bu nedenle quota ve admission policy availability güvenliği için önemlidir.

### Kubernetes Audit Logs Neden Gereklidir?

API Server üzerinden gerçekleştirilen kritik işlemler audit loglarda görülebilir.

Örneğin;

secret read,

role assignment,

pod creation,

exec command,

config change

izlenebilir.

Incident Response için kritik veri kaynağıdır.

**kubectl exec Neden İzlenmelidir?**

kubectl exec, çalışan pod içerisinde komut çalıştırmaya izin verebilir.

Bu meşru troubleshooting için kullanılır.

Ancak saldırgan veya insider tarafından kötüye kullanılabilir.

Production ortamında exec aktiviteleri loglanmalı ve gerekirse sınırlandırılmalıdır.

### Kubernetes Secret Okunması Alarm Üretmeli mi?

Her secret read saldırı değildir.

Application'lar normal olarak secret kullanabilir.

Ancak human admin'in çok sayıda secret okuması veya beklenmeyen service account aktivitesi anomali olabilir.

Behavior-based monitoring değerlidir.

### Kubernetes SIEM Entegrasyonu Nasıl Yapılır?

SIEM'e;

Kubernetes Audit Logs,

node logs,

container runtime logs,

cloud IAM logs,

WAF/API logs

gönderilebilir.

Örneğin:

WAF → exploit attempt.

Runtime → shell opened.

Kubernetes → secret read.

Cloud IAM → storage access.

Bu olaylar tek saldırı zinciri olarak korele edilebilir.

### Kubernetes Threat Hunting Nedir?

Cluster telemetry üzerinde geçmiş saldırı davranışlarının aranmasıdır.

Örneğin hipotez:

**“Compromised pod üzerinden service account token kullanılmış olabilir.”**

Audit loglarda;

token activity,

secret access,

unexpected API calls

aranabilir.

### Kubernetes Incident Response Nasıl Yapılır?

Bir pod compromise olduğunda sadece pod'u silmek yeterli olmayabilir.

Kontrol edilmesi gerekenler:

Pod hangi service account'u kullanıyordu?

Hangi secret'lara erişti?

Hangi node üzerinde çalıştı?

Cloud IAM permission'ı var mıydı?

Başka pod'larla iletişim kurdu mu?

Image güvenilir miydi?

Bu nedenle containment ile investigation birlikte yürütülmelidir.

### Compromised Pod Silinmeli mi?

Gerekebilir.

Ancak forensic evidence kaybolabilir.

Önce;

logs,

container state,

network connection,

node telemetry

toplanması değerlendirilebilir.

Incident Response planı önceden hazırlanmalıdır.

### Ephemeral Container Forensics Neden Zor?

Container'lar kısa ömürlüdür.

Pod silindiğinde filesystem ve runtime evidence kaybolabilir.

Bu nedenle merkezi logging ve runtime telemetry son derece önemlidir.

Cloud-native forensics klasik disk imaging'den farklıdır.

### Kubernetes Backup Güvenliği

Cluster configuration ve persistent data backup edilmelidir.

Ancak backup içerisinde;

secret,

application configuration,

sensitive data

bulunabilir.

Backup erişimi ayrıca korunmalıdır.

**etcd Backup Neden Kritik?**

Self-managed cluster'larda etcd backup cluster state recovery için önemli olabilir.

Ancak etcd backup hassas credential ve secret içerebilir.

Şifreleme ve access control uygulanmalıdır.

### Disaster Recovery Kubernetes'te Nasıl Planlanır?

Kubernetes cluster yeniden oluşturulabilir.

Ama application data, secret ve configuration'ın nasıl geri döneceği planlanmalıdır.

Infrastructure as Code ve GitOps recovery sürecini hızlandırabilir.

### GitOps Nedir?

**GitOps**, Kubernetes configuration'ın source of truth olarak Git repository üzerinden yönetilmesidir.

Cluster config değişiklikleri code review ve version control ile yapılabilir.

Bu configuration drift'i azaltabilir.

Ancak Git repository ve CI/CD pipeline'ın kendisi yüksek değerli güvenlik hedefi haline gelir.

### GitOps Supply Chain Riski

Saldırgan Git repository'yi ele geçirirse production manifest'ini değiştirebilir.

Örneğin malicious image veya privileged pod ekleyebilir.

Bu nedenle;

branch protection,

signed commit,

code review,

CI/CD security

önemlidir.

### CI/CD Pipeline Kubernetes Güvenliğinde Neden Kritiktir?

Pipeline genellikle production cluster'a deployment yetkisine sahiptir.

Bu credential ele geçirilirse saldırgan doğrudan workload deploy edebilir.

Bu nedenle CI/CD identity minimum yetkili olmalı ve secret'lar sıkı korunmalıdır.

### Kubernetes Secret CI/CD Loglarına Sızabilir mi?

Evet.

Yanlış pipeline configuration secret değerini console log'a yazabilir.

Bu nedenle log masking ve secret scanning önemlidir.

Ayrıca uzun ömürlü cluster admin token pipeline içinde tutulmamalıdır.

### Image Tag Olarak “latest” Kullanmak Riskli mi?

latest değişken bir tag olabilir.

Bugün aynı tag başka image'a işaret edebilir.

Bu deployment reproducibility ve supply chain güvenliğini azaltabilir.

Digest veya immutable version tag kullanımı daha kontrollü olabilir.

### Image Digest Nedir?

Image'ın cryptographic hash değeridir.

Deployment belirli digest'e bağlanırsa aynı image'ın çalıştırıldığı daha güvenli şekilde doğrulanabilir.

Bu supply chain integrity için değerlidir.

### Admission Control ile Image Policy Nasıl Uygulanır?

Örneğin policy:

Sadece kurumsal registry.

Sadece signed image.

Critical CVE içeren image deploy edilemez.

latest tag yasak.

Bu şekilde image security production deployment noktasında enforce edilir.

### Vulnerability Fix Yoksa Image Deploy Edilebilir mi?

Risk bazlı istisna süreci olabilir.

Örneğin;

CVE application path'inde değil,

compensating control var,

vendor fix yayınlamadı.

Bu durumda risk owner onayıyla exception verilebilir.

Ancak süreli ve izlenebilir olmalıdır.

### Exception Management Nedir?

Security policy'ye geçici istisna verilmesi sürecidir.

Örneğin application privileged container gerektiriyor olabilir.

İstisna için;

business justification,

owner,

expiry date,

compensating control

tanımlanmalıdır.

Süresiz exception güvenlik açığına dönüşebilir.

### Kubernetes Security Assessment Nedir?

**Kubernetes Security Assessment**, cluster'ın;

architecture,

RBAC,

network,

secret,

workload,

node,

logging,

runtime

güvenlik seviyesinin sistematik değerlendirilmesidir.

Bu çalışma sadece CVE scan değildir.

Configuration ve privilege ilişkileri daha önemlidir.

### Kubernetes Security Assessment Nasıl Yapılır?

Genel akış şu şekilde olabilir:

#### \1. Cluster Architecture Review

Managed/self-managed yapı.

#### \2. API Exposure

Control plane erişimi.

#### \3. RBAC Analysis

Kullanıcı ve service account permission'ları.

#### \4. Workload Security

Root, privileged, capabilities.

#### \5. Network Policy

Pod communication.

#### \6. Secret Management

Credential güvenliği.

#### \7. Image Security

Vulnerability ve registry kontrolleri.

#### \8. Runtime Security

Detection coverage.

#### \9. Logging

Audit ve SIEM entegrasyonu.

#### \10. Attack Path Analysis

Pod'dan cluster/cloud'a geçiş yolları.

Bu yaklaşım gerçek risk görünümü sağlar.

### Kubernetes Pentest ile Security Assessment Arasındaki Fark

#### Security Assessment

Konfigürasyon ve posture'u analiz eder.

#### Kubernetes Penetration Test

Yetkilendirilmiş saldırı teknikleriyle bu hataların ne kadar istismar edilebilir olduğunu test eder.

Örneğin assessment:

overprivileged service account bulur.

Pentest:

bu account üzerinden secret veya cloud resource erişimi mümkün mü?

sorusunu doğrular.

### Container Security Assessment Nedir?

Image,

Dockerfile,

registry,

runtime,

privilege,

secret

alanlarının güvenlik değerlendirmesidir.

Kubernetes kullanmayan container platformlarında da uygulanabilir.

### CIS Docker Benchmark Nedir?

Docker host ve container configuration için güvenlik önerileri sağlar.

Örneğin;

daemon,

filesystem,

logging,

container privilege

gibi alanları kapsayabilir.

Ancak modern managed container ortamlarında bütün maddeler birebir uygulanamayabilir.

### Kubernetes Security KPI'ları Nelerdir?

Örnek metrikler:

#### Privileged Container Count

#### Root Container Percentage

#### Cluster-Admin User Count

#### Overprivileged Service Account Count

#### Critical Image Vulnerability Count

#### Public API Endpoint Count

#### Network Policy Coverage

#### Unsigned Image Count

#### Runtime Detection Coverage

#### Audit Logging Coverage

Bu metrikler güvenlik posture'un zaman içerisinde izlenmesine yardımcı olabilir.

### Network Policy Coverage Nasıl Ölçülür?

Örneğin production namespace'lerin kaçında default-deny policy bulunduğu ölçülebilir.

Ama sayı tek başına yeterli değildir.

Policy yanlış yazılmışsa uygulama iletişimi yine gereğinden geniş olabilir.

Bu nedenle security validation gerekir.

### Kubernetes Security Score Kullanılabilir mi?

Yönetim görünürlüğü için;

RBAC,

Workload,

Network,

Image,

Runtime,

Logging

alanları puanlanabilir.

Ancak tek bir privileged internet-facing pod bütün ortalama skordan daha önemli olabilir.

Bu nedenle score + critical attack path birlikte sunulmalıdır.

### Kubernetes Raporunda Neler Olmalıdır?

Profesyonel rapor şu alanları içerebilir:

#### Executive Summary

İş ve teknik risk özeti.

#### Cluster Architecture

EKS, AKS, GKE veya self-managed yapı.

#### Control Plane Security

API ve etcd riskleri.

#### RBAC & Identity

Kullanıcı ve service account yetkileri.

#### Workload Hardening

Root, privileged ve capability bulguları.

#### Network Security

Network Policy ve exposure.

#### Secrets

Credential güvenliği.

#### Image & Supply Chain

Registry ve vulnerability riskleri.

#### Runtime Detection

CWPP/SOC görünürlüğü.

#### Attack Path Analysis

Pod → Cluster → Cloud yolları.

#### Remediation Roadmap

Öncelikli iyileştirmeler.

### Kubernetes Güvenliğinde En Büyük Hata Nedir?

En yaygın hata:

**“Managed Kubernetes kullanıyoruz, güvenlik provider'ın sorumluluğunda.”**

varsayımıdır.

Provider control plane'in bazı katmanlarını koruyabilir.

Ancak application ve workload konfigürasyonu yine kuruma aittir.

Bir pod;

root,

privileged,

cluster-admin service account

ile çalışıyorsa provider bunu iş ihtiyacı mı yoksa hata mı diye bilemez.

Bu nedenle Kubernetes Security Shared Responsibility Model içerisinde değerlendirilmelidir.

### Container ve Kubernetes İçin Temel Güvenlik Kontrolleri

Güçlü yaklaşım şu katmanları içerebilir:

#### Trusted Images

Güvenilir registry ve image signing.

#### Image Scanning

CVE ve dependency analizi.

#### Non-Root Containers

Minimum runtime privilege.

#### Pod Security

Privileged ve dangerous configuration kontrolü.

#### RBAC

Least Privilege.

#### Network Policies

Workload segmentation.

#### Secret Management

Vault ve short-lived credential.

#### Admission Control

Policy as Code.

#### Runtime Security

CWPP/eBPF tabanlı detection.

#### Audit & SIEM

Merkezi visibility.

#### Continuous Validation

KSPM ve security assessment.

Bu katmanlar birlikte çalışmalıdır.

### Container Security Lifecycle Nasıl Olmalıdır?

Container güvenliği yalnızca production runtime'da başlamamalıdır.

Daha doğru model:

#### Code

↓

#### Dependency Scan

↓

#### Dockerfile Security

↓

#### Image Build

↓

#### Image Scan

↓

#### Image Sign

↓

#### Registry

↓

#### Admission Policy

↓

#### Runtime Security

↓

#### Monitoring

↓

#### Incident Response

Bu yapı **Secure Software Supply Chain** yaklaşımını destekler.

### Kubernetes Security ile DevSecOps Arasındaki İlişki

Kubernetes config çoğu zaman YAML veya Helm chart olarak source control'da tutulur.

Bu nedenle security kontrolleri CI/CD içerisine alınabilir.

Örneğin;

manifest scanning,

RBAC review,

secret scan,

policy validation

deployment öncesinde yapılabilir.

Bu **Shift Left Kubernetes Security** yaklaşımıdır.

### Runtime Validation Neden Hâlâ Gereklidir?

Pipeline güvenli olabilir.

Ancak administrator production'da manuel değişiklik yapabilir.

Ya da saldırgan runtime'da API üzerinden yeni pod oluşturabilir.

Bu nedenle:

**Shift Left + Runtime Security + KSPM**

birlikte kullanılmalıdır.

### Kubernetes Attack Path Analizi Neden Geleceğin Ana Konularından Biri?

Çünkü modern cloud-native mimarilerde risk tek bir platform içinde kalmaz.

Saldırı zinciri şöyle olabilir:

#### Internet

↓

#### Web Application Vulnerability

↓

#### Container

↓

#### Kubernetes Service Account

↓

#### Secret

↓

#### Cloud IAM

↓

#### Managed Database

Bu zincir;

Application Security,

Container Security,

Kubernetes Security,

Cloud IAM,

Data Security

alanlarını aynı anda içerir.

Saldırgan açısından bunlar ayrı departmanlar değildir.

Tek bir saldırı yoludur.

Bu nedenle modern güvenlik de aynı bütünlükte değerlendirilmelidir.

### Sonuç: Kubernetes Güvenliği Pod Güvenliğinden Daha Fazlasıdır

Kubernetes güçlü bir orchestration platformudur.

Ama güvenliği yalnızca:

**“Image'da CVE var mı?”**

sorusuyla ölçülemez.

Daha doğru sorular şunlardır:

#### Pod root mu çalışıyor?

#### Privileged mı?

#### Hangi service account'u kullanıyor?

#### Bu service account hangi secret'ları okuyabiliyor?

#### Network üzerinde hangi servislerle konuşabiliyor?

#### Cloud IAM yetkisi var mı?

#### Runtime'da şüpheli process tespit ediliyor mu?

#### API Server aktiviteleri SOC tarafından görülüyor mu?

Gerçek Container ve Kubernetes Security;

**Secure Build + Least Privilege + RBAC + Network Isolation + Secret Security + Admission Control + Runtime Detection + Cloud IAM Security + Continuous Validation**

yaklaşımıyla oluşturulur.

Ve container dünyasındaki kritik uygulamaların arka tarafında çoğu zaman başka bir yüksek değerli sistem daha bulunur:

**Veritabanı.**

Uygulamanız güvenli olabilir.

Kubernetes cluster'ınız sıkılaştırılmış olabilir.

Cloud IAM doğru olabilir.

Ancak database yanlış yapılandırılmışsa;

müşteri verileri,

finansal kayıtlar,

kimlik bilgileri,

ticari sırlar

yine risk altında olabilir.

Bu nedenle sıradaki kritik konu doğrudan verinin kendisine gidiyor.