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.

Bildiğiniz gibi Powershell üzerinden herhangi bir Modülü dahil etmek istersek bize yardımcı olan cmdlet "Install-Module" olarak karşımıza çıkıyor. Fakat bu komutu yazmadan önce bir konuyu sizinle paylaşmak istiyorum. AzSK Powershell modülü aslında arka tarafta Azure Powershell modülüne ihtiyaç duymaktadır. Bunun temel sebebi ise, AzSK Powershell modülüne sahip olduğunuz ve onun detaylarını incelediğiniz zaman bir çok geliştirilmiş 'advanced-powershell-function'larının olması ve bunların arkasında devamlı Azure Powershell Module ile birlikte gelen cmdlet'ler sayesinde ilgili kaynakların özelliklerini talep ederek iş yapabilmesidir. Örneğin, Azure Subscription seviyesindeki detaylara Secure DevOps Kit for Azure (AzSK) Powershell modüllü erişmek ister ise, Azure Powershell Modülüne ihtiyaç duyacak ve tüm yapılandırma detaylarını bu modül içerisinde bulunan komutlar sayesinde edinecektir. Yukarıda gördüğünüz "Find-Module -Name AzSK -IncludeDependencies -Repository PSGallery" aslında bize AzSK Powershell modülünün ne tür bağımlılıkları olduğunu anlatmaktadır.

Artık AzSK Powershell modülünü Powershell Gallery üzerinden talep edebiliriz. Yukarıda gördüğünüz satır içerisinde (9) kullandığım Powershell komut satırı, benim için AzSK'yı sahip olduğum bilgisayar üzerine indirecek ve bunu sadece sahip olduğum oturum içerisinde kalacak şekilde belirtmiş bulunmaktayım. Scope olarak 'CurrentUser' parametresi bana bu konuda yardımcı oluyor. Repository parametresi ise belirtmek zorunda değilsiniz, çok farklı Repository'ler kullandığım için özellike belirttim eğer tanımlamazsanız PSGallery yani Microsoft'un Windows üzerinde default tanımlamış olduğu Powershell Gallery üzerinden modüle sahip olmaya başlayacaksınız. En sonda kullandığım '-Verbose' parametresi ise 'Install-Module' komutu çalışırken bana arka tarafta yapılanlar hakkında detaylı bilgiler almamı sağlıyor.

Gördüğünüz gibi artık AzSK Powershell Modülüne sahibiz. Modüle içerisinde toplam şimdilik 55 adet cmdlet mevcut ama bir çoğunu bu yazı serisinde tanımaya çalışacağız. Şimdi en temelleri olan Subscription seviyesi bazında Security taramaları gerçekleştireceğiz ve bunun için şimdilik sadece abonelik ile ilgili olanlar ile ilgileneceğim.

İlk bölümde bahsettiğimiz ve konumuzun en temel önem arz eden başlığımız olan 'Subscription Security' yani Azure Aboneliğinin güvenliğinin detaylarına göz gözdirelim. Abonelik içerisinde tarama işlemi başlatmak için, 'Get-AZSKSubscriptionSecurityStatus' function kullanarak bir takım çıktılar/sonuçlar elde edebiliriz. Kullanmaya başladığımız zaman göreceksiniz ki bir çok detayın bu Powershell fonksiyonu tarafından irdelendiğini şahit olacaksınız. Herhangi aboneliği incelemek için bir dizi otomatik tarama gerçekleştirir ve çeşitli güvenlik sorunları, yanlış yapılandırmalar veya eski eserler / ayarlar nedeniyle aboneliğinizin daha yüksek bir risk altında olabileceğinin göstergesi olan koşulları/bulguları sizlere işaretler. Bu fonskiyon aşağıdaki kısımlara tek tek bakarak size bir sonuç oluşturmaya çalışıyor.

Access Control ( IAM ) Erişim kontrolü yapılandırması – abonelik seviyesinde kimlik ve erişim yönetimi ile ilgili sorunlar. ( Abonelik üzerinde bulunan admins/owners, custom-rbac roles, MFA, PIM, SPNs)

Alert Configuration – Azure Aboneliği ve çeşitli azure kaynakları için hassas eylemler için etkinlik uyarılarının yapılandırılması. (Securtiy Center )

Azure Security Center - Azure Güvenlik Merkezi yapılandırması detayları – (Point of contact, VMs Updates, Malware, Extension vb.)

Azure Policy ve Resource Lock- konfigürasyonu – Belirli bir düzeyde tanımlanan Azure Policyler ( Region, VM Size, belirli resource tiplerinin yasaklanması), Resource Lock ve diğer tüm Policy ile yapılabilecek diğer aksiyonlar.Bunun dışında şahsi olarak kullandığım ve sizinde güvenli bir abonelik için Azure Policy ile birlikte çalışan Guest Configuration bakmanızı önerebilirim.

Note: Daha fazla detay için lütfen paylaştığım sayfa üzerinden neden önemli oldukları ve ne seviyede önem gerektirdiklerini anlayabilirsiniz. Lütfen şu sayfaya göz gezdirin.

Yukarıdaki resim üzerinde görüldüğü üzere ilk health check işlemini 'Get-AZSKSubscriptionSecurityStatus' function ile başlattım. Bu komutu çalıştırmadan önce doğal olarak Az Powershell üzerinde tarama başlatalabilmek için ilgili aboneliklere yetkili hesap ile oturum açmanız gerekmektedir. SubscriptionId değerini bu function içerisine gönderdip çalıştırdıktan sonra yukarıda özetle bahsettiğimiz kontrolleri tek tek yapıyor ve sizin için bir sonuç belirlemeye çalışıyor olacak.

