OpenShift Nedir?
Red Hat tarafından geliştirilen OpenShift, açık kaynak kodlu, konteyner tabanlı bir platformdur ve kullanıcıların konteyner tabanlı uygulamalarını ve iş yüklerini etkin bir şekilde yönetmelerine olanak tanır. Bu platform, AngularJS ve Go gibi programlama dilleri kullanılarak geliştirilmiştir ve Apache Lisansı altında lisanslanmıştır, bu da geliştiricilere projelerini ve uygulamalarını buluta kolayca dağıtmaları için geniş bir esneklik sunar. OpenShift, Kubernetes’in temel altyapısını kullanarak, uygulama geliştirme ve dağıtım süreçlerini hızlandırmada önemli bir rol oynar. Ayrıca, Docker Container Runtime Interface’in aksine, cri-o konteyner çalışma zamanı arayüzünü tercih ederek daha standart ve optimize bir ortam sunar. Her yeni sürümde, Kubernetes’e yüzlerce iyileştirme eklenerek platformun performansı ve güvenilirliği artırılır. OpenShift, Red Hat’in Açık Konteyner Girişimi (OCI) katılımcıları arasında yer alır ve ürünü, OCI spesifikasyonlarına uygunluğu destekler. Platform, geniş bir kullanıcı kitlesine hitap etmek için hem Community hem de Enterprise sürümlerine sahiptir, bu da kuruluşların ve bireysel geliştiricilerin ihtiyaçlarına göre esnek çözümler sunar.
OpenShift Container Platform, Kubernetes tabanlı, bulut odaklı bir konteyner yönetim sistemidir. Kubernetes’in alt yapısal temelleri üzerine inşa edilen bu platform, teknolojik ve işlevsel benzerlikler gösterir. Amacı, birkaç makine ve uygulamadan, binlerce makineyi ve milyonlarca kullanıcıyı destekleyecek büyüklüğe kolayca genişleyebilen uygulama ve veri merkezi ekosistemlerinin oluşturulmasını sağlamaktır.
OpenShift Container Platform, geliştiricilere ve bilgi teknolojisi organizasyonlarına, uygulamaların güvenli ve ölçeklenebilir kaynaklar üzerinde dağıtılabilmesi için bulut tabanlı uygulama platformları sunar. Bu platform, minimal yapılandırma ve yönetim gereksinimleriyle karakterize edilir, müşterilerin veri merkezlerine ve buluta Kubernetes platformunu entegre etmelerine olanak tanır. Ayrıca, güvenlik, mahremiyet, uygunluk ve yönetim standartlarını karşılamak üzere tasarlanmıştır.
Kubernetes’in güçlendirdiği OpenShift Container Platform, telekomünikasyon, video akışı, oyun ve bankacılık gibi alanlarda kullanılan aynı temel teknolojiyi barındırır. Red Hat’ın açık teknolojileriyle gerçekleştirilen entegrasyon sayesinde, kullanıcılar konteynerize uygulamalarını sadece tek bir bulut ortamından öteye, yerel ve çoklu bulut ortamlarına taşıyabilirler. Bu, platformun esnekliğini ve uygulamaların genişletilebilirliğini önemli ölçüde artırır.
Kubernetes, konteynerize edilmiş uygulamaların yönetimi, dağıtımı ve ölçeklendirilmesini otomatikleştiren, açık kaynaklı bir orkestrasyon aracıdır. Bu sistem, Open Container Initiative (OCI) standartlarına uygun olarak çalışan düğümler üzerindeki konteynerlerde uygulama örneklerini ve bileşenlerini çalıştırır. Konteyner, OCI-uyumlu bir imajın çalışma zamanıdır ve imaj, ikili bir uygulama biçimidir. Bir çalışma düğümü, bulut, donanım veya sanallaştırma olsun, altta yatan kaynakların bellek ve CPU kapasitelerine bağlı olarak çok sayıda konteyneri çalıştırabilir.
Pod, tek bir ana bilgisayarda bir arada konuşlandırılan bir veya daha fazla konteyneri ifade eder ve ortak kaynaklara (örneğin, hacimler ve IP adresleri gibi) sahip konteynerlerden oluşan bir grubu temsil eder. Bu, tanımlanmış, dağıtılmış ve yönetilmiş en küçük hesaplama birimidir. OpenShift Container Platform içinde, podlar, bireysel uygulama konteynerlerinin yerini alarak en küçük dağıtılabilir birim haline gelmiştir. Bu platform, bir pod içindeki tüm konteynerleri aynı düğüm üzerinde planlayıp çalıştırarak, iç ve dış dünyayla etkileşimde bulunan karmaşık uygulama setlerini yönetir.
Kubernetes’in Replica Set ve OpenShift Container Platform’un Replication Controller’ı, belirlenen sayıda pod replikasının sürekli çalışır durumda olmasını sağlayan mekanizmalar sunar. Bu, podlar sona erdiğinde veya silindiğinde daha fazlasının başlatılmasını, fazlaysa gerekli sayıya indirilmesini içerir.
Deployment ve DeploymentConfig, OpenShift Container Platform tarafından hem Kubernetes Deployment nesneleri hem de özel DeploymentConfig nesneleri şeklinde sunulur. Bu, uygulamaların, podlar olarak düğümlere nasıl dağıtılacağını yönetir; imaj isimlerini, replika sayılarını ve dağıtım etiketlerini belirler. Özellikle, DeploymentConfig nesneleri, konteyner imajlarındaki yeni sürümler gibi değişiklikleri otomatik olarak algılayıp bu değişikliklere tepki verebilen ek özellikler sunar.
Servis, pod grubuna ve bunların erişim politikalarına mantıksal bir isim vererek, uygulamaların yaratılıp yok edilmesine rağmen sabit iç IP adresleri ve ana bilgisayar adları aracılığıyla birbirleriyle iletişim kurmalarını sağlar. Örneğin, bir frontend web servisi, belirli bir servis üzerinden bir veritabanına bağlanabilir. OpenShift Container Platform, servis bilgilerini konteynerlere otomatik olarak enjekte ederek, keşif süreçlerini basitleştirir.
Route, bir servisi dış dünyaya açmanın, ona ulaşılabilir bir hostname atamanın yoludur. Bu, belirlenen routelar ve servis endpointleri aracılığıyla, 3.party müşterilerin uygulamalara erişimini sağlar. OpenShift Container Platform dışından gelen trafik, bu yönlendirme katmanı olmadan uygulamalara ulaşamaz.
Build süreci, girdi parametrelerini veya kaynak kodunu çalıştırılabilir bir imaja dönüştürür. OpenShift Container Platform, bu imajlardan konteynerler oluşturup entegre kayıt defterine iterek Kubernetes’i etkin bir şekilde kullanır.
Proje, OpenShift Container Platform’da işbirliği ve izolasyonun birimi olarak hizmet eder, kullanıcı veya geliştirici gruplarının birlikte çalışmasına olanak tanır. Projeler, kaynakların kapsamını tanımlar ve yöneticilere ve iş ortaklarına kaynak yönetimi yetkisi verir. Bir proje, ek açıklamalarla zenginleştirilmiş bir Kubernetes domainidir ve düzenli kullanıcılar için kaynaklara erişimi yönetir.
Operatorler, Kubernetes yerel uygulamalarıdır ve yazılıma işletimsel bilgiyi dahil etme amacı taşır. Bu, uygulamanın kurulumu, yapılandırması, ölçeklendirilmesi, güncellenmesi ve yedeklenmesi gibi faaliyetleri otomatikleştirir, böylece uygulamalar tek bir nesne olarak ele alınır ve yönetilir. Bu yaklaşım, uygulamaların Kubernetes ekosistemi içinde daha verimli bir şekilde yönetilmesini sağlar.
OpenShift üzerindeki uygulamalar için High Availability/Disaster Recovery
Pod Fails
- Bir pod’un her zaman iki örneğini çalıştırın.
- Örnekleri farklı node’lar üzerinde tutun.
- Pod fail durumlarına karşı kaynak ayırın.
- Pod’un çalıştığı node’ların aynı anda devre dışı kalması senaryosuna karşı önlemler alın.
- Podlar için local/host path kullanmayın.
- Uygulamalarınızı geliştirirken ilgili pod’un cevap vermeyeceği senaryoyu da göz önünde bulundurun.
- Uygulamalarınız özelinde, pod bağımlılığı olmamalı (Hangi pod’a request gittiği ile ilgili bağımlılıklar olmamalı)
Node Fails
- Node’ları izlemek için healthcheck sisteminiz olsun
- Tek bir hipervizör hatasının birden çok master node’un kullanılamaz hale gelmesine neden olmaması için master node’lar için hipervizör anti-affinity kurallarını kullanın.
- Kubernetes’in erişilemeyen bir node’daki iş yüklerini yeniden zamanlamasının varsayılan olarak beş dakika sürdüğünü anlayın.
- Sanallaştırılmış OpenShift cluster’lar için, hipervizörün yüksek kullanılabilirlik özellikleri node’ları hızlı bir şekilde geri getirebilir. Bu, node kümeye yeniden katıldığında kayıp OpenShift node’larındaki pod’ların yeniden zamanlanmasına neden olacağını unutmayın.
Cluster Fails
- Node’un HA durumu, master node’un hata durumunda sağlıklı kalmasına bağlıdır.
- Master Node başarısız olursa veya başka bir şekilde erişilemez hale gelirse, birçok işlev çalışmayı durdurur. Podların zamanlanması en kritik olanlardan biridir.
- OpenShift 4 sürümü ile, tüm node’ların (tek node’lu OpenShift hariç) her biri aynı zamanda bir etcd üyesini barındıran üç master node’u vardır.
- Üç düğümle, master node başarısız bir node ile bile çalışmaya devam edecektir.
- İki node başarısız olursa, master node da çalışamaz.
- Bununla birlikte, üç OpenShift master node’un tümü aynı veri merkezindeyse ve bir veri merkezi arızası varsa, OpenShift cluster kurtarılamaz.
İki Veri Merkezi için Senaryo Örnekleri
Storage Avability
Depolamanın kullanılabilirliğini korumanın en iyi yolları, çoğaltılmış depolama çözümleri, kesintilerden etkilenmeyen paylaşılan depolama veya clusterdan bağımsız bir veri tabanı hizmeti kullanmaktır.
İş yükleri için 3 Availability Zone
Etcd, basit, hızlı ve güvenli, dağıtılmış, güvenilir bir anahtar-değer deposudur. Bir backend hizmet keşfi ve veritabanı gibi davranır, kümelerdeki değişiklikleri izlemek ve bir OpenShift yöneticisi veya kümeleri tarafından erişilmesi gereken durum/yapılandırma verilerini depolamak için aynı anda OpenShift kümelerindeki farklı sunucularda çalışır. Ek olarak, etcd, OpenShift yöneticisinin keşif hizmetini desteklemesine olanak tanır, böylece dağıtılan uygulama hizmete dahil edilmek üzere kullanılabilirliklerini beyan edebilir.
OpenShift etcd için key-value store aracılığıyla , OpenShift Cluster için tüm yapılandırmaları depolar. Verileri tablo biçiminde depolayan geleneksel veritabanından farklıdır. Etcd, her kayıt için, birini güncellerken diğer kayıtları engellemeyen bir veritabanı sayfası oluşturur. Örneğin, birkaç kayıt ek sütunlar gerektirebilir, ancak aynı veritabanındaki diğer kayıtlar için gerekli olmayanlar olabilir. Bu, veritabanı içinde artıklık yaratır. Etcd, OpenShift için tüm kayıtları güvenilir bir şekilde ekler ve yönetir. OpenShift masterda yer alan API sunucusu bileşeni, farklı kümelere yayılmış bileşenlerle etcd ile iletişim kurar. Etcd, sistem için istenen durumu ayarlamak için de yararlıdır.
Etcd kritik bir bileşendir ve etcd kümenizi kaybederseniz tüm cluster’ınızı kaybedebilirsiniz.
CI/CD işlem hattınız için ayrılmış bir küme kullanın
- CI/CD pipeline için ayrılmış bir küme kullandığınızda, bu, pipeline tarafından kullanılan kaynakların OpenShift üzerinde çalışan diğer uygulamalardan ve hizmetlerden yalıtılmasını sağlar.
- Bu, pipeline’a veya kümedeki başka herhangi bir uygulamaya kötü amaçlı kod eklenmesi riskini azaltmaya yardımcı olur.
- Ayrıca, ayrılmış bir küme kullanmak, pipeline’a erişimi daha kolay denetlemenize ve etkinliğini daha yakından izlemenize olanak tanır.
Her uygulama ortamı için ayrı projeler oluşturun
- Her ortam için ayrı projeler oluşturarak, bir projedeki kaynakların başka projedeki kaynaklardan yalıtılmış olmasını sağlayabilirsiniz.
- Bu, ortamlar arasında yetkisiz erişimi ve veri sızıntısını önlemeye yardımcı olur.
- Ayrıca, belirli kullanıcılara veya gruplara erişimi kısıtlamak gibi, her ortama farklı güvenlik ilkeleri uygulamanıza olanak tanır.
- Son olarak, değişiklikleri izlemeyi ve her ortamdaki etkinliği izlemeyi kolaylaştırır.
OpenShift API erişimini kısıtlayın ve denetim altına alın
- OpenShift API, kullanıcıların uygulamalarıyla etkileşime girmelerini ve uygulamalarını yönetmelerini sağlayan arayüzdür.
- Ayrıca, kötü niyetli aktörler tarafından ortamınıza erişmek için kullanılan arabirimle aynıdır, bu nedenle ortama kimlerin erişebileceğini sınırlamak önemlidir.
- Bunu yapmanın en iyi yolu, rol tabanlı erişim denetimi (RBAC) kullanmaktır.
- Bu, hangi kullanıcıların OpenShift API’sine erişimi olduğunu ve hangi eylemleri gerçekleştirebileceklerini tanımlar.
- Ek güvenlik için kimlik doğrulama belirteçleri veya sertifikaları kullanmayı da düşünmelisiniz.
- Son olarak, kullanıcı izinlerini düzenli olarak gözden geçirdiğinizden ve gereksiz erişimleri iptal ettiğinizden emin olun.
Secret ve Sertifikalara erişimi kontrol altında tutun ve kısıtlayın
- Secret ve sertifikalar, kullanıcıların, uygulamaların ve hizmetlerin kimliğini doğrulamak için kullanılır.
- Bu secret ve sertifikaların güvenliği ihlal edilirse, saldırganlar OpenShift ortamınıza erişebilir ve potansiyel olarak ciddi hasara neden olabilir.
- Bu tehdide karşı korunmak için, rol tabanlı erişim denetimi (RBAC) kullanarak secret ve sertifikalara erişimi kısıtlamanız gerekir.
- Bu, OpenShift ortamınızda depolanan hassas bilgilere yalnızca yetkili personelin erişmesini sağlayacaktır.
- Ek olarak, OpenShift’te depolanan tüm secret ve sertifikalar için şifreleme kullanmalı ve ele geçirilme riskini azaltmak için bunları düzenli olarak değiştirmelisiniz.
Uygulamalar arasında uçtan uca TLS kullanın
- TLS (Aktarım Katmanı Güvenliği), uygulamalar arasında güvenli iletişim sağlayan bir şifreleme protokolüdür.
- Ağ üzerinden gönderilen verilerin şifrelenmesini ve yalnızca hedeflenen alıcı tarafından şifrenin çözülebilmesini sağlar.
- TLS kullanmak; OpenShift ortamınızı, aktarım sırasında, hassas verileri ele geçirmeye veya değiştirmeye çalışabilecek kötü niyetli aktörlerden korumaya yardımcı olur.
- Maksimum güvenliği sağlamak için, tüm uygulamalarınızı iletişim için TLS kullanacak şekilde yapılandırmanız gerekir.
- Buna hem iç hem de dış iletişim dahildir.
- Ayrıca, TLS sertifikalarınızı en son güvenlik standartlarıyla güncel tutmak için düzenli olarak güncellediğinizden emin olun.
Ağ erişim kurallarını doğru kullanın
- Network Policy, OpenShift’te çalışan uygulamalar arasındaki iletişimi denetlemenizi sağlar.
- Bu, birbirleri ile iletişim halinde olan hizmetlerin izinlerini kısıtlayabileceğiniz ve ayrıca dış kaynaklardan erişimi kontrol edebileceğiniz anlamına gelir.
- Network Policyleri etkinleştirerek, cluster alanınıza yalnızca yetkili trafiğe izin verilmesini sağlayabilirsiniz.
- Network Policylerini, uygulamanızın farklı bölümlerini segmentlere ayırmak için de kullanabilirsiniz, böylece bir parçanın güvenliği ihlal edilirse sistemin geri kalanını etkilemez.
- Network Policyleri, herhangi bir OpenShift dağıtımı için önemli bir güvenlik önlemidir ve mümkün olan en kısa sürede etkinleştirilmelidir.
Rol Bazlı Erişimi DOĞRU ve EKSİKSİZ Yapılandırın
- RBAC, Rol Tabanlı Erişim Kontrolü anlamına gelir ve OpenShift ortamınızdaki hangi kaynaklara kimin erişimi olduğunu kontrol etmenizi sağlayan bir sistemdir.
- RBAC önemlidir, çünkü yalnızca yetkili kullanıcıların ihtiyaç duydukları kaynaklara erişebilmelerini sağlamaya yardımcı olur.
- Ayrıca, kullanıcıların olması gerekenden daha fazla erişime sahip olmamasını sağlar.
- Bu, yetkisiz erişim veya kaynakların kötüye kullanılma riskini azaltmaya yardımcı olur.
- RBAC uygulamak için roller oluşturmanız ve bunları kullanıcılara atamanız gerekir.
- Daha sonra belirli kaynaklara erişim izni vermek veya erişimi reddetmek için bu rolleri kullanabilirsiniz.
- Bu, OpenShift ortamınızı güvende tutmanıza yardımcı olur ve yalnızca doğru izinlere sahip olanların ihtiyaç duydukları kaynaklara erişebildiğinden emin olursunuz.
Node’lara SSH Erişimini kısıtlayın
- SSH erişimi etkinleştirildiğinde, kullanıcıların doğrudan düğümlerde oturum açabilir, potansiyel olarak hassas verilere erişebilir, kümenin güvenliğini tehlikeye atabilecek değişiklikler yapabilir.
- Doğrudan SSH erişimini devre dışı bırakarak, düğümlere yalnızca yetkili personelin erişebilmesini ve yapılan değişikliklerin güvenli bir kanal üzerinden yapılmasını sağlayabilirsiniz.
- Doğrudan SSH erişimini devre dışı bırakmak için OpenShift ortamınızı LDAP veya Active Directory gibi bir kimlik doğrulama sağlayıcısı kullanacak şekilde yapılandırmanız gerekir.
- Bu, düğümlere kimlerin erişebileceğini ve hangi eylemleri gerçekleştirebileceğini kontrol etmenizi sağlar.
- Ek olarak, ek güvenlik için iki faktörlü kimlik doğrulama kullanmayı da düşünmelisiniz.
Konteyner imajlarını sıkılaştırın
- Konteyner imajları, OpenShift uygulamalarının yapı taşlarıdır ve bir uygulamayı çalıştırmak için gereken tüm kodu ve yapılandırmayı içerir.
- Konteyner imajlarınızı sağlamlaştırmak için, yalnızca güvenilir temel görüntülerin kullanıldığından emin olarak başlamalısınız.
- Ayrıca, imaja dahil edilen tüm üçüncü taraf kitaplıklarının veya paketlerinin güncel ve güvenli olduğundan emin olmalısınız.
- Dağıtmadan önce imajdaki güvenlik açıklarını algılamak için güvenlik tarama araçlarını kullanmanız gerekir.
- Son olarak, konteyner imajlarınızı güvende tutmak için düzenli olarak izlemeli ve güncellemelisiniz.
