Enterprise seviyede container stratejisi belirlenirken en önce düşünülmesi gereken şey güvenlik olmalıdır. Başarılı bir container güvenlik stratejisi container’ın yaşam döngüsünün üç ana bileşeni olan Build, Deploy ve Run aşamalarının her birine entegre olmalıdır.
- Build
- Deploy
- Run
Tüm bunların yanında önemli olan bir diğer durum ise container’ın yaşam döngüsünün yanında container’ları üzerinde çalıştıran alt yapının da düzgün şekilde configure edilmiş olması gerekir. Bu konfigürasyonlar düzgün yapıldığı taktirde doğru seçilmiş bir container security tool’u cluster altyapısının, orchestrator mekanizmasının ve containerized edilmiş uygulamanın güvenli olmasını sağlayacaktır.
Build Phase:
- Var olan bir problemin build aşamasında saptanması run time’da saptanmasından daha efektiftir. Ayrıca bir çok team tarafından kullanılan base bir imaj üzerindeki sorunun build aşamasında giderilmesi runtime’a düzeltilmeye çalışılmasından daha efektif olacaktır.
- Container imaj security denildiğinde akla gelen ilk bileşen Vulnerability taramasıdır. Container security çözümleri bu taramaları oldukça esnek bir biçimde yapıp saptanan tehditlerin otomatik olarak bloklanmasını sağlarlar.
- Uygun bir container security çözümleri ayrıca build aşamasında security practise’lerine uygun olarak compliance ölçümüde yapmalıdır. Örneğin developer’lar için kullanışlı olabilecek apt-get,curl gibi araçlar atak yüzeyini genişlettiği için son imaj içerisinden silinmelilerdir.
- Container security tool’ları ayrıca uygulamaları ve bunları çalıştıracak yetkili kullanıcıları da kontrol ediyor olmalıdır. BUnları organizasyon security policy’lerine bağlı kalarak yapılacak compliance taramaları ile handle etmelidir.
| Özellik/Fonsiyon | Neden Gerekli? |
| IMAGE ASSESSMENT | |
| Problemlerin saptanmasında imaj konfigürasyonu ayarları analiz edilir. Bu ayarlar build işleminde kullanılan Dockerfile yönergeleriniuser identity konfigürasyonlarını ve environment variable’ları içerir. | Bu aşama paketler içerisindeki bilinen zaafiyetlerin belirlenmesini sağlar. Özetle zaafiyetlerin belirlenmesinde her hangi bir scanner’ın kaçırdığı bir durumu saptayan ek bir güvenlik katmanıdır. |
| Imaj bileşenlerindeki zaafiyetlerin belirlenmesi | Zaafiyet içeren versiyonlara sahip imaj bileşenlerini kullanmak oldukça risklidir. Bu zaafiyetleri build aşamasında saptamak risklerin production ortamına taşınmasını engeller. |
| Registry’ler içersinde builtin bulunan scannerlardan dataların alınması | Eğer repository ile böyle bir scanner özelliği geliyorsa mevcut container security tool’unun mevcut scanner’dan data alabiliyor olması gerekir. Böylece mevcut security context’i hakkında container security tool’u aware olur. |
| Belirli bileşen ve imaj katmanlara zaafiyetleri ve konfigürasyon problemlerinin bağlamak | Base imaj katmanlarındaki zaafiyet ve diğer problemler genellikle farklı takımlara ait olabilir. Bu sebeple zaafiyetlerin hangi imaj katmanına bağlı olduğunu belirlemek önemlidir. |
| Hem fixable hemde gelecek aletlerden kaçınmak için fixable olmayan zafiyetlerin belirlenmesi | Bazen OS distributor’lar yada opensource maintainer’lar bir zaafiyeti asses edebilir fakat bunu düzeltmek için bir fix yayınlamayabilirler. Bu yüzden development teamin workflow’larını bu sebepten ötürü durdurmak üretkenliği etkiler. |
| RESPONSE | |
| CI building fail edilmesi | Build’in belli bir zaafiyetten ötürü fail edilmesi developer’lara hızlı şekilde aksiyon alma fırsatı verir. |
| Koşul üzerinde customize edilmiş kontrollere izin verme | Agresif kontroller development takımlarının security kontrollerini disable etmesine sebep olabilir. Genelde çok sıkı ve realistic olmayan kontroller bu tarz sonuçlara sebep olur. |