İlgili Powershell fonksiyonu bizim için başarılı bir şekilde çalıştı. Yapılan kontroller sonucu ne tür testlerden geçemediğimizin detaylarını Powershell bize Console üzerine yazmış bulunmakta bununla kalmayıp bunları "High", "Critical","Medium" olarak ayırdı. Bunların tüm detayları yukarıda belirttiğim sayfa üzerinde var. İlgili sayfa içerisinde neden seviyelerinin "High",Medium",Critical" olarak ayrıldığını anlayabilirsiniz. Health Check işlemini başlatmak istediğim aboneliğim MSDN olarak belirlemiştim. Üzerinde sadece yaptığım testler olan birazda dağınık bir hesap, yukarıdaki tablo içerisinde bazı adımlardan 'Failed' aldığımı görüyorum. Bunların bazıları "High" ve "Medium" olarak iki kısıma ayrılmış durumda. Yukarıdaki resim içerisinde ayrıca belirttim fakat Powershell fonksiyonu çalışmayı bitirdiği zaman size bir "Windows Explorer" otomatik olarak açıyor olacak ve karşınıza bir takım log dosyaları ve çalıştırdığımız tarama sonucunun daha fazla detaylarını 'CSV' dosyası içerisinde bulabileceksiniz.

Bizim için otomatik bir şekilde output çıktısı oluşturdu, bu dosyalardan en önemlisi CSV detayları ve buna baktığımız zaman hangi tür testlerden başarılı/başarısız olduğumuzu görebileceğiz. Bunun dışında 'Etc' ve 'Visual Studio Enterprise – MCT' folderında Azure aboneliği için tutulan bir takım bilgiler ve Powershell Function çalıştığı süre boyunca Powershell transcript özellğinden faydalanarak console yazılan herşeyin bir çıktısınıda görebiliyorsunuz. İşin özeti bizim için en önemli dosya şimdilik Security Report adındaki dosya olduğunu söyleyebilirim. Şimdi biraz da bu dosya içeriğini inceleyelim.

CSV Dosyasını açtım ve artık içerisindeki değerleri görebiliyoruz. Bizim için nelerin kontrol edildiğini beraber daha rahat anlayabiliriz. Çalıştırdığımız Powershell Function yaptığı tüm testlerin detayları bu kısımda bulunmakta ve CSV dosyasının en sağ tarafında 'Recommendation' kısmına giderek neler yapmanız gerektiğini bulabilirsiniz. Ekran görüntüsü olarak paylaşmadım ama abonelik içerisinde hangi Resource'dan dolayı başarısız sonuçları anlamanız içinde 'CSV' üzerinde 'ResourceId' kısmına bakarak kaynağınızı direk tanıyabilme ve bulma şansınız vardır. Daha fazla detay öğrenmek için lütfen "Visual Studio Enterprise – MCT"(Sizin aboneliğinizin ismi yazacaktır) klasörü içerisinde bulunan 'Subscription.LOG' isimli dosyayı özellikle incelemeyi unutmayın.

Daha farklı bir kullanama yöntemi olan ve parametrik olarak değerler alabilen bu komut, istersek bizlere 'PDF' olarak yukarıda gördüğünüz raporları sunabiliyor. Aslında fikir ve kullanım açısından çok hoş, eğer biden çok farklı aboneliğiniz var ise hepsi için tek tek 'PDF' çıktıları alıp ilgili iş birimlerini bilgilendirebilirsiniz. Gelin beraber kullanım şeklini inceleyelim.

Yukarıda görebildiğiniz gibi yaptığım sadece 'GeneratePDF' parametresini otomatik oluşacak rapor için yatay mı dikey mi olmasına karar vermem oldu. Talep ederseniz ilk kullandığımız komut ( CSV ) sonuna '-DoNotOpenOutputFolder' parametresini eklersek, bizim için herhangi bir 'Windows Explorer' açmayacaktır.

Elde ettiğimiz raporların detaylarına baktığımız zaman bir çok güvenlik kriterleri ele alınmış durumda. Fakat ilgili Powershell komutu içerisine parametrik değerler göndererek almak istediğimiz arama standlarına göre (bunların belirli bir anahtar kelime listesi var örneğin; RBAX, SOX, AuthN) bu değerleri gönderdiğimiz zaman o spesifik bölümler için tarama/health check başlatabiliyorum. Gönderebileceğimiz parametreler ve anlamları aşağıdaki gibidir.

İlk başta bahsetmek istediğim iki adet parametre var. Bunların detaylarını yukarıdaki açıkladım. Paylaştığım bilgi doğrultusunda, bu parametrelerin alabileceği çok fazla değer var ve aşağıda bulunan liste içerisinde parametreleri kullanmaya karar verdiğinizde bu güvenlik etiketlerini kullanarak 'Get-AZSKSubscriptionSecurityStatus' parametre gönderip sadece belirlediğiniz güvenlik denetimine göre sonuç alabilirsiniz.

'FilterTags' ve 'ExcludeTags' alabilecek parametrik değerler yukarıdaki gibi olmalıdır. Şimdi beraber bir örnek yapalım ve gelin nasıl kullanabildiğimizi beraber görelim.

Yukarıda yapmış olduğumuz iki adet farklı örnek bulunuyor. Bu örneklerde görebileceğiniz gibi iki adet farklı tag isimleri göndererek sadece belirlediğimiz güvenlik kriterlerine göre aramalar yaptık. 'SOX' – uyum ve denetimi için 'Get-AZSKSubscriptionSecurityStatus' çalışacak ve ona uygun bir şekilde kontroller yapacaktır.

Diğer farklı bir kullanım yöntemi olan ve parametrik olarak gönderebileceğimiz bölüm ise 'ControlIds' parametresi bize Secure DevOps Kit for Azure için yapılan Control kriterleri bazında filtereleme şansı verecektir. Kullanım şekline beraber bakalım;

