background

Azure Kubernetes Service Püf Noktaları — 2

Azure Kubernetes Service Püf Noktaları — 2

2. Bölüm — Cluster Güvenliği

Erişim

  • Cluster güvenliği konusundaki en önemli konulardan biri API Server’a erişimin kısıtlanmasıdır. Eğer API Server’ı dışarıya tamamen kapatmak istiyorsanız private bir cluster kurarsınız. Private cluster, private link’e ait tüm kısıtlamalara tabidir. Bunun dışında farklı kısıtlamaları da vardır. İkinci yöntem ise public bir cluster kurup API Server erişiminin yalnızca belirli ip’lerden yapılmasına izin vermektir. Böylece, örneğin şirket network’ünüz dışından cluster’ınızın API Server’ına erişilmesini engelleyebilirsiniz.
  • API Server’a erişirken herhangi bir IP kısıtlaması yapmak istemiyorsunuz, cluster’ınızı da public kurdunuz fakat API Server erişimini Active Directory ile yapmak istiyorsunuz diyelim. Azure Active Directory ile Kubernetes RBAC’i entegre ederseniz API Server erişimini kolayca kısıtlayabilirsiniz. Ayrıca kimin admin haklarıyla çalışıp kimin standart kullanıcı olarak çalışacağını Azure Kubernetes Service Cluster Admin Role ve Azure Kubernetes Service Cluster User Role yetkileriyle yönetebilirsiniz.
  • Azure Active Directory’yi cluster’da enable ettiğinizde Kubernetes RBAC üzerinden örneğin hangi AD kullanıcızın hangi namespace’te ne yapabileceğine kadar karar verebilirsiniz.Örneğin bir kullanıcı grubuna yalnızca tek namespace’e yetki verirseniz o kullanıcı grubu bu namespace dışındaki kaynaklara erişemeyecektir.
  • AAD ile ilgili son bir not: Contributor rolü Azure’da çok yetkili bir roldür. Eğer kullanıcılarınızın admin olarak cluster’a erişmesini istemiyorsanız, kullanıcının bağlı bulunduğu resource group veya subscription altında Contributor değil Reader yetkisi vermeniz gerekir.

Cluster Güvenliği

  • Container’ların node kaynaklarına erişimi sınırlanmalıdır. root yetkisi podlara verilmemelidir. root yetkisi verilen pod üstünde bulunduğu node’un işletim sisteminde tüm kaynaklara erişebileceği için, node’un tamamını kullanılmaz hale getirebilir. Pod manifest’te allowPrivilegeEscalation: false kullanılarak root erişimi engellenebilir. Container hareketlerini daha detaylı kontrol etmek için AppArmor ve seccomp gibi built-in Linux güvenlik özlellikleri kullanılabilir.
  • App Armor: AKS Node’larında default açık gelir. Application seviyesinde erişimleri kontrol eder. /proc ve /sys folder’larının çoğuna erişimi kısıtlar.
  • Secure computing: Process seviyesinde çalışır. Birçok hareketi kısıtlamaya yarar. Örneğin chmod kullanması engellenebilir.
  • Bütün bu güvenlik kurallarını kontrol etmek için lisanslı tool’lar kullanabilirsiniz. Örneğin Twistlock hem image registry’nizi, hem cluster’ınızda ayağa kalkmaya çalışan container’ları tarar. Hem bu container’ların runtime’da hangi komutları çalıştıracağını, hem hangi container’ın hangi container’a erişebileceğini, vs belirler. Bütün vulnerability’leri sınıflandırılmış olarak görebileceğiniz dashboard’lar sunar. Hem de bütün bu kurallara göre alarm mekanizmaları kurar, policy’ler tanımlamanıza izin verir.

Up-to-date Cluster

  • Kubernetes upgrade’lerini düzenli olarak çalıştırmak gerekir. az aks upgrade node’ları tek tek drain edip güvenli şekilde upgrade edilebilir. Ama upgrade sürecini tetikleyecek governance süreci manuel olarak yönetilmelidir.
  • Linux node update’leri ve reboot’ları kured ile gerçekleştirilebilir. AKS, Linux security fixlerini otomatik indirir ve kurar ama reboot gerekiyorsa bunu yapmaz. kured pending reboot’ları bulur ve aynı anda tek node olacak şekilde nodeları restart eder. kured ile Prometheus’u entegre edebilir ve ne zaman restart edeceği kontrol edilebilir.

Container Image Yönetimi

  • Image güvenlik açıkları sürekli taranır ve iyileştirilir. Twistlock veya Aqua kullanarak imajlar CI/CD süreci içinde taranabilir.
  • Uygulamaların kullandığı base imajlar güncellendiğinde otomatik olarak yeni imaj build edilmesi önerilir. Örneğin dotnet runtime’da bir security fix gelmişse bunun uygulamaya yansıması sağlanmalıdır. Azure Pipelines ve Jenkins ile bu yapılabilir.

