Category: Powershell

Detayları ile Azure Frontdoor ve Application Gateway

Uzun zamandır vakit harcadığım hizmetlerden bir kaçı olan Azure Front Door ve Application Gateway ikilisinden bu yazımızda bahsedeceğim. Temel anlamıyla bu yazı serisinde hizmetlerin çok detaylarına girmeyi düşünmüyorum fakat avantajlarını ve dezavantajlarını görebileceğimiz bir yazı seri olacak. Seri sonunda en azından sizlere bu servislerden hangisini ne için seçmeniz gerektiğini aktaran bir sonuca kavuşturmayı hedefliyorum. Bildiğiniz gibi şirket/organizasyon içerisinde servisleriniz var bunlar; http veya https olarak public bir şekilde hizmet verebilen (IaaS, PaaS farketmez.), Function ve Web API vs hizmetleriniz olduğu düşünelim ve tüm bu servislerini Internet ortamına açmak istediğimiz zaman güvenlik kriterlerini sağlayan özellikle Web Application Firewall özelliğine sahip cihazlar üzerinden Internet dünyası ile buluşturup müşterilerimizi hizmet vermeyi hedeflemekteyiz. En temel haliyle Web Application Firewall hizmeti sunan cihazlar/servisler bizlere bir web uygulamasına giden ve uygulamadan gelen tüm HTTP trafiğini filtreler, inceler ve bloklar. Bir Web Application Firewall (WAF) ürününün normal bir güvenlik duvarından farkı, sıradan güvenlik duvarları sunucular arasında bir güvenlik geçidi olarak hizmet verirken, WAF ürününün istediği web uygulamalasına ait içeriği filtreleyebilmesidir.HTTP trafiğini inceleyerek, SQL Enjeksiyonu, Siteler Arası Betik Çalıştırma (XSS) ve güvenlik yanlış yapılandırmaları gibi güvenlik zafiyetlerinden kaynaklanan saldırıları engelleyebilmektedir. Bu servisleri/appliance seçerken karışımıza çıkan bir çok seçenek ve sorular ile karışlacaksınız özellikle güvenlik ekibinden gelen soruların başında ‘OWASP’ desteği var mı? – Bu da nedir derseniz eğer kısaca; Open Source Web Application Security Project(OWASP), web uygulaması güvenliği alanında serbestçe erişilebilir makale kaynakları, metodolojiler, belgeler, araçlar ve teknolojiler üreten çevrimiçi bir topluluktur. Bu tarz servislerin, OWASP Community üzerinden sununulan standard güvenlik zafiyeti içerebilecek tüm standardları izlemesi gerçekten oldukça önem teşik etmektedir. Daha fazla detay öğrenmek istiyorsanız lütfen şu sayfa üzerinen bir göz atın derim. Konuya bağlı kalarak, Web Application Firewall hizmeti, günümüzde daha çok güvenlik ekibi tarafından yönetilmektedir. Fakat, Scrum & Agile gibi proje yönetim metodları ile çalışıyor ve her Sprint sonu release yapmak istiyorsanız ve bunun detayı Güvenlik tarafındaki ekibe dokunuyorsa işte o zaman işiniz oldukça zorlaşıyor. Buraya kadar anlattıklarım tamamen, ITSM süreçleri ve yaşadığım deneyimler sonrası çok sıkıcı problemler. Agile ve Scrum gibi proje metodolojileri uyguladıktan sonra yapmak istediğiniz release sonrası çok hızlı bir şekilde production ortama geçerken Firewall veya Web Application Firewall gibi hizmetlerde yapılması gerken değişiklikler olduğu zaman gerçekten sancılı bir sürece döndüğünü göreceksiniz.



Serverless automation using PowerShell Core in Azure Functions – Bölüm 4

Bir önceki yazımızda Visual Studio Code üzerinde ilk fonksiyonumuzu oluşturduk. Hatırlarsanız fonksiyonumuzun adı getResourceStatus olarak belirlemiştik. Fonksiyon bize Azure sanal sunucuların hakkında anlık raporlar (html output olarak) üretmesini sağlamak temel hedefi idi. Bu fonksiyon RESTful isteklerin kabul ediyor olacak ve istediğimiz zaman abonelik içerisinde bulunan sanal sunucuların yapılandırma bilgilerini anlık ve her yerden bir web request ile raporlayabileceğiz.

Fonksiyonumuzu deploy etmeden önce bildiğiniz gibi Azure Subscription içerisine Azure Function App deploy etmemiz gerekiyor. Bunu dilerseniz Azure Portal, ARM Template, VSCode, Powershell yapabilirsiniz. Bu yazı içerisinde size aşağıdaki Powershell Script’ini takip ederek Azure Function App oluşturmanızı yardımcı olacak olan kod bloğunu paylaşıyorum.