Yapmış olduğumuz örnek içerisinde görebileceğiniz üzere, 'ControlIds' parametresi 'Azure_Subscription_AuthZ_Limit_Admin_Owner_Count' eşit olan güvenlik kontrollerine göre rapor oluşturmasını talep ettim ve sadece onun özelinde bana tarama sonucu olan 'CSV' dosyasını yaratıyor olacak.Bu yaptığım aramanın sonucu yine Powershell Console üzerinde görebiliyorum ve ayrıca talep istersem, CSV ve PDF olarak çıktı alma şansım var.

Bu yazımız içerisinde AzSK Powershell modülünün sadece bir komutu olan 'Get-AZSKSubscriptionSecurityStatus' kullanarak nasıl health check raporları almamız üzerine konuştuk. Bir sonraki yazımızda bu Powershell fonksiyonun nasıl kullanıldığına ve ne tür farklı yetenekleri olduğunu anlatmaya devam edeceğiz.

Ö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.

Azure için Secure DevOps Kit'i (bundan böyle 'AzSK' olarak kısaltacağım), DevOps ekipleri için Azure Subscriptions ( Azure Abonelikleri ) ve Resource ( Azure Kaynakları – herhangi bir dağıttığınız kaynak, Storage Account, WebApp, VMs, Key Vaults vb. olabilir) güvenlik gereksinimi gereken her noktayı destekleyen Powershell scriptler, araçlar, eklentiler, yol gösteren dökümanlar ve otomasyon gibi yöntemler sunar. Daha kapsamlı otomasyon kullanmak ve güvenliği alışıla gelmiş/gelmeye çalışan kültürümüze yani DevOps içerisine iş akışlarına sorunsuzca entegre edebiliriz. MS Core Services Engineering & Operations (CSEO) tarafından önemli başlıklar altında derğelendirme açısından ayrılan Secure DevOps Kit for Azure, 6 adet farklı odak noktasıyla nasıl güvenli bir Azure ortamını elde etmemiz gerektiği konusunda yardımcı olmak için tasarlanmıştır. Sırayla bu başlıkları beraber inceleyelim.

Azure Subscription: Güvenli bir Azure Subscription(aboneliği) elde etmek için aslında temel olarak dikkat etmemiz gereken bir takım bileşenler var. Bunların en başında çok iyi ve düzenli bir biçimde tasarlanmış Access Control yani Role-Based Access Control ( Management Group ) gibi konular gelmektedir. Daha sonra yine sizin Subscription ( Azure Aboneliği ) seviyesinde olan Azure Policy mekanizmasının yine çok iyi bir şekilde yapılandırmanız gerekmektedir. Aralarında önemli ilişki olan konular özellikle Subscription, Management Group, Role-Based Access Control ve bunlarla yakından ilişkisi olan tasarım açısından Azure Policy unutmamak gerekir. Bununla beraber Azure AD'nin içerisinde Privilige Identity Management ( Azure Active Directory Premium gereksinimi doğmaktadır.) ise size daha farklı güvenlik katmanı katabiliyor. Abonelik seviyesinde işlem görmeyen Azure Security Center bizlere Free olarak sunuluyor fakat bu hizmet Tenant seviyesinde olduğu için ve güvenlik tarafından sorumlu olduğumuz en önemli hizmet olduğu için Security Center ile ilgili detaylı Policy'ler yazmamız neredeyse şart. Bunun içinde Microsoft sizi Azure Security Center – Standard seviyesine ( Ücretli ödeyerek elde ettiğiniz ) yönlendirmektedir. Tenant seviyesinden yapacaklarımıza ve Abonelike seviyesinde dikkat etmemiz gereken konuları konuştuk aslında diğer bir konu ise, kaynak seviyesindeki güvenlik detayları işte tam bu noktada sizi Azure Resource Lock yapılandırması göstermektedir. Bunun dışında olmazsa olmaz olan Azure Alerts çok faydalı olduğunu unutmamak gerekiyor. Tüm bu yapılandırmaların sonucunda Azure Subscription seviyesinde güvenlik temeline uyum sağlamış olacağız (Secure DevOps Kit for Azure bize sunduğu denetim detaylarına göre, bunların hepsi aslında, bir çok uyum denetimi standardları takip edilerek geliştirilmiş.) .Aynı zamanda yapılan tüm ayarların güvenli bir temele uygun olup olmadığını kontrol etmek mümkün olmalıdır. Özetle, bir çok Security BaseLine takip edilmelidir. ( Five Disciplines of Cloud Governance, CIS Microsoft Azure Foundations Benchmark)

Enable secure development: Herhangi bir uygulama/hizmetinizi develop ederken, varsayalım ki daha kuluçka döneminde veya orta seviye aşamalarında iken, Secure DevOps Kit for Azure bizlere developer ekibinin Cloud-Based bir hizmetin/ürün özelinde nasıl güvenli kod yazmalarının gerektiğini ve bulut uygulamalarının güvenliğinin nasıl sağlanacağını minimum seviyede bilmesi, yapılandırmasını test etme becerisine sahip olmaları gerektiğini bahsediliyor. MS Core Services Engineering & Operations (CSEO) ekibi bu kısımda bizler için Azure'da çeşitli kaynak türlerinin güvenliğini kontrol edebilen bir kavramı hayatımıza sokuyor ve buna Security Verification Tests (SVTs) adını veriyor. Bu yöntemi Microsoft tıpkı bir Software Development sürecindeki Build Verification Tests ( BvT) benzetiyor aslında, Build Verification Tests ( BvT) en yalın haliyle daha ayrıntılı ve titiz test prosedürleri ile yüzleşmeyi ve bu yüzleşmeye hazır olup olmadığını değerlendirmek ve doğrulamak için her yeni yazılım sürümünde yapılan bir testler dizisidir. Ayrıca bu kısımda kesinlikle developer'lar için 'Security IntelliSense- VS Extension' eklentisinin kullanmasını öneriyor.