Network

  • kubenet ve Azure CNI network mode’ları karşılaştırılıp seçim yapılır. kubenet performans önceliği olmayan cluster’larda tercih edilebilir. Var olan virtual networklerle ve on-prem networklerle entegrasyon için ise Azure CNI kullanılır. Not: Azure CNI’da podlar bireysel olarak IP alır ve bu sayede daha hızlı erişilebilirler. Extra routing e gerek kalmaz. Azure CNI kullanıldığında virtual network ayrı bir resouce group altnda olur. AKS cluster service principal’ın en az Network Contributor yetkisiyle bağlanması gerekir.

  • Azure CNI kullanıyorsanız AKS subnet’lerinin IP range’lerini iyi ayarlamalısınız. Bu range’ler node, pod ve network resource’larını kapsayacak kadar büyük olmalıdır. Hatta scale out ve node upgrade’leri için de ekstra ip’lere ihtiyaç olacaktır, bunlar da göz önünde bulundurulmalıdır.

  • Ingress ile trafik dağıtılır. Ingress controller ve ingress path’ler ile vs tek ip üzerinden birden fazla uygulamaya erişimi sağlar. Ingress controller’lar Linux node’larda koşmalıdır (IpTables)
  • Web Application Firewall (WAF) ile trafik güvenli hale getirilir. Barracuda WAF for Azure gibi WAF’larla potensiyel saldırılar önlenir.

Depolama

  • AKS üzerinde volume kullanan bir uygulama ayağa kaldıracaksanız uygun storage tipini seçmelisiniz. Production’daki kritik dataları tutmak için disk tipi mutlaka SSD olmalı (premium). Ayrıca birden fazla concurrent connection olduğu durumlarda network-based storage planlanabilir. Arşiv gibi datalar standart’ta (hdd) tutulabilir. AKS kurduğunda iki storage-class gelir:


    1 — default: Azure standard storage. Az kullanılan ve performans endişesi olmayan cluster’larda kullanılabilir. Arka planda HDD kullanır.

    2 — managed-premium: Azure premium storage. Performans odaklıdır. Production’da kullanılması tavsiye edilir. Arka planda SSD kullanır.


  • Her iki disk tipinde de pod (ve onun controller’ı) silinirse disk silinir. Yani Azure’un size sağladığı default storage class’larda uygulamalar silinirse datalar da silinir. Dataları korumak için datayı koruyan (retain) bir storage class yaratmak gerekir. Bunun için aşağıdaki gibi bir script kullanılabilir:


    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
    name: managed-premium-retain
    provisioner: kubernetes.io/azure-disk
    reclaimPolicy: Retain
    parameters
    storageaccounttype: Premium_LRS
    kind: Managed

  • Node’ların size’ı belirlenirken storage ihtiyaçları da göz önüne alınmalıdır. VM’leri seçerken mutlaka storage performansına bakılır. Node isimleri s ile bitenler SSD destekleyen VM’lerdir. Production kullanımında mutlaka bu VM’ler kullanılmalıdır.
  • Volume’ler dinamik olarak provision edilir, PVC kullanılır. Reclaim policy’ye dikkat edilmelidir.
  • Data’ların backup’ı mutlaka alınmalıdır. Azure Site Recovery veya Velero kullanılabilir.

Devamlılık ve Disaster Recovery

  • Birden fazla bölgede AKS cluster’ı yaratılması önerilir. Bölgeleri seçerken availability ve paired regions kontrol edilir. İki ayrı bölgede kurulan cluster’lar hot/hot, hot/warm veya hot/cold olarak kullanılabilir. Bu durumda uygulamalar iki cluster’a birden deploy edilmelidir.
  • Eğer hot/hot kullanılıyorsa, yani birden fazla cluster ayakta ve hizmet veriyorsa, Azure Traffic Manager kullanılır. Azure Traffic Manager müşterileri en yakınlarındaki cluster’a yönlendirir ve performans düşüşünü engeller.
  • Container registry’leri geo-replicate edilir. Her cluster imajları kendi region’ındaki registry’den çeker. Bu sayede iki farklı cluster’ın registry erişimleri daha hızlı, daha güvenli ve daha ucuz çalışır.
  • State’ler (durumlar) container’da tutulmamalıdır. 12 factor app’e uyumlu kod geliştirilmelidir. Bu bambaşka ve uzun bir makalenin konusu olmakla birlikte, AKS üzerine çıkacağınız uygulamalar mümkün olduğu kadar cloud native şekilde yazılmış olmalıdır. Dosya bağımlılığı varsa Azure DB’ler veya Azure Storage’lar kullanılabilir.
  • Storage migration plan oluşturulur: Gluster, Ceph, Rook veya Portworx kullanılır.

Geliştirme

  • Development için Azure Dev Spaces kullanılabilir. Microservice mimarsinde yazılmış bir uygulamanız olduğunu düşünün. Bir servisi debug etmek diğer servislere bağımlılıkları sebebiyle işkenceye dönüşebilir. Azure Dev Spaces sizin local development ortamında debug ettiğiniz servisi AKS üzerindeki diğer servislerle konuşturarak cluster üzerinde debug deneyimi yaşatır ve debug işlemlerini çok kolaylaştırır.
  • VS Code Kubernetes extension’ının kullanılması önerilir.

AKS kurarken ve kullanırken dikkat edilmesi gereken pek çok maddeye değindik ama yazdıkça aklıma daha fazlası geliyor. Örneğin izleme (Azure Monitor, App Insights, Log Analytics, Prometheus, Jaeger, Kiali), loglama (Log Analytics, ELK/EFK, vb.), performans izleme (New Relic, AppDynamics, Dynatrace, vb.) gibi konular ve yaşadıkça öğrenilen deneyimler var. Hepsini iki makaleye sığdırmak kolay değil. O yüzden şimdilik burada bırakalım. Geri kalanlar başka makalelerin konusu olsun. Okuduğunuz için teşekkürler.

Kaynak:

Nasıl yardımcı olabiliriz?