Kubernetes, modern bulut yerel dünyasında fiili konteyner yönetimi platformudur. Mikro hizmetleri esnek ve ölçeklenebilir bir şekilde geliştirmeyi, dağıtmayı ve yönetmeyi mümkün kılar. Kubernetes, çeşitli bulut sağlayıcıları, kapsayıcı çalışma zamanı arabirimleri, kimlik doğrulama sağlayıcıları ve genişletilebilir entegrasyon noktaları ile çalışır.
Ancak Kubernetes’in hala önemli bir dezavantajı var: güvenlik. Kubernetes’in herhangi bir altyapı üzerinde kapsayıcılı herhangi bir uygulamayı çalıştırmaya yönelik entegratör yaklaşımı, Kubernetes ve üzerinde yaşayan uygulama yığını çevresinde bütünsel güvenlik oluşturmayı zorlaştırır.
Red Hat’in 2022’sine göre”Kubernetes’in Durumu” güvenlik raporu, Kubernetes kullanıcılarının çoğunluğunun adreslenmemiş güvenlik endişeleri nedeniyle teslimatını durdurdu. Ayrıca, önceki 12 ay boyunca, çalışmadaki hemen hemen her Kubernetes kullanıcısı en az bir güvenlik olayı yaşadı. Bu nedenle, adil Kubernetes ortamlarının varsayılan olarak güvenli olmadığını ve risklere açık olduğunu söylemek.
Bu makale, gerçek hayattan örneklerle en önemli 10 güvenlik riskini ve bunlardan nasıl kaçınılacağına ilişkin ipuçlarını tartışmaktadır.
1. Kubernetes Sırları
Sırlar parolalar, sertifikalar veya belirteçler gibi hassas verileri depolamak ve bunları kapsayıcılarda kullanmak için Kubernetes’in temel yapı taşlarından biridir. Kubernetes sırlarıyla ilgili üç kritik konu vardır:
- Gizli diziler, hassas verileri temel 64 kodlu dizeler olarak depolar, ancak varsayılan olarak şifrelenmezler. Kubernetes şunları sunar: şifreleme depolama için kaynaklar, ancak yapılandırmanız gerekir. Ayrıca, sırlarla ilgili en büyük tehdit, aynı ad alanındaki herhangi bir bölmenin – ve bölmenin içinde çalışan herhangi bir uygulamanın – bunlara erişebilmesi ve okuyabilmesidir.
- Rol tabanlı erişim denetimi (RBAC) Kubernetes kaynaklarına kimlerin erişebileceğini düzenlemenize olanak tanır. Yalnızca ilgili kişilerin ve uygulamaların sırlara erişebilmesi için RBAC kurallarını doğru şekilde yapılandırmanız gerekir.
- Sırlar ve Yapılandırma Haritaları çalışan kapsayıcılara veri aktarmanın iki yöntemidir. Eski ve kullanılmayan sırlar veya ConfigMap kaynakları varsa, karışıklık yaratabilir ve güvenlik açığı bulunan verileri sızdırabilir. Örneğin, arka uç uygulama dağıtımınızı siler, ancak veritabanı parolalarınızı içeren sırrı silmeyi unutursanız, gelecekte herhangi bir kötü amaçlı bölme bunları kullanabilir.
2. Güvenlik Açıkları Olan Konteyner Görüntüleri
Kubernetes, çalışan düğümlerinde kapsayıcıları dağıtan ve çalıştıran bir kapsayıcı düzenleme platformudur. Ancak, güvenlik açıkları veya açıkları olup olmadığı için kapsayıcıların içeriğini kontrol etmez.
Bu nedenle, kümede yalnızca kritik güvenlik açıkları (uzaktan kod yürütme gibi) olmayan güvenilir kayıtlardan alınan görüntülerin çalışacağından emin olmak için dağıtımdan önce görüntüleri taramak gerekir. Konteyner görüntü taraması, otomasyon ve kusurları daha erken tespit etmek için CI/CD sistemlerine de entegre edilmelidir.
3. Çalışma Zamanı Tehditleri
Kubernetes iş yükleri, yani kapsayıcılar, çalışan düğümlerde çalışır ve kapsayıcılar, çalışma zamanında ana bilgisayar işletim sistemi tarafından kontrol edilir. İzin verilen politikalar veya güvenlik açıklarına sahip kapsayıcı görüntüleri varsa, bunlar kümenizin tamamına arka kapılar açabilir. Bu nedenle, çalışma zamanında güvenliği sağlamak için işletim sistemi düzeyinde çalışma zamanı koruması gerekir ve çalışma zamanı tehditlerine ve güvenlik açıklarına karşı en önemli koruma, Kubernetes genelinde en az ayrıcalıklı ilkeyi uygulamaktır.
Açık kaynak ve yaygın olarak kabul edilen araçlar gibi seccomp, SELinuxve Uygulama Zırhı Linux çekirdeği düzeyinde, politikaları uygulamak ve erişimi kısıtlamak için kullanılabilir. Bu araçlar Kubernetes’te dahili değildir ve çalışma zamanı tehditlerine karşı koruma sağlamak için harici yapılandırma ve çaba gerektirir. Kubernetes’i otomatik bir şekilde güvenceye almak için aşağıdakileri kullanmayı deneyin: Kubernetes Güvenlik Duruş Yönetimi (KSPM) yaklaşmak. KSPM, bütünsel bir yaklaşım kullanarak güvenlik, yapılandırma ve uyumluluk sorunlarını tespit etmek, düzeltmek ve uyarmak için otomasyon araçlarından yararlanır.
4. Küme Yanlış Yapılandırması ve Varsayılan Ayarlar
Kubernetes API ve bileşenleri, karmaşık bir dizi kaynak tanımları ve yapılandırma seçeneklerinden oluşur. Bu nedenle Kubernetes, yapılandırma parametrelerinin çoğu için varsayılan değerler sunar ve uzun YAML dosyaları oluşturma yükünü ortadan kaldırmaya çalışır.
Ancak, küme ve kaynak yapılandırmasıyla ilgili üç kritik konuda dikkatli olmanız gerekir:
- Varsayılan Kubernetes yapılandırmaları, esnekliği ve çevikliği artırmaya çalıştıkları için yararlıdır, ancak bunlar her zaman en güvenli seçenekler değildir.
- Kubernetes kaynakları için çevrimiçi örnekler, başlamak için yardımcı olur, ancak bu örnek kaynak tanımlarının kümenize ne dağıtacağını iki kez kontrol etmek gerekir.
- Kümeler üzerinde çalışırken “kubectl edit” komutlarını kullanarak Kubernetes kaynaklarında değişiklik yapmak gelenekseldir. Ancak, kaynak dosyaları güncellemeyi unutursanız, sonraki dağıtımda değişikliklerin üzerine yazılır ve izlenmeyen değişiklikler öngörülemeyen davranışlara yol açabilir.
5. Kubernetes RBAC Politikaları
RBAC, Kubernetes kaynaklarına yönelik yetkilendirmeyi yönetmek ve denetlemek için Kubernetes’e özgü bir yöntemdir. Bu nedenle, kümeleri istenmeyen erişimden korumak için RBAC ilkelerini yapılandırmak ve sürdürmek çok önemlidir.
RBAC ilkeleriyle çalışırken dikkate alınması gereken iki kritik nokta vardır. İlk olarak, kümedeki temel olarak her şeyi yapabilen cluster_admin rolü gibi bazı RBAC ilkeleri çok serbesttir. Bu roller, onları daha çevik hale getirmek için normal geliştiricilere atanır. Ancak, bir güvenlik ihlali durumunda, saldırganlar cluster_admin kullanarak kümelere hızlı bir şekilde üst düzey erişim sağlar. Bunu önlemek için, belirli kaynaklar için RBAC ilkelerini yapılandırmalı ve bunları belirli kullanıcı gruplarına atamalısınız.
İkincisi, genel olarak, yazılım geliştirme yaşam döngüsünde geliştirme, test etme, hazırlama ve üretim gibi çeşitli ortamlar bulunur. Ayrıca geliştiriciler, testçiler, operatörler ve bulut yöneticileri gibi farklı odaklara sahip birden fazla ekip vardır. RBAC politikaları, maruziyeti sınırlamak için her grup ve her ortam için doğru şekilde atanmalıdır.
6. Ağ Erişimi
Kubernetes’te bir pod, küme dışındaki diğer pod’lara ve harici adreslere bağlanabilir; diğerleri bu bölmeye varsayılan olarak kümenin içinden bağlanabilir. Ağ politikaları bölmeler, ad alanları ve IP blokları arasındaki ağ erişimini yönetmek ve kısıtlamak için Kubernetes’e özgü kaynaklardır.
Ağ ilkeleri, bölmelerdeki etiketlerle de çalışabilir, bu nedenle etiketlerin verimsiz kullanımı istenmeyen erişimlere yol açabilir. Ayrıca, kümeler bulut sağlayıcılarında yaşadığında, küme ağı da sanal özel bulutun (VPC) geri kalanından izole edilmelidir.
7. Bütünsel İzleme ve Denetim Günlüğü
Bir uygulamayı bir Kubernetes kümesine dağıttığınızda, yalnızca uygulama ölçümlerini izlemek yeterli değildir. Tüm yığının bütünsel bir görünümüne sahip olmak için Kubernetes kümesinin durumunu, bulut altyapısını ve bulut denetleyicilerini de izlemelisiniz. Davetsiz misafirler olası her açılıştan kümelerinize erişmek için test yapacaklarından, ihlalleri izlemek ve anormallikleri tespit etmek de önemlidir.
Kubernetes, kullanıma hazır sağlar denetim günlükleri kümedeki güvenlikle ilgili olaylar için. Yine de çeşitli uygulamalardan kayıtları toplamanız ve sağlıklarını merkezi bir yerden izlemeniz gerekiyor.
8. Kubernetes API’si
Kubernetes API, tüm dahili ve harici istemcilerin Kubernetes ile bağlantı kurduğu ve iletişim kurduğu tüm sistemin özüdür. Kubernetes bileşenlerini şirket içinde dağıtır ve yönetirseniz, Kubernetes API sunucusu ve bileşenleri, potansiyeli olan açık kaynaklı araçlar olduğundan daha dikkatli olmanız gerekir: ve gerçek – güvenlik açıkları. Bu nedenle, Kubernetes’in en son kararlı sürümünü kullanmalı ve canlı kümeleri mümkün olduğunca erken yamalamalısınız.
Bulut sağlayıcıları kullanıyorsanız, Kubernetes kontrol düzlemi sağlayıcının kendisinin kontrolündedir, bu nedenle bulut altyapısı otomatik olarak güncellenir ve yamalar. Ancak, çoğu durumda çalışan düğümlerini yükseltmekten kullanıcılar sorumludur. Bu nedenle, düğümleri kolayca yükseltmek veya yenileriyle değiştirmek için otomasyon ve kaynak sağlama araçlarını kullanabilirsiniz.
9. Kubernetes Kaynak İstekleri ve Sınırları
Kubernetes, kapsayıcıları zamanlamaya ve çalıştırmaya ek olarak, kapsayıcıların kaynak kullanımını CPU ve bellek açısından da sınırlayabilir. Kubernetes kullanıcıları bunları çoğunlukla ihmal etseler de, kaynak istekleri ve limitler iki nedenden dolayı kritiktir:
- Güvenlik: Bölmeler ve ad alanları kısıtlanmadığında, güvenlik açığı olan tek bir kapsayıcı bile kümenizdeki hassas verilere erişebilir.
- Maliyet: İstenen kaynaklar gerçek kullanımdan daha fazla olduğunda, düğümlerin kullanılabilir kaynakları tükenecektir. Bu, otomatik ölçeklendirme etkinleştirilirse düğüm havuzunda bir artışa yol açacaktır ve yeni düğümler kaçınılmaz olarak bulut faturanızı artıracaktır.
Kaynak istekleri doğru hesaplanıp atandığında, tüm küme CPU ve bellek açısından verimli çalışır. Ayrıca kaynak limitleri belirlendiğinde hem hatalı uygulamalar hem de izinsiz giriş yapanlar kaynak kullanımı açısından sınırlandırılacaktır. Örneğin, herhangi bir kaynak sınırlaması yoksa, kötü niyetli bir kapsayıcı, düğümdeki kaynakların neredeyse tamamını tüketebilir ve uygulamanızı kullanılamaz hale getirebilir.
10. Veri ve Depolama
Kapsayıcılar geçici olacak şekilde tasarlanmış olsa da Kubernetes, durum bilgisi olan kapsayıcılı uygulamaları ölçeklenebilir ve güvenilir bir şekilde çalıştırmayı mümkün kılar. İle Durumsal Küme kaynak, veritabanlarını, veri analizi araçlarını ve makine öğrenimi uygulamalarını Kubernetes’e hızlı bir şekilde dağıtabilirsiniz. Veriler, bölmeler tarafından şu şekilde erişilebilir olacaktır: birimler kaplara bağlanır.
Ancak kümedeki diğer bölmelerin istenmeyen erişimini önlemek için erişimi ilkelere ve etiketlere göre sınırlamak çok önemlidir. Ayrıca Kubernetes’te depolama, harici sistemler tarafından sağlanır, bu nedenle kümedeki kritik veriler için şifreleme kullanmayı düşünmelisiniz. eğer sen yönetirsen depolama eklentilerietkin olduklarından emin olmak için güvenlik parametrelerini de kontrol etmelisiniz.
Çözüm
Kubernetes, mikro hizmet uygulamalarını çalıştırmak için tartışılmaz bir kapsayıcı yönetim platformudur. Ancak, projenin ana odak noktası olmadığı için bütünsel güvenlik hala dezavantajlarından biridir. Bu nedenle, kümelerinizi ve uygulamalarınızı daha güvenli hale getirmek için ekstra adımlar atmanız gerekir.