Kubernetes Yapılandırma ve Hassas Veri Yönetimi Politikası

1.0 Giriş ve Politikanın Amacı

Bu yazı, Kubernetes ortamlarımızda uygulama yapılandırmalarını ve hassas verileri yönetmek için standartlaştırılmış en iyi uygulamaları ve politikaları tanımlamaktadır. Modern ve etkin bir yazılım geliştirme süreci, yapılandırma verilerini uygulama kodundan ayırmayı gerektirir. Bu ayrıştırma (decoupling) ilkesi, uygulamalarımızın güvenliğini, farklı ortamlardaki taşınabilirliğini ve genel yönetilebilirliğini doğrudan artırdığı için stratejik bir öneme sahiptir. Bu politika, bu kritik ayrımı sağlamak üzere tasarlanmış temel Kubernetes nesnelerinin doğru ve güvenli kullanımını zorunlu kılmayı amaçlamaktadır.

• Kapsam: Bu politika, gizli olmayan yapılandırma verileri için ConfigMap ve hassas veriler (parolalar, API anahtarları vb.) için Secret nesnelerinin oluşturulması, kullanılması ve güvenliğinin sağlanmasına yönelik kuralları içerir.
• Hedef Kitle: Bu belge, platform üzerinde uygulama geliştiren ve dağıtan tüm geliştiriciler ile DevOps mühendisleri için birincil başvuru kaynağıdır. Belirtilen standartlara uymak, sistemlerimizin kararlılığını ve güvenliğini sağlamak adına zorunludur.

Bu temel ilkeleri benimsedikten sonra, Kubernetes’in bu amaçla sunduğu iki temel nesneyi, ConfigMap ve Secret‘ı ve aralarındaki kritik farkları daha yakından inceleyeceğiz.

2.0 Temel Kavramlar: ConfigMap ve Secret

Kubernetes, uygulama yapılandırmalarını koddan ayırmak için iki temel API nesnesi sunar: ConfigMap ve Secret. Bu nesneler, uygulamaların farklı ortamlarda (geliştirme, test, üretim) herhangi bir kod değişikliği gerektirmeden çalışmasını sağlayarak esnekliği ve güvenliği artırır.

2.1 ConfigMap: Çevresel Yapılandırma

ConfigMap, gizli olmayan (non-confidential) verileri anahtar-değer çiftleri halinde saklayan bir API nesnesidir. Uygulamanın çalışması için gerekli olan ancak hassas nitelik taşımayan yapılandırma verilerini yönetmek için ideal bir araçtır.

ConfigMap için ideal kullanım senaryoları şunlardır:

• Uygulama ayarları (örneğin, tema rengi, sayfa başına öğe sayısı)
• Ortam değişkenleri (örneğin, bir API’nin URL adresi)
• Yapılandırma dosyalarının içerikleri (örneğin, nginx.conf veya settings.xml dosyaları)

Not: Bir ConfigMap nesnesinin boyutu 1 MiB ile sınırlıdır.

2.2 Secret: Hassas Veri Yönetimi

Secret, az miktarda hassas veri saklamak için tasarlanmış bir Kubernetes nesnesidir. Adından da anlaşılacağı gibi, güvenli bir şekilde yönetilmesi gereken veriler için kullanılır.

Secret için uygun kullanım senaryoları şunlardır:

• Parolalar ve veritabanı bağlantı dizeleri
• OAuth token’ları ve API anahtarları
• SSH anahtarları
• Özel Docker registry kimlik bilgileri (imagePullSecrets)

2.3 Kritik Ayrım: Anlamsal Farklılık

ConfigMap ve Secret arasındaki temel fark kriptografik bir koruma seviyesi değil, semantik (anlamsal) bir ayrımdır. Bir veriyi Secret olarak tanımlamak, Kubernetes sistemine ve küme yöneticilerine bu verinin “hassas” olduğu ve özel bir dikkatle ele alınması gerektiği sinyalini verir. Bu anlamsal fark, kümenin bu nesnelere farklı davranmasını sağlar. Örneğin, kubectl get secret komutu varsayılan olarak içeriği göstermezken, kubectl get configmap komutu tüm veriyi açıkça listeler.

Aşağıdaki tablo, iki nesne arasındaki temel farkları özetlemektedir:

Özellik	ConfigMap	Secret
Amacı	Gizli olmayan yapılandırma verileri	Hassas ve gizli veriler
Varsayılan Güvenlik	Şifrelenmez, düz metin	Şifrelenmez, sadece Base64 kodlanır
Anlamı	“Bu bir yapılandırmadır.”	“Bu veri hassastır, dikkatli kullanılmalıdır.”
CLI Davranışı	kubectl get ile içerik görülebilir	kubectl get ile içerik varsayılan olarak gizlenir

Bu nesnelerin ne olduğunu ve ne zaman kullanılacağını anladıktan sonra, bir sonraki bölümde bu verilerin uygulamalara nasıl güvenli ve etkin bir şekilde aktarılacağını inceleyeceğiz.

3.0 Veri Enjeksiyonu için En İyi Uygulamalar

Yapılandırma ve hassas verileri ConfigMap veya Secret nesnelerinde saklamak, sürecin yalnızca ilk adımıdır. Bu verilerin Pod’lar içindeki konteynerlere doğru yöntemle enjekte edilmesi, uygulamanın esnekliği, güncellenebilirliği ve güvenliği üzerinde doğrudan etkilidir. Kubernetes bu işlem için iki temel yöntem sunar.

3.1 Yöntem 1: Ortam Değişkeni Olarak Enjekte Etme

Hem ConfigMap (configMapKeyRef) hem de Secret (secretKeyRef) içindeki anahtar-değer çiftleri, bir konteynere doğrudan ortam değişkeni olarak enjekte edilebilir. Bu yöntem, basit ve tekil yapılandırma değerleri için oldukça pratiktir.

Ancak bu yöntemin kritik bir kısıtlaması vardır: Ortam değişkeni olarak enjekte edilen veriler, kaynak ConfigMap veya Secret güncellendiğinde çalışan Pod’larda otomatik olarak güncellenmez. Değişikliğin uygulamaya yansıması için Pod’un yeniden başlatılması gerekir.

3.2 Yöntem 2: Volume (Birim) Olarak Bağlama

Daha esnek bir yaklaşım, bir ConfigMap veya Secret nesnesinin tamamını bir birim (volume) olarak Pod’a bağlamaktır. Bu yöntem uygulandığında, nesne içindeki her bir anahtar, bağlanan dizin altında bir dosya haline gelir ve dosyanın içeriği o anahtarın değerini temsil eder.

Bu yöntemin temel avantajı dinamik güncelleme yeteneğidir: Birim olarak bağlanan bir ConfigMap veya Secret güncellendiğinde, bu değişiklikler çalışan Pod’daki dosyalara otomatik olarak yansıtılır (kubelet senkronizasyon döngüsüne bağlı olarak). Bu, uygulamanın yeniden başlatılmasına gerek kalmadan yapılandırmayı anında değiştirmeyi mümkün kılar.

3.3 Politika: Hangi Yöntem Ne Zaman Kullanılmalı?

Doğru enjeksiyon yöntemini seçmek, uygulamanızın operasyonel verimliliğini belirler. Aşağıdaki tablo, geliştiricilere yol göstermek amacıyla bu iki yöntemin ne zaman tercih edilmesi gerektiğini özetlemektedir:

Kriter	Ortam Değişkeni	Volume Olarak Bağlama
Kullanım Kolaylığı	Basit anahtar-değer çiftleri için ideal	Yapılandırma dosyalarının tamamını sağlamak için ideal
Dinamik Güncelleme	Desteklenmez (Pod yeniden başlatma gerektirir)	Desteklenir (Değişiklikler, kubelet senkronizasyon döngüsüne bağlı olarak Pod’a yansıtılır)
Önerilen Senaryo	Değişmesi beklenmeyen basit ayarlar (API URL’si gibi)	Sık güncellenebilen tam yapılandırma dosyaları (nginx.conf gibi)

Verilerin uygulamalara nasıl aktarılacağını belirledikten sonra, özellikle hassas verileri içeren Secret nesnelerinin güvenliğinin nasıl sağlanacağına odaklanmamız kritik önem taşır.

4.0 Güvenlik Politikaları ve Sorumluluklar

Secret nesneleri hassas verileri yönetmek için tasarlanmış olsa da, varsayılan olarak yüksek bir güvenlik seviyesi sunmazlar. Bu nedenle, veri sızıntılarını önlemek ve kurumsal güvenlik standartlarını karşılamak için ek güvenlik katmanları uygulamak kritik bir şirket politikasıdır.