Serverless automation using PowerShell Core in Azure Functions – Bölüm 3

Artık ilk Event-Based Automation çözümümüzü beraber geliştirebiliriz, senaryomuzu basit ve anlaşılır yapmak için hemen beraber belirleyelim. Başlangıç seviyesi için kesinlikle basit bir senaryodan ilerleyeceğiz. Örneğin, Azure Function ‘HTTP’ trigger (tetikleyicisini) kullanarak parametrik olarak gönderilen sanal sunucunun adına göre Azure Function bizim için HTML bir Report oluşturmasını isteyelim. Giriş yazımızı hatırlarsanız, o kısımda ‘HTTP’ kullanırsak bize bir RESTful HTTP uç noktaları sunar API gibi davranacağından bahsetmiştik. Şimdi ön gereksinimlerimiz neler bunlara bir göz gezdirelim.

  • Azure Subscription
  • Visual Studio Code
  • Powershell Core – 6
  • Visual Studio Code üzerinde AZ Function Core Tools eklentisi

Yukarıda ön gereksinimleri elde ettiğinizi varsayarak çözümü geliştirmeye başlayabiliriz. Önce hemen bir VS Code üzerinde Azure Function projesi oluşturalım. Visual Studio Code üzerinde terminal’e gelip hızlı bir şekilde aşağıdaki işlemleri yaparak yeni bir Azure Function App Projesi oluşturalım.




Serverless automation using PowerShell Core in Azure Functions – Bölüm 2

Fonksiyonlarımız için ne tür Triggers ( tetikleyiciler) kullanabileceğimizden bahsettik ve örneklerini anlattık. Şimdi hız kesmeden Bindings (tam türkçeye çeviremiyorum. Bağlar/Bağlantılar) kavramına açmak istiyorum. Bindings size fonksiyonunuz içerisinden verilere bağlanmanız için bir yol veya yöntem için yardımcı olurlar. Bir önceki yazımızda bildiğimiz gibi Triggers ( tetikleyicilerin ) bize geliştirdiğimiz fonksiyonun hangi servisler tarafından tetiklenebileceğini söyleyebiliyorduk. Örneğin, Azure Queue Servisi ile fonksiyonunuz tetiklenmesini ( yani çalışmasını/aksiyon almasını ) sağlayabiliyoruz. Fakat bu tetiklemeden sonra Storage Queue servisinden gelen veri bizim için fonksiyonun içerisindeki parametreye atanıyor. Bindings kullanmak zorunda değiliz fakat kullanma senaryomuzu biraz daha açmak ister isek, Storage Queue’den bir mesaj geldiği zaman tetiklenecek olan Azure Fonksiyonumla beraber Storage Table tuttuğum transcation verileriminde bindings kullanarak bir parametreye atanması sağlayıp, daha sonra bu verileri karşılaştırabilir ve fonskiyonumun onun sonuca göre çalışmasını sağlayabilirim. Bindings tamamen isteğe bağlıdır. Bu yüzden karşımıza farklı Bindings türleri çıkıyor olacak. Bir önceki yazımızda herhangi bir kod yazmadan tetikleyen servise erişmemizi sağlayacağından bahsetmiştik. Bindings sayesinde yine farklı servislere kod yazmadan erişip bir parametreye atayıp veriler elde edebilir ve onları değerlendirebiliriz.




Serverless automation using PowerShell Core in Azure Functions – Bölüm 01

Öncelikle bu yazı serisine başlamadan şunu göz önünde bulundurmanızı tavsiye ediyorum, yazı içerisinde geçen Azure servislerin detaylı bir biçimde neler yaptığını anlatmayı düşünmüyorum. Bunları anlamak ve kavramak için internet üzerinde örn:’Microsoft Docs’ sınırsız kaynaklara erişme şansınız var. Genel anlamıyla servislerin nerede, ne zaman ve niçin kullanılması gerektiğine değinip servisleri sırası geldikçe ve kullanıma başladıkça sizinle paylaşıyor olacağım. Bu servisleri kullanırken temel veya yüzeysel bir açıklama görebilirsiniz. Fakat bu yazı serisinin temel amacı Serverless hizmetlerini kullarank ve bunlar ile beraber Cloud veya Hybrid otomasyonunun nerelere doğru yelkenler açtığını, son olarakta Powershell Core’un tüm Azure Serverless hizmetlerinde ne/nasıl bir şekilde aktif şekilde röl aldığını anlamanıza yardımcı olmaya çalışacağım.

