CNCF blogu, OpenBao ile CloudNativePG'yi bir araya getirerek Kubernetes üzerinde açık kaynaklı bir gizli bilgi yönetimi yığını oluşturmak için operasyonel bir tarif sunuyor. OpenBao, Linux Foundation çatısı altındaki HashiCorp Vault'un açık kaynaklı çatallanmış sürümüdür; CloudNativePG ise bir PostgreSQL kümesini kendi kendini iyileştiren, senkron çoğaltmaya ve sertifika tabanlı kimlik doğrulamaya sahip bir hizmete dönüştürür. Tarif, CNCF'nin mezun bir projesi olan Kubernetes'ten ve CNCF'de Incubation aşamasına geçmek üzere Teknik Gözetim Komitesi tarafından değerlendirilen bir Sandbox projesi olan CloudNativePG'den yararlanıyor.
Temel fikir, PostgreSQL'i yalnızca sıradan bir depolama alanı olarak kullanmak değil; OpenBao'nun belirli bir sağlayıcıya ait özel bir bulut veritabanına bağlı kalmadan, yüksek esneklik sağlayan bir PostgreSQL arka ucuna dayanmasını sağlamaktır. Tarif, yeterli veri dayanıklılığını güvence altına almak için bir senkron yedek kopyanın kullanılabilir olmasının yeterli olduğu, kota tabanlı senkron çoğaltmaya sahip üç CloudNativePG örneği kullanıyor. Buna karşılık, dayanıklılık koşulunu karşılayan bir yedek kopya bulunmadığında yazma işlemleri durabilir.
Tasarımda ne değişiyor?
OpenBao, ha_enabled = true seçeneğiyle yerel PostgreSQL depolama backend'ini ve yüksek kullanılabilirlik kilit tablosunu kullanıyor. Yapılandırma, verileri depolamak için openbao_kv_store ve yüksek kullanılabilirlik kilit kayıtlarını saklamak için openbao_ha_locks olmak üzere iki tablo oluşturuyor. Tarif, tüm durumun CloudNativePG'de tutulması gerektiğinden OpenBao şemasındaki varsayılan yerel depolamayı devre dışı bırakıyor.
CloudNativePG, PostgreSQL kümesini üç örnekle çalıştırıyor; düğüm seçicileri, tolerasyonlar ve pod yakınlık kısıtları kullanılarak örnekler özel düğümlere yönlendiriliyor ve ayrı arıza alanlarına dağıtılıyor. Tarif, sabit bir görüntü etiketi elle yazmak yerine PostgreSQL 18'in minimal sürümünü belirleyen bir görüntü kataloğu kullanıyor; ayrıca SHA özetiyle güvenliği sağlanmış bir görüntünün kullanıldığı bir test durumu da gösteriyor.
Parolasız kimlik doğrulama
Tarifin en önemli yönlerinden biri, OpenBao'nun veritabanına yaptığı bağlantılardan parolaları kaldırmasıdır. CloudNativePG, şemaya sahip bir rol ve openbao-rw adlı kısıtlı bir işletim rolü için DatabaseRole nesneleri oluşturur; her ikisi de TLS istemci sertifikası alır. pg_hba kuralları, bu iki rol için TLS bağlantısı ve istemci sertifikası kullanımını zorunlu kılarken şifrelenmemiş bağlantıları reddeder.
Bu ayrıntı önemlidir; çünkü yalnızca sertifika oluşturmak, sertifikanın otomatik olarak kullanılmasını zorunlu kılmaz. Her bağlantıda kimlik doğrulamanın sertifikayla mı, parolayla mı yapılacağını veya bağlantının reddedileceğini belirleyen PostgreSQL kurallarıdır. Tarif ayrıca kapsayıcıların içine bağlanan gizli bilgi dosyalarının izinlerini 0640 olarak ayarlar; çünkü libpq kitaplığı, varsayılan 0644 değeriyle bağlandığında grup veya tüm kullanıcılar tarafından okunabilen özel anahtarları reddeder.
DatabaseRole, kaynakta belirtildiği üzere şu anda tablo düzeyinde yetki verme işlemlerini yönetmediğinden, tek seferlik bir Job görevi tabloları oluşturma ve kısıtlı role SELECT, INSERT, UPDATE ve DELETE yetkileri verme komutlarını yürütür. Görev ayrıca PUBLIC için CONNECT yetkisini ve genel şema üzerindeki kullanım yetkisini geri alır, ardından gereken asgari yetkileri openbao-rw rolüne yeniden verir. OpenBao yapılandırmasında skip_create_table seçeneği etkinleştirilir; böylece kısıtlı işletim rolü tabloları kendisi oluşturmaya çalışmaz.
Bu, Kubernetes operatörleri açısından pratikte ne anlama geliyor?
Tarif, önceden CloudNativePG yapılandırmalarını içeren ve altı düğümlü bir Kind kümesi oluşturan cnpg-playground deposunu kullanarak yerel bir test yolu sunuyor. Deneme için Docker, Kind, Helm ve kubectl gerekiyor. Ancak test ortamındaki düğüm dağılımı önemli bir kısıt getiriyor: Özel ve etiketli PostgreSQL düğümleri nedeniyle, zorunlu yakınlıkla üç OpenBao örneğini dağıtmak için yalnızca iki genel düğüm kalıyor. Bu nedenle tarif, Kind ortamında OpenBao'nun kontrol düzlemi düğümünü geçici olarak kullanmasına izin veriyor ve bu tolerasyonun üretime taşınmaması konusunda açıkça uyarıyor. Etiketlenmemiş üç çalışan düğüme sahip bir üretim kümesinde bu çözüm gerekli değildir.
OpenBao grafiği kurulduktan sonra küme başlatılmalı ve her örneğin mühürü, beş anahtar içinden gereken üç Shamir anahtarı kullanılarak ayrı ayrı kaldırılmalıdır. İlk örneğin mührünün kaldırılması diğer iki örneğin mührünü kaldırmaz; ayrıca varsayılan OrderedReady StatefulSet politikası, bir sonraki örneğin oluşturulmasını önceki örnek hazır olana kadar geciktirir. Bu nedenle mühür kaldırma anahtarları ve kök belirteci güvenli biçimde saklanmalı, ardından anahtarlar her örneğe sırayla girilmelidir.
Başlatma işleminden sonra OpenBao, başlatma durumunu ve anahtarlarını openbao_kv_store tablosunda saklar; deneme gizli bilgisi, PostgreSQL tablosuna doğrudan erişildiğinde bile açık metin olarak değil, BYTEA türünde şifrelenmiş veri olarak tutulur. Kaynak, kısıtlı PostgreSQL rolüyle KV v2 kullanılarak bir gizli bilginin yazılıp okunmasına yönelik testin başarılı olduğunu doğrular.
Operasyonel kısıtlar ve tarifin kapsamadığı konular
Sertifikalar CloudNativePG tarafından otomatik olarak yenilenir; CNPG istemci sertifikasının geçerlilik süresi 90 gündür ve genellikle sona ermesinden yaklaşık bir hafta önce yenilenir. Ancak OpenBao sertifika dosyalarını otomatik olarak yeniden okuyamaz; PostgreSQL depolama arayüzü, bağlantı havuzunu işlem başlatılırken açar. Bu nedenle yenileme sonrasında OpenBao örnekleri için kademeli bir yeniden başlatma planlanmalı ve tercihen eski sertifikanın sona ermesinden önceki 83 günlük yenileme penceresi içinde uygulanmalıdır.
Ayrıca Kubernetes kümesi içindeki yüksek kullanılabilirlik, eksiksiz bir felaket kurtarma planına eşit değildir. Tarif, tüm kümenin kaybına karşı otomatik olarak yedekleme veya kurtarma oluşturmaz. Üretim kullanımı için kaynak, Amazon S3, Google Cloud Storage veya Azure Blob Storage gibi bir nesne deposuyla birlikte Barman Cloud Plugin'in eklenmesini ve WAL arşivleme, temel yedeklemeler ve belirli bir zamana geri yüklemeyi etkinleştirmek üzere Backup ve ScheduledBackup kaynaklarının kullanılmasını öneriyor. Tüm kümenin kaybından kurtulmayı gerektiren RTO ve RPO hedefleri için ise ikinci bir kümede veya bölgede asenkron bir PostgreSQL kümesi gerekir.