Integrate security into CICD: Benimde inandığım ve MS Core Services Engineering & Operations (CSEO) ekibi tarafından da bahsedilen en önemli nokta, Test Automation Mühendisi, DevOps kültürünün temel yapı taşlarından olduğunu düşünüyorum. Secure DevOps Kit for Azure bizlere Azure DevOps'un bir parçası olmasını olanak sağlıyor ve bu sayede Azure DevOps içerisinde bahsettikleri Security Verification Test özelliği ile tüm test süreçleri için bir task oluşturup yazılan artefact'leri kolaylıkla test süreçinden geçirebiliyoruz. Bu tanımlanan Security Verification Test'leri, herhangi bir veya geliştirmiş olduğunuz bulut uygulamasını dağıtmak için kullanılan hedef aboneliğin veya uygulamanın dayandığı Azure kaynaklarının güvenli bir şekilde kurulmasını sağlamak için kullanılabilir durumdadır. DevOps özelinden bir örnek verelim, uygulamamı Azure üzerine dağıtmak için Azure Resource Manager Template'leri (Infrastucture as Code olarak) bunun testini yapabilme imkanım var.Bununla beraber kendi Unit Test'lerinizi Pester ile geliştirebilirsiniz harika olur. Geliştirmiş olduğum Resource Manager Template içerisinde yaptığım güvelik hatalarını veya olabilecek güvenlik sorunlarını görebilirim.

Continuous Assurance: Kelime anlamında çıkaracağımız nokta bizim için en önemli şey aslında sürekli güvence altında olmak, sunmak veya en önemlisi sunabilmek. Bu kısımdaki MS Core Services Engineering & Operations (CSEO) ekibi tarafından anlaşılmak istenen yaklaşım güvenliği sürekli değişen, yenilen bir süreç olarak ele alıyor. İşte bu yüzden Azure Kaynaklarının sık sık belirli bir mekanizma ile kontrol edilmesini ön görmemiz gerektiğinden bahsediyor. Bu kısımda bizlere Azure Automation içerisinde, Runbooks'lar ile bunların yapılması gerektiğinden bahsetmiş. Bizler ile paylaşmış olduğu Runbook kolleksiyonu aslında Azure Resource tek tek gezip herhangi bir sorun olduğunda bizim için o hataları düzeltmeyi hedefliyor. Security taramalarının hepsini Azure Automation tarafından yönetileceğini ve talebe göre otomatik olarak düzeltebileceğinizi söyleyebiliriz.

Alerting & Monitoring: Azure kaynaklarının güvenlik durumunun görünürlüğüne çok önemli olduğuna vurgu yapılıyor. Uygulamaya sahip departmanlar tarafından veya ayrıca merkezi IT / DevOps ekipleri için çok büyük bir önem arz etttiğini ve bunları her iki ekip tarafındanda görüntülenebilmesi için Operational Insight/ Log Analytics üzerinde Monitoring Solution olarak Azure Secure DevOps Kit eklentisi aktif edebiliyoruz. Bu eklenti sayesinde yukarıda yapılan tüm health check sonuçlarının detaylarını görebilir veya departmanlarınız ile paylaşabilirsiniz.

Cloud Risk Governance: Yukarıda belirtmiş olduğum tüm maddeler haricinde Az Secure DevOps kit içerisindeki en son bu madde bize yukarıda yaptığımız tüm aşamaların bulut kaynaklarının risk yönetiminin, denetiminin, devamlı kontrol altında kalması aşamalarının sonuçlarının takip edilmesini sağlayacak. Bu aşamaya geldiğimiz zaman bize Application Insight kullanarak telemetrik veriler sağlanacak. Bu ise bize firmaların, uygulamalarının güvenlik sağlığının ihtiyaç duyulan ve yapılan iyileştirmelerden haberdar olmalarına yardımcı olacak.

Secure DevOps Kit for Azure özelinde bulunan tüm başıkları tek tek inceledik. Şimdi ise AzSK nasıl bir profilin ihtiyacı olabilir, kimler tarafından ne için kullanılmak istendiğini inceleyim. Bu kısımda IT Organizasyonu veya DevOps eko sistemi içerisindeki kişilerden örneklere göz gezdirelim.

Tablo üzerinde görebileceğiniz gibi Departman veya Kişi bazında faydalarından bahsetmeye çalıştım. Kişi dememin en temel noktası ufak organizasyonlarda yukarıda gördüğünüz işlerden aynı kişi sorumlu oluyor. Bir sonraki yazımızda artık Secure DevOps Kit for Azure abonelik seviyesinde nasıl kullanabildiğimizden bahsedeceğiz.

Bir önceki yazımızda Azure Function örneğini deploy etmiş ve içerisinde bulunan function ile nasıl etkileşim halinde olduğunu ve aksiyon aldığından bahsetmiştik. Şimdi ise Azure aboneliği üzerine Custom Resource Provider tanımlamasının nasıl olduğunu anlayamaya çalışalım. Öncelikle Custom Resoırce Provider henüz general available olmadığı için tüm Azure Region'larında kullanma şansınız yok. Bu yüzden ben sadece destekleyenlerden biri olan, 'EastUs' özelinde devam edeceğim. Custom Resoırce Provider kesinlikle destekleyen Region'lar da oluşturulmalıdır.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "containerName": {
            "type": "string",
            "defaultValue": "fsocietyTerminal01"
        }
    },
    "resources": [
        {
            "apiVersion": "2018-09-01-preview",
            "type": "Microsoft.CustomProviders/resourceProviders",
            "name": "customContainerProvider",
            "location": "eastus",
            "properties": {
                "resourceTypes": [
                    {
                        "name": "startContainer",
                        "routingType": "proxy",
                        "endpoint": "https://customprovider-func.azurewebsites.net/api/{RequestPath}"
                    }
                ]
            }
        },
        {
            "apiVersion": "2018-09-01-preview",
            "type": "Microsoft.CustomProviders/resourceProviders/startContainer",
            "name": "customContainerProvider/startNewContainer",
            "location": "eastus",
            "dependsOn": [
                "[resourceId('Microsoft.CustomProviders/resourceProviders/', 'customContainerProvider')]"
            ],
            "properties": {
                "ContainerName": "[parameters('containerName')]"
            }
        }
    ],
    "outputs": {
    }
}