Uzun süredir Azure Functions ( Serverless Functions ) kullanarak interaktif biçimde Microsoft servislerini deneyimleyip içli dışı olup zaman geçiriyorum. Cloud Engineering departmanlarının even-based cloud otomasyon süreçlerini tasarlıyorum. Azure Functions en sade ve özet haliyle Microsoft’un bize sunduğu Serverless Functions hizmeti olarak karşımıza çıkıyor. İşte tam bu noktada ‘Serverless’ olmasının verdiği avantaj ile Powershell Core esnekliğinide kullanarak Microsoft Azure’un diğer servisleri ile entegre biçimde kullanıp veya başka bir Cloud Provider’ın API/SDK kullanarak farklı otomasyon senaryolarına doğru yelken açabiliyoruz. Azure Functions farklı ‘Run time’ versiyonlarına sahip ve her ‘Run Time’ versiyonunda farklı (.Net veya .Net Core) framework – yani alt yapısı ile karşımıza çıkıyor. Azure Functions App içerisinde run time versiyonlarını daha iyi anlamak için lütfen şu sayfa üzerine göz gezdiriniz. Yazımızın devamında Azure Functions App ‘Run Time 2.x veya 3.x’ kullanarak devam edeceğim. Deneyimlerim doğrultusunda söyleyebilirim ki, ‘Run Time2.x’ den sonra Powershell Core gücünü arkasına alarak çok farklı yenilikler geldi ve Powershell Core ile alt yapı otomasyonu ile uğraşan Developer veya Powershell Developer’ın işlerini kolay hale getirebilcek çözümler sunuyor. Zaten Microsoft Azure Functions Apps ‘Run Time’ 1.x için experimental olarak bizlere kullanıma sunuyordu.




Secure DevOps Kit for Azure – Bölüm 3

Bu bölüm içerisinde, Secure DevOps Kit for Azure – Bölüm 2 isimli makalemizi okuyup, temel abonelik seviyesinde Azure Kaynaklarının güvenliğini tarama komutlarını kullandığınızı düşünerek biraz daha ileriye götürecek senaryolar üzerinde durmaya çalışacağım. Temel tarama komutlarını kullandık ve kavramaya çalıştık artık bundan sonra neler yapabileceğimize odaklanacağız. Bildiğiniz gibi , ‘Get-AZSKSubscriptionSecurityStatus’ kullanılarak manuel bir tarama başlattığımızda, (otomatik olarak) açılan klasör içerisinde CSV dosyasının detaylarına baktığımız zaman AzSK ile yaptığımız taramada değerlendirilen tüm kaynaklar için elde edilmiş bir rapor ve log dosyası sağladığını unutmayalım. Elde ettiğimiz bu dosyaların tümünün detayına ve ne işe yaradıklarını bir önceki yazımızdan ulaşabilirsiniz.

AzSK ile yaptığımız güvenlik kontrollerinde, kontrol hatasını düzeltmek için gereken düzeltme(leri) otomatikleştirilebiliriz. AzSK bu senaryoyu ‘FixControls’ özelliği ile desteklemektedir. Bu özelliğin mevcut yapılan kontroller için AzSK tarafından kullanıcıların talebi ile bu düzeltmeleri uygulayabilmesi için otomatik bir şekilde oluşturabileceği Powershell Script’i yeteneğine sahiptir. Tahmin edebileceğiniz gibi pek çok yapılan kontrol için eğer sorun bulunduysa ve düzeltilmek isteniyorsa, bunların otomasyonu her zaman uygun değildir, çünkü yapılan kontrollerin düzeltilmesiyle ilgili iş akışı veya çalışan servislerin bağımlılıkları karmaşık olabilir. Sonuç olarak, bu özellik tüm kontroller için mevcut olmayabilir veya geçerli olmayabilir. Bu özelliği ‘Get-AZSKSubscriptionSecurityStatus’ komutuna ‘-GenerateFixScript’ parametresini eklediğimiz zaman bizim için abonelik içerisinde bulunan tüm kaynakları güvenlik kontrollerinden geçirir ve herhangi bir uyumsuzluk bulur ise bunlar için Powershell Script oluşturur ve bunu çalıştırmamız, bulunan sorunları düzeltmemiz için yeterlidir.



Secure DevOps Kit for Azure – Bölüm 2

Secure DevOps Kit for Azure araçının kullanıma artık yavaştan girelim. Öncelikle AzSK için Powershell Module nasıl sahip olacağımıza ve ne tür ön gereksinimler olduğuna beraber inceleyelim. Core MS Engineering tarafından bize aktarılan en az aşağıdaki işletim sürümüne ve powershell versiyonuna sahip olmanız gerekiyor.

  • PowerShell 5.0 veya üstü.
  • Windows OS

