Uygulamalarımızın güvenlik açıkları ve potansiyel bug’larını tespit etmek için kullandığımız Static Application Security Testing ya da kısa adıyla SAST tool’u denildiğinde ilk akıla gelen isimlerden biri de SonarQube. Bu yazıda “SonarQube nedir?”e girmeyeceğim için detaylı bilgi için buraya bakabilirsiniz.
SonarQube kurulumu ile ilgili kendi dokümantasyonu dışında internette de bir çok makale bulabilirsiniz. Hatta incelemek isterseniz Microsoft’un SonarQube Hosted On Azure App Service adında bir blogpost’u da var. Kurulum için birden fazla yöntem var, ama siz kendiniz için en uygun yöntemi seçip onunla ilerleyebilirsiniz. Eğer Azure üzerinde düşünüyorsanız, bir kaç farklı örnek verebilirim: Azure App Service üzerine native çalışacak şekilde ve Azure SQL kullanarak, SonarQube ve kullanacağınız veri tabanının (MSSQL, PostgreSQL) Docker imajları ile Azure App Service üzerinde Docker Compose kullanarak çalıştırma gibi senaryoları çoğaltabilirsiniz. Bu yazıda ise kurulumu aşağıdaki servisleri kullanarak yapacağım:
1. Azure App Service
Azure App Service üzerine SonarQube kurulumu yaparken native olarak değil de container olarak tercih etmemin bir nedeni güncelleme işleminin biraz daha kolay olması. Güncelleme için yapmanı gereken mevcut container imajını yenisi ile değiştirmek. Veri tabanını ayrı bir servis üzerinde kullanacağım için bu işlem herhangi bir veri kaybına sebebiyet vermeyecektir, tabii veri tabanı tarafında bu kadar rahat olamayacağımız için o tarafta yedekleme konusunda dikkatli olmakta fayda var.
Web App oluştururken sistemin çalışabilmesi için planları sistemin çalışabileceği minimum seviyede seçmeye çalıştım. Resim-1‘de de göreceğiniz gibi standart bir web app oluşturma işlemi gerçekleştiriyorum.
Resim-1
Docker sekmesine docker image ve tag değerlerini sonarqube:lts-community olarak belirtiyorum (Resim-2).
Resim-2
2. Azure Virtual Network
Veri tabanına uygulama haricinde dışarıdan erişilmesini istemediğim için veri tabanına geçmeden önce bir VNET oluşturacağım. VNET oluştururken 2 tane subnet ekleyeceğim. Bunlardan bir tanesi web app (10.0.0.0/24), diğeri de veri tabanı (10.0.1.0/24) için. İki subnet de aynı VNET içerisinde oldukları birbirleri ile haberleşlemeri için ayrı bir konfigürasyon ya da ek bir servis ihtiyacımız olmayacak (Resim-3). Güvenlik için ek olarak Firewall da ekleyebilirsiniz, bu örnekte eklemedim.
Resim-3
3. Azure Database for PostgreSQL
Veri tabanı seçiminde Azure üzerinde PostgreSQL kullanacağım ve Resim-4‘te de göreceğiniz gibi tavsiye edilen şekilde Flexible Server tercih edeceğim.
Resim-4
Burada önemli olan kısım Networking, yani VNET ayarlarını yapacağım kısım. Diğer kısımları istediğiniz şekilde ayarlayabilirsiniz. Virtual network ayarlarında biraz önce oluşturduğum VNET’i ve veri tabanı için oluşturduğum sonar-db isimli subnet’i seçiyorum (Resim-5).
Resim-5
Buraya kadar sadece Azure üzerinde kaynakları oluşturdum. Buradan itibaren de yapmam gereken bir kaç konfigürasyon işlemi var.
Azure App Service oluşturma sırasında VNET ile ilgili bir ayar yapmamıştım. Web app internet erişimine açık olacağı için, burada yapacağım ayar uygulamanın outbound trafiğini, VNET içerisinde web app için tanımladığım subnet’e yönlendirmek.
Resim-6
Bunun için de web app’in network ayarlarına gelip Outbound Traffic altında yer alan VNET integration‘a tıklıyorum (Resim-7).
Resim-7
VNET ayarlarını tamamladıktan sonra, PostgreSQL connection string bilgilerini Application settings altına tanımlıyorum.
- SONAR_JDBC_URL:jdbc:postgresql://<Azure Database for PostgreSQL Server name>:5432/sonar
- SONAR_JDBC_USERNAME: Azure Database for PostgreSQL oluştururken verdiğiniz kullanıcı
- SONAR_JDBC_PASSWORD: Azure Database for PostgreSQL oluştururken verdiğiniz şifre.
Son olarak da bir workaround yapacağım. “Max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]” hatasını geçebilmek için Elasticsearch bootstrap check’i disable etmem gerekiyor. Bu nedenle de SONAR_ES_BOOTSTRAP_CHECKS_DISABLE değerini true olarak set ediyorum. Bu konuda detaylı bilgi için buraya tıklayabilirsiniz.
Resim-8
Application settings’i kaydedip, web app’i restart ettikten sonra artık sırada SonarQube’e giriş yapıp her şeyin çalıştığını kontrol etmek var. Ama maalesef göreceğiniz şey Resim-9‘deki ekran :)
Resim-9
Her şeyi doğru yaptığımı (?) varsayarak hatanın kaynağını anlamak için App Service Monitoring altında yer alan Log stream ekranın gidiyorum ve web app tekrar restart ederek buradan logları takip ediyorum, gördüğüm ile hata: “Database ‘sonar’ does not exist” (Resim-10).
Resim-10
Oluşturduğum Azure Database for PostgreSQL kaynağının Settings sekmesindeki Databases‘a giderek sonar adında yeni bir veri tabanı oluşturuyorum (Resim-11).
Resim-11
Web app’i tekrar restart ettikten sonra, web app url’ine gittiğimde ise artık SonarQube login sayfasını görebiliyorum. Geçici kullanıcı adı admin ve şifresi admin olarak girdikten sonra yeni bir şifre belirlemem gerekiyor. Sonra Administration menüsünde System altından Resim-12‘de göreceğiniz gibi veri tabanının PostgreSQL olduğunu görebiliyorum.
Resim-12
NOT: Eğer herhangi bir veri tabanı ayarı yapmadan SonarQube container’ını çalıştırırsanız, internal H2 veri tabanı ile çalışacak ve bu ekranda “H2 database should be used for evaluation purpose only” şeklinde bir mesaj göreceksiniz. Mesajdan da anlaşıldığı üzere bu sistemin çalışmasını test etmek amaçlı bir veri tabanı ve production için önerilmiyor.
Referanslar
Azure Database for PostgreSQL – Flexible Server | Microsoft Learn
SonarQube Hosted On Azure App Service – Developer Support (microsoft.com)
TAGs: Azure, Azure App Service, Azure Web App, Azure Database for PostgreSQL, PostgreSQL, SonarQube, Sonar, Azure VNET, VNET, SAST, Static Application Security Testing