4.1 Temel Güvenlik Uyarısı: Şifreleme Yanılgısı

Yeni başlayanlar arasındaki en yaygın yanılgılardan biri, Secret nesnelerinin adından dolayı şifrelendiğini (encrypted) varsaymaktır. Bu kesinlikle doğru değildir. Kubernetes, bir Secret içindeki verileri varsayılan olarak şifrelemez; yalnızca Base64 formatında kodlar (encoded).

Base64, bir güvenlik mekanizması değildir ve veriyi gizlemez. Örneğin, admin dizesinin Base64 karşılığı olan YWRtaW4=, tek bir komutla kolayca orijinal haline geri çözülebilir. Bu nedenle, Base64 kodlamasına asla bir güvenlik önlemi olarak güvenilmemelidir.

4.2 Politika: Erişim Kontrolü (RBAC)

Secret nesnelerinin anlamsal değeri, onlara yönelik daha sıkı erişim kontrol politikaları uygulama imkanı tanımasıdır.

Politika: Tüm Secret nesnelerine erişim, “en az yetki prensibi” (principle of least privilege) doğrultusunda Rol Tabanlı Erişim Kontrolü (RBAC) politikaları ile sıkı bir şekilde kısıtlanmalıdır. Sadece ilgili uygulamanın servis hesabının (ServiceAccount), ihtiyaç duyduğu belirli Secret‘lara okuma (get, list, watch) izni olmalıdır. Geliştiricilerin veya diğer uygulamaların gereksiz Secret‘lara erişimi engellenmelidir.

4.3 Politika: Verinin Saklandığı Yerde Şifrelenmesi (Encryption at Rest)

Secret verilerinin gerçek anlamda korunması, Kubernetes’in veri deposu olan etcd seviyesinde başlar. “Duran verinin şifrelenmesi” (encryption at rest), etcd içindeki verilerin diskte şifreli olarak saklanmasını sağlar.

Bu özellik, varsayılan bir davranış değildir ve küme yöneticisi tarafından bilinçli olarak yapılandırılması gereken gelişmiş bir güvenlik önlemidir. Aktif edildiğinde, etcd veritabanına doğrudan fiziksel erişim sağlansa bile Secret içeriklerinin okunmasını engeller.

Politika: Tüm üretim (production) Kubernetes kümelerinde, etcd için “encryption at rest” özelliği zorunludur. Bu, hassas verilerimiz için temel bir koruma katmanı sağlar ve veri güvenliği standartlarımızın temelini oluşturur.

Bu kuralları özetleyen ve hızlı bir başvuru kaynağı sunan kontrol listesi, belgenin son bölümünde sunulmaktadır.

5.0 Politika Özeti ve Uygulama Kuralları

Bu bölümde, belge boyunca ele alınan tüm kritik politika maddeleri ve en iyi uygulamalar, geliştiriciler ve operasyon ekipleri için hızlı bir başvuru kaynağı olarak özetlenmiştir. Aşağıdaki kurallara uymak, Kubernetes ortamlarımızda yapılandırma ve hassas verilerin güvenli, tutarlı ve verimli bir şekilde yönetilmesini sağlayacaktır.

Yapılması Gerekenler (DO):

• [✓] Hassas veriler (parolalar, API anahtarları, token’lar) için her zaman Secret kullanın.
• [✓] Gizli olmayan yapılandırma verileri (URL’ler, port numaraları) için ConfigMap kullanın.
• [✓] Secret‘lara erişimi kısıtlamak için katı RBAC politikaları uygulayın.
• [✓] Dinamik olarak güncellenmesi gereken yapılandırma dosyaları için Secret veya ConfigMap‘leri Volume olarak bağlayın.
• [✓] Üretim ortamlarında etcd için Encryption at Rest özelliğinin aktif olduğundan emin olun.

Yapılmaması Gerekenler (DO NOT):

• [✗] Secret nesnelerinin şifrelendiğini varsaymayın. Unutmayın, sadece Base64 kodlanmıştır.
• [✗] Hassas verileri ConfigMap içinde saklamayın.
• [✗] Secret YAML dosyalarını veya Base64 ile kodlanmış değerleri Git gibi versiyon kontrol sistemlerine commit etmeyin. Bunun yerine harici bir sır yönetim aracı kullanın.
• [✗] Uygulama imajlarının içine yapılandırma veya hassas verileri sabit olarak kodlamayın (hard-code).