Not: Bildiğiniz gibi Powershell Core sayesinde cross platform üzerinde Powershell’e sahip olma imkanı bizlere sunuluyor. Bu sayede Windows veya Linux, macOs farketmeksizin Powershell’i kullanabilirsiniz ama bir takım özelliklerinden yararlanma şansınız olmayabilir. Bu yüzden dökümantasyon tarafında henüz resmi bir detay göremedim özellikle Core veya Desktop sürümü olarak yaptığım bir çok testler de Windows üzerinde Powershell Core tarafında pek sorun yaşamadım. Ancak bu yüzden kendi edindiğim tecrübelerim ile paylaşabilirim ki AzSK Powershell Modülünü sorunsuz kullandığımı söyleyebilirim. Bu detay belki önem arz edebilir. Mümkün oldukça Powershell Core kullanarak hayatımı sürdürüyorum. Hızlıca bu Powershell modülüne nasıl sahip olabiliriz beraber görelim.



Secure DevOps Kit for Azure – Bölüm 1

Öncelikle bu yazı serisi içerisinde DevOps ve SecOps kavramlarının ne olduklarının detaylarını girmek istemiyorum, bunların ne tür çalışma prensiplerine sahip olduklarının MsHowto üzerinden veya Internet üzerinden kolayca bulabilirsiniz. Secure DevOps Kit for Azure hakkında bilmemiz en önemli durum, bu araç/tool artık nasıl isimlendirmek isterseniz Microsoft’un geliştirmiş olduğu resmi bir ürünü değil, MS Core Services Engineering & Operations (CSEO) tarafından uygulanan en iyi pratikleri, yapılandırmaları ve güvenlik politikalarını topluluklar ile paylaşma girişimidir. Secure DevOps Kit for Azure (AzSK), Microsoft BT’nin Azure’u benimsemesini hızlandırmaya yardımcı olmak için Microsoft’taki MS Core Services Engineering & Operations (CSEO) bölümü tarafından geliştirildi ve bizlere kullanıma sunuldu. Az Secure DevOps Kit, Yönetim ve Güvenlik üzerindeki kontrolleri sıkı sıkıya korurken, DevOps kültürünün farklı aşamalarında bulut kaynaklarını hızlı bir şekilde taramak, güvenli bir şekilde dağıtmak ve yönetmek için rehberlik sağlamak üzere AzSK ve onun belgelerine herkesin kolaylıkla erişebileceği bir araç veya yol gösterici olarak kullanılmaktadır.



Custom Resource Providers ve Azure Function Kullanım Örnekleri – Bölüm 2

Bir önceki yazımızda Custom Resoırce Providers kavramını tanımlamak ve ona bağlı olan komponentleri anlamak ile ilgilenmiştik. Bu yazımızda ise, Custom Resource Providers tanımlamasının nasıl olduğundan bahsediyor olacağız.

Custom Resource Provider nasıl tanımlanır?

Custom Resource Providers, Azure ile endpoint (Azure Function) arasında karşılıklı ilişkileri tanımlayan bir listedir. Bu karşılıklı tanımlamalar Azure’un herhangi bir endpoint ile nasıl etkileşime girmesi gerektiğini açıklar. Custom Resource Provider’lar bir proxy gibi davranır ve belirtilen endpoint için gelen istekleri alır ve yanıtları onlara iletir. Bu kısımda endpoint arkasında çalışan bizim geliştirdiğimiz bir adet Powershell Core yazılmış Script olduğunu düşünelim ve onu Azure Function hizmetine deploy edip, endpoint olarak kullanacağız Azure Function olmasının sebebi tamamen Azure Servislerinden faydalanmak. Bir Custom Resource Provider iki tür sözleşme/tanımlar modeli belirtebilir bunlar sırasıyla;

  • resourceTypes
  • Actions

Bunlar endpoint tanımlarını belirtirken kullanılır ve her ikiside farklı API özellikleri bizlere sunar ve onlar aracılığıyla etkileşim içine geçilebiliriz.

  • name,
  • routingType
  • endpoint.



Custom Resource Provider ve Azure Function Kullanım Örnekleri – Bölüm 1

Bir süredir yazmak istediğim seri ile karşınızdayım. Öncelike seriyi okumadan önce lütfen Mshowto Blog’u üzerinde ve internette takip edebileceğiniz Azure Resource Manager Template isimli yazıları okumanızı tavsiye ederim. Eğer Azure Resource Manager az bir seviyede aşina iseniz, bununla beraber kendinizi DevOps kültürünün bir parçası olduğunuzu farkettiğiniz zaman Infrastrature As Code ile uğraşmaya başladınız demektir. Temel amacımız bu yazı seri içerisinde vermek istediğimiz veya aktarmak istediğimiz konu Azure Resource Manager’ın bir parçası olan Custom Resource Provider kullanarak ve işin içerisine son zamanlarda gözde servisimiz olan Azure Function dahil ederek bu muhteşem ikilinin aralarında bulunan çalışma ilişkisini göstermek olacak. Bu terimleri yazımızın ilerleyen kısımlarında tek tek açıklıyor olacağım.