Yukarıda gördüğünüz resim üzerinde bir çok açıklama mevcut. Öncelike yukarıda gördüğünüz resim basit bir Azure Resoırce Manage Template ibaret ama bunun içerisinde bir tanımlamalar var. Bu template genel anlamıyla iki iş yapıyor. Bu açıkmalar resim üzerinde var ama kısaca yine özetlemekte fayda olduğunu düşünüyorum.

Azure Template içerisinde Resources kısmında tanımlı olan bölümleri ele alalım.

• 1. Bölge yani , Custom Resoırce Provider için Azure API içerisinde tanımlı olan Resoırce Type çağırıp, işte benim custom resoırce provider adım ve ResoırceType tanımlamam bunlar dedik. CustomContainerProvider adında bulunan Custom Resoırce Provider bana startContainer adında bir resoırceType sağlıyor olacak. Bunu tekrar template içerisinde kullanarak süreci Azure function tarafına devredeceğim.
• 2. Bölge de tamamen tanımlamış olduğum Custom Resoırce Provider çağırıyorum ve ona parameterik olarak bir değer gönderip container oluşmasını sağlayacağım. Dediğim gibi normalde bunu Azure Resource Manager Template ile yapabilirsiniz ama burada vermek istediğimiz mesaj Azure Abonelikleri eğer benim Custom Resoırce Provider'ımı kullanıyor ise, lütfen şu propertyleri göndersin ve onun için kendi hizmetimi, bana özel çözümümü Azure Aboneliği içerisine kolay birşekilde dağıtabileyim ve müşteri tarafında gereken tüm automation, yapılacak bir çok işlem (lisanslama, deployent validation vs) Azure Function arkasında çalışan Powershell ile yönetilebilsin. Bunun giib farklı örnekler ile senaryomuz genişletilebilir.

Şimdi isterseniz Deployment sürecine geçelim ve nasıl aksiyon alındığını beraber görelim. Yukarıda gönrdüğümüz template kendi aboneliğim içerisinde çalıştıracağım ve bu sayede basit bir container elde edeceğim. Azure Portal içerisinden Template Deployment seçelim,

Daha sonra "Create" butonuna basarak yukarıda bulunan Azure Resource Manager Template içerisine yapıştıralım ve parametreleri dolduralım.

Template için parametrik değer olarak "Container Name" kısmını belirledik. Bu containerName için girdiğimiz değer, yukarıda bahsettiğimiz gibi Azure Function içerisinde Azure API üzerinde REST API olarak gönderilecek ve Azure Function bu değerleri aldıktan sonra bizim için aksiyon alacak. Şimdi 'Purchase' butonuna basalım ve neler olduğunu beraber görelim.

Deployment süreci başladı. İlk önce tanımlamış olduğumuz customContainerProvider tanımlamasını yaptı. Bunu görebilmeniz için, Deploy ettiğiniz Resource Group içerisinde Deployments sekmesine gelmeniz yeterli. Şimdi ise Azure Resource Manager Template içerisinde olan ikinci kaynak olan Custom Resource Provider içerisine containerName parametresini gönderip Azure Function tarafından tetiklenmesini sağlandığını görelim.

Herşey yolunda gitmiş gözüküyor, gönderdiğimiz değer Azure Function içerisine gönderilmiş , Azure Function içerisindeki Powershell çalıştırıldı ve Azure Rest API gerekli cevaplar düzgün iletilmiş. Görüldüğü üzere deployment Azure function tarafından başarılı bir şekilde yapılmış gözüküyor. Şimdi ise Azure Function tarafında Log detaylarını görelim, böyle bir talep geldiği zaman nasıl bir etkileşim başlıyor.

Kullanmış olduğumuz Template içerisindeki Parametrik olarak değer Azure ARM REST API sayesinde Azure Function içerisine gönderildi ve yapmak istediğim Resource Group ve Azure Container Instance oluşturuldu. Azure Container Instance oluşup oluşmadığını kontrol edelim.

Yukarıdaki resimde görüldüğü üzere Azure Container Instance oluşturuldu ve Container içerisinde console üzerine yazılar yazdırdık. Bu yüzden tamamen neler yapabileceğimize bir örnek vermek adına yaptığımız bir uygulama oldu. Aşağıda paylaştığım gitHub adresim üzerinden dilerseniz Custom Resource Provider Template direk deploy edebilirsiniz. Fakat dikkat etmeniz gereken endpoint adreslerinin düzeltilmesi, kendi Azure Function hizmetini göstermelisiniz.

Not: Yaptığımız örneklerde sadece bir adet Azure Aboneliği özelinde devam ettik. Gerçek senaryolarda Azure Function tamamen hizmeti veren firma, partner tarafından yönetilir. Firmanın verdiği hizmetleri kullanmak isteyen Azure Abonelikleri Custom Resource Provider sayesinde Partnerlerin hizmetini kendi abonelikleri içerisine deploy etmelerine yardımcı olur. Yazımızın başında dediğimiz gibi, bu yöntem Partner firmaların hizmetlerini Azure Aboneliklerine dağıtırken kullanabilecekleri bir yöntem ama dilerseniz kendi organizasyon yapınızda kullanabilmek şansınız olabilir. Daha önceki yazımda verdiğim örnek gibi, Jumbox on demand aslında buna en net örnek olarak gösterebilirim. Bunun sebebi herşey kolay ve hızlı bir şekilde Azure Functions tarafından geliştirilen Powershell tarafından yönetiliyor olacak. Bu yüzden kontrol, yönetim, gizlilik herşey Azure Functions arkasında yazılan olan kısıma bağlı yani özetle hizmet veren kişiye/firmalara.

Daha fazla detay için gitHub adresim üzerinden contribute edebilir veya bana direk yorumlarınızı iletebilirsiniz.

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.

Yukarıda gördüğünüz, bir endpoint tanımının alması gereken öznitelikler yani propertyleri görebilirsiniz. Bu property'lerin ne iş yaptıklarına kısaca göz gezdirelim.

Tablo içerisinde bahsettiğimiz ve yukarıda ki örnek JSON dosyası içerisinde sıradan bir Endpoint tanımlasını nasıl yapmamız gerektiğinden bahsettik. Şimdi ise bu endpoint tanımlasını Azure Resource Manager içerisinde nasıl kullanabileceğiz ve nasıl Custom Resource tanımlası yapabiliriz buna beraber bakalım. Öncelikle Custom Resource için Resouce Types anlaşma/tanım özelliğini kullanılım. Aşağıda gördüğünüz tanımın temelinde bize yeni bir API sunar ve tüm operasyonunda RESTful özelinde Create, Read, Update, Delete (CRUD) yöntemlerini ortaya koyar ve destekler.

Yukarıdaki tanımladığımız JSON içerisinde artık Azure API bu detayları gönderdikten sonra Custom Resource ile nasıl iletişime geçeceğini ve eklenen API Detayları aşağıda bulabilirsiniz. Girdiğiniz resourceType adına göre Azure REST API gerekli CRUD işlemleri için API tanımlamaları yapılacaktır. ResourceType olarak kullanılan Custom Resource Provider tipinde yapılan istek sonrası endpoint kesinlikle Id, Name ve Type göndermelidir. Bunlar sırasıyla,

• Id: "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CustomProviders/resourceProviders/{customResourceName}",
• Name: "{customResourceName}",
• Type: "Microsoft.CustomProviders/resourceProviders/{resourceTypeName}"

Bunların detaylarını geliştirmiş olduğum Powershell code bloğu içerisinde bulabilirsiniz. Return Response olarak bu değerleri geriye dönmeniz gerekiyor, Deployment sürecinin başarılı tamamladığını anlatmak için Azure API tarafına göndermeniz şart.

Custom Resource Provier için Custom Actions nasıl tanımlanır?

Daha öncede söylediğimiz gibi iki adet farklı karşılıklı anlaşma modelimiz var idi. Bunlardan diğeri olan Custom Actions en basit haliyle, Custom Resource Provider tanımlamasını yaptığımız zaman Azure bize, Action için bir Rest API sunar ama sadece Post methodunu destekler. Yazı serimiz boyunca ResourceType tanımı üzerinde yoğunlaşıp onu kullanarak endpoint kullanımı gerçekleştireceğiz.

Yukarıdaki örnekte bir Actions tanımlaması Custom Resource Providers için görebilirsiniz. Bu tanımlama ile bahsettiğim gibi, Custom Resource Providers için RESTful operasyona denk gelen aksiyonları belirtip endpoint talepleri iletebileceğiz. Tanımlanan Actions ile aşağıdaki API Detayları elde edilebilir.

Actions olarak kullanılan Custom Resource Provider tipinde yapılan istek sonrası endpoint kesinlikle aşağıda bulunan geçerli tipte veriler döndürmelidir. Bunlar sırasıyla,

• Content tipi: "application/json; charset=utf-8" olmalı.
• Geçerli bir JSON formatında, object array.

Custom Resorce Provider özelinde Resource Type ve Actions tipinde farklı karşılıklı anlaşma modellerinin nasıl yapılacağını gördük, aralarındaki farklılıklardan bahsettik ve artık ön gereksinimlerimize geçebiliriz.

Azure Functions hizmetine ihtiyacımız var çünkü bizim için bir endpoint gibi davranıp Custom Resource Provider tarafından gelen eylemleri işleyip Azure Function içerisinde çalışan Powershell Function veya Script artık nasıl bir süreç yönetmek istiyorsanız sizin isteğiniz doğrultusunda aksiyon almasını sağlayacağız. Makale içerisinde sizleri Azure Function nasıl oluşturulur, neler yapmanız gerektiğini bilmenize gerek kalmadan kendi gitHub hesabım üzerinden Azure Resource Manager Template'lerine erişebilir ve hızlıca kendi ortamınıza dağıtabilirsiniz. Bu yüzden Azure Function nasıl oluşturacağım, nelere dikkat etmem gerekiyor gibi sorunlara sizi boğmadan Azure Function oluşturmak için aşağıdaki adımları seyrederseniz çok hızlı bir şekilde Custom Resource Provider için bir endpoint tanımlaması gerçekleştirebilirsiniz.

Azure Function Dağıtım adımları için lütfen aşağıdaki adımları takip ediniz.

Gördüğünüz gibi Deploy to Azure butonuna bastığınız zaman sizler için yayınladığım Azure Function hizmetini deploy ediyor olacak. Function içerisinde geliştirdiğim, StartContainer isimli Function job tanımlanmış olacak. Bu sayede bunu Custom Resource Provider kullanabilirsiniz. Deployment başarılı olduğu zaman sizin için bir Deploy ettğiniz Function adında bir adet App Registration oluşturacak ( Service Principal Account ) bunun demo ortamı için azure hesabınıza yetkilendirmesini yapmanız gerekmektir. Daha fazlası için gitHub sayfamı takip edebilirsiniz. Özetle bu function depoy ederek, endpoint tanımlamasının bir şablon halinde hesabınıza dağıtarak kullanmaya başlayacaksınız.

Aşağıdaki paylaştığım Azure Function içerisinde Powershell Core ile geliştirmiş olduğum bir kod bloğu var, yaptığı işi kısaca özetlemek gerekir ise gelen talep doğrultusunda bir adet container oluşturup console içerisine birşeyler yazdırmak. Tahmin edebileceğiniz gibi bunu zaten Azure Resoırce Manager Templateleri ile yapabiliyoruz ama burada vermek istediğim örnek tamamen sizin hizmetinize özel geliştirmiş olduğunuz Custom Resource Provider için belirli bir nitelikler göndererek ( endpoint'e yani Azure Function uç noktasına) bu değerler Azure Function tarafından işlenip sizin için bir aksiyon almasını sağlamak. Yani özetle Azure deneyimini bozmadan, Azure Resource Manager üzerinden abonelik içerisinde Custom Resource Provider register edip, sadece talep edilen propertyleri göndermek olacak. Aşağıda bulunan kod bloğunu incelediğiniz zaman request edilen container adında hızlıca bir ACI oluşturup console üzerine birşeyler yazıyor olacak.

Bir sonraki yazımızda Azure Function ve Custom Resoırce Provider için yapmamız gereken yapılandırmalara devam edeceğiz.

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.

Custom Resoırce Provider tanımına geçmeden önce hızlıca Azure Resource Manager ve Azure Functions konularından bahsedelim. Öncelikle Azure Resource Manager Template dağıtım modelini kullanmanın avantajlarından kısaca bahsedelim. En basit haliyle Azure Resource Manager Template dağıtım modelini kullanarak geliştirmiş olduğunuz JSON ( declarative syntax ) ile tekrar edilebilir, validate edilmiş, DevOps kültürüne uygun olarak deployment patternleri hazırlayabilir ve tekrar tekrar kullanmaıza yardımcı olur. Green Field bir deployment yaptığınız zaman veya hali hazırda mevcut bir ortamınız için geliştirilmiş olan Azure Resource Template'lerini Dev, UAT, Production ortamlarınız için tutarlı deployment pattern hazırlayabilirsiniz. Bildiğiniz gibi farklı deployment araçları kullanarak Terraform, Ansible(her ne kadar configuration as code giriyor olsada IaC ve CaC ) olarak da kullanabilir) dağıtım yapabilirsiniz.

Azure Resource Manager templateleri daha önce dediğimiz gibi bize tutarlı, tekrar edilebilir, moduler hale getirilmiş, validate edilmiş ve CI/CD süreçlerine entegre olurken çok farklı avantajlar sağlıyor. Deployment süreçlerini yönetirken hangi tool ile bu işi sırtlanmanız gerektiğini siz belirleyebilirsiniz. Daha öncesinde farklı deployment aracı olan Terraform video serisimize Bulut Bilişim Çözümleri ve Ötesi isimlı youtube kanalı içerisinden bakabilirsiniz.

Azure Function ile ilgili yaklaşık iki sene önce bir yazı yazmıştım ama o kadar hızlı değişiyor ki yetişmek mümkün değil. Uzun bir süredir Azure Automation kullanarak schedule edilen standard tasklarımı veya WebHook kullanarak request ettiğim custom süreçlerimi öncelikli olarak Azure Automation içerisinden yönetiyordum ancak oyuna Azure Function hizmetinin Powershell desteği ile girmesiyle beraber şimdi ise iki tarafıda yoğun olarak kullanıyorum fakat Serverless Automation kavramında Azure Function oyuna dahil olduğu için bu Azure Function hizmeti içerisinde Powershell kullanmayı daha çok tercih etmeye başladım şu sıralar. Azure Functions en çok DevOps tarafında Servleress Automation olarak karşımıza çıkıyor ve EventGrid, Storage Queue veya Services Bus ile yaptığınız entegrelerde inanılmaz sonuçlar alabilirsiniz. Bu konuyu başka bir yazıda ele alacağım. Muhtemelen Event Driven Orchestration dünyasının nimetlerinden faydalanmamak imkansız gibi gözüküyor.

Azure Function kendi içerisinde v1 ve v2 olarak ikiye ayrılmakta, yeni bir Azure Function oluşturmak istediğiniz zaman hangi versiyonu seçmeniz gerektiğinize emin olmalısınız. Temel anlamıyla, v1 Powershell Core desteklemiyor. Powershell Core kullanmak istiyorsanız v2 ile devam etmenizi tavsiye ederim. Sebebi ise Powershell Core dışında, Azure Function v2 bize çok fazla kolaylık sağlıyor, en temeli custom bir Powershell Modülüne ihtiyacınız olur ise bunları yönetmek için Dependancy Management kullanarak Package Management üzerinden Custom Powershell Modüllerini alabilir veya Managed Identiy tadına vararak Azure Function code bloğunuzun çalışırken karşılaşacağı authentication sorunlarını kolayca atalabilirsiniz.

Şimdi tekrar Azure Function hizmetini nimetlerine dönmeceğim ama önce artık Custom Resource Provider nedir, ne için kullanabiliriz bunu biraz daha açalım. Bunları şu cümleler ile özetleyebiliriz.

Öncelikle şunu bilmenizi isterim ki, Custom Resource Providers henüz release olmadı. Birkaç cümle ile Azure'da bulunan Publisher'lar yani Vendor veya Partner artık nasıl çağırmak isterseniz onların hizmet vermek istediği müştlerine kaynaklarını dağıtmak, configure etmek için bir yol sağlamaktır. Kullanıcıların Azure dışından gelen kaynaklar için eylemler tanımlamasına izin verir ve bunları Azure Resource Manager şablonu ile dağıtımına yardımcı olur. Senaryoyu biraz daha açmak gerekir ise düşünseniz F5 bir load balancer deploy etmeye çalıştığınız firmanın bir takım orkestrasyon yapması gerekir dağıtılan kaynaklar içerisinde işte tam bu noktada Azure Custom Resource Provider yardımımıza koşuyor. Azure Managed Application detaylarına baktığınız zaman Custom Resource Provider ile ilişkisi olduğunu göreceksiniz. Aslında cevap çok basit, eğer custom bir uygulamanız var ise ve bunu Market Place üzerinden hizmet vermesini istiyorsanız Custom Resource Provider kullanarak Custom Resource için API'lar yayımlayabilir ve kullandırabilirsiniz.

• Azure Resource Manager REST API - isteğimiz doğrultusunda genişletebiliriz. Bunlar organizasyonuza bağlı olarak tasarlanan uygulamalar Internal ve External hizmet sağlayıcıları olabilir.
• Mevcut Azure Deployment süreçlerinizde ihtiyacımız olan özel yapılandırmaları otomatikleştirebiriz.
• Azure Resource Manager Template kullanarak daha fazla denetim altına alabilir ve etki eden deployment süreçlerini daha detaylı kontrol edebiliriz.

Daha fazla örnekleri genişletmemiz gerekir ise sizin bir uygulamanız var bir servis sağlayıcı olarak bu uygulamanızı Azure üzerinde kullanan müşterinize sunarken bir deployment süreçinden geliştirmek istiyorsunuz. Bu herhangi bir third-party uygulama, firewall, aklınıza gelebilecek Azure kaynaklarına dokunna her türlü bir süreç olabilir. Siz bir partner olarak hizmetleriniz var bunları Azure Resource Manager üzerinden dağıtabiir hale getirmek istiyorsunuz ve arada yer alan dağıtım süreçlerini otomatik hale getirerek tamamlamak istiyorsunuz. Benim yakın zamanda yaptığım ve Pre-Production bir sistemde kullanmak olduğunuz Custom Resource Providers kullanarak bir dağıtım yönetimden bahsetmek istiyorum tamamen internal-organizasyon içerisindeki istekler özeli dahilinde kullanıyoruz.Bir Custom Resoırce Provier geliştirdik fakat bu sadece şirket içerisindeki departmanlara hizmet veriyor. En basit haliyle, şirket içerisinde farklı departmanlar var bu departmanların kendi özgü kaynakları abonelikleri olduğunu düşünün. Departmanların isteği doğrultusunda kendi ortamlarına kolayca Jumpbox VM ihtyaçlarını olduğunu ve bunu yine basit bir Azure Resource Manager Template ile kullanabildiklerini ama arkadaki bir çok automation süreçlerini çok fazla soru sorulmadan kolayca ve güvenli bir biçimde halledildiğini düşünün.

Özetle; Bu servisi ben {Jumbox-On-Demand} olarak çağırıyorum. Business Departmanlar merkezi olarak kendi ihtiyaçları doğrultusunda Jumbox on demand hizmetini talep etmek için Azure Resource Template kullanıyorlar ama bu template içerisinde kullanmak istedikleri Azure kaynakları tek tek tanıtmıyorlar, sadece template hizmeti veren ekip tarafından geliştirip, talep edilen parametreler aslında Azure Function içerisine Post ediliyor ve deployment tamemen Azure Function üzerinden kontrol ediliyor. Azure Resource Manager Template'ler sadece bu noktada endpoint ( Azure Function) olarak tanımlamak için ve talep edilen parametrik değerli almak için kullanılıyor. Eğer aşağıda süreçleri düşünürseniz, bu işleri yapmak için basit bir kullanıcının nelere yetkili olması gerektiğini farkına varabilirsiniz. Bu yüzden business departman kullancısı sadece istediği talebi Azure Resource Manager içerisinde tanımlı olan Custom Resource Provider resource'una iletip daha sonrasında Azure Function endpoint'ine gönderiyor ve tüm kontroller, authentication ve authorization Azure Function tarafında yazdığınız Powershell Script tarafından kontrol edilecektir. Senaryonun bir tık ilerisi aslında aynı Azure Function hizmetini, ITSM hizmetleri ile birleştirmekten ibaret yani aynı talebi firmanın talebi ile beraber ServiceNow gibi hizmetlere entegre edebilirsiniz sebebi ise Azure Function geliştirdiğiniz Powershell bloğunuz bir Rest API gibi davranabilir ve önüne Azure API Management hizmetini koyabilirsiniz.

• Creating - Virtual Machine – Sanal Makine oluşturma
• Impelementing – Disk Encyrption – Oluşturulan Sanal Makineyi Disk Encryption süreçlerini otomatik hale getirme
• Creating Firewall Rules on Firewall for spesific IP Ranges. Oluşturulan sanal makine için Firewall üzerinde ingress kurallar tanımlama ( belirtilen source adresler üzerinden)
• Creating CIS Based Imaged – Enrolling Azure Automation Account to get latest DSC Configuration – CIS Image ( Hardening olaması için geliştirdiğim DSC Config alabilmesi için Azure Automation otomatik register etmek)
• Automatically Enroll to Backup Vault – Jumbox amaçlı oluşturulan sanal makinenin Azure Backup Vault içerisine otomatik olarak kaydedilmesi
• To Schedule – Azure Runbook for deleting and redeploying Jumpbox. Deployment süreçinde Azure Automation DSC ve Runbook özelliğinden faydalanılıyor. Mevcut bir Runbook ile güvenlik gereksinimlerinden dolayı her 30 günde bir dağıtılan Jumpbox silinip tekrar oluşturup domain ortamına dahil ediliyor.

Diğer bir örnek verebilecek olur ise, Custom Resource Provider ile mesela, Azure Active Directory tarafında Group Oluşturmak, Group Member'ları ekleme çıkarma gibi değişik senaryolar yapabilirsiniz. Senaryolar oldukça genişletilebilir.Bir sonraki yazımızda Custom Resoırce Provider yapısını oluşturmak için temel bileşemlere bakıyor olacağız.