1

Azure Resource Manager – Policy Management – Bölüm 1. Azure Resource Manager ile artık bildiğiniz gibi Role-Based Access Control, Resource Lock, Resource Tag ve Billing vb. yönetimsel ihtiyaçlarımızı karşılamaktadır. Resource Manager Policy, isteğe bağlı olarak yazılan özel politikalar yoluyla erişimini kontrol etmenizi sağlar. Geliştirdiğiniz bu politikalar ile, kurumun kaynaklarını yönetmek için gerekli olan kuralları yazabilir ve kullanıcıların yapabileceği hataları önleyebilirsiniz.


Resim-1

Özellikle organizasyon içerisinde istenmeyen eylemleri veya kaynakları tanımlayan politikalar oluşturmak istenebilir. Tanımladığınız politikaları Subscription, Resource Group veya Resource bazında istenilen kapsamda atayabilirsiniz. Bu makalede, size politika oluşturmak için kullanabileceğiniz politika oluşturmak için gerekli dilinin temel yapısını açıklayıp sonra farklı kapsamlarda bu politikaları uygulamak ve bazı örnekler göstereceğim.

Resource Manager ile Policy Management arasındaki farkı iyi anlamak gerekli. Resource Manager hali hazırda bizlere zaten Role-base Access Control yaptırabiliyor. Fakat biz biraz daha yönetimi derinleştirmek istiyoruz. Örnek olarak “Engin” kullanıcısına Azure Subscription içerisinde belirli bir Resource Group için yetki verdiniz. Buraya kadar her şey istediğiniz gibi gidiyor. Eğer biraz daha derinleşmek isterseniz, örnek olarak Resource Group içerisine kaynak yaratsın ama sadece sizin belirlemiş olduğunuz “Azure Datacenter” lokasyonunda veya belirlediğiniz kaynakları örn: ” Storage Account, VM , SQL” sadece bu hizmetleri oluşturabilsin deme şansına sahip olabiliyorsunuz. Benzer şekilde, Azure içerisinde bulunan hizmet katalog yapısını kontrol etmek veya kaynaklar için istenen adlandırma kurallarına zorlayabilirsiniz. Örneğin sadece Virtual Machine oluşturabilsin fakat size olarak “D2” şeklinde belirtme şansınız var.

Policy Defination Structure

Policy tanımı yaparken JSON söz dizimi kullanılarak oluşturulur. Eylemler ve koşullar yerine getirildiğinde ne yapması gerektiğini söyleyen bir tanımlama veya mantıksal operatörler kullanılır.

Temelde, bir Policy aşağıdaki kısımlardan oluşmaktadır.

Condition/Logical operators: Belirlediğiniz koşulları mantıksal operatörler ile manipüle edebilirsiniz. Bunlar “Not”,” And”,” Or” olarak çağrılır.

Effect: – Bu kısım önemli belirlediğiniz koşul yerine geldiği zaman ne olacağını açıklar. Effect olarak alabilecek değerler aşağıdaki gibidir.

  • “Deny” değeri verilir ise yapılacak aksiyon hem Audit edilir ve hem de işlem gerçekleşmez.
  • “Audit” değerli verilir ise yapılacak aksiyon Audit edilir, fakat işlem gerçekleşir.
  • “Append” değeri koşul içerisinde yer alan kaynaklara izin verir.

Aşağıdaki örnekte örnek bir JSON Policy Template görebilirsiniz.


Resim-2

Bu örnekte söz dizimi biraz inceleyelim.”JsonPolicy” adında bir değişken oluşturulmuş ve JSON içerisine Condition ve Effect tanımlamaları yapılmış durumdadır. Template içerisinde “North-Europe ve West-Europe” lokasyonlarında yapılacak işlemleri için bir durum belirtilmiş. Bu durum kısmı ise “Effect” alanına “Deny” değeri verilmiş gözüküyor. Özetle eğer bu lokasyonlarda dışında oluşturulacak kaynaklar için işlemler başarısız bir şekilde olacaktır ve Audit edilebilme şansımız olacaktır. (Template içinde bulunan “in” kısmına dikkat ediniz!) JSON Template içeriğini Powershell ISE üzerinde geliştirdim. Sebebi ise bir değişken atayıp script içinde ilerleyen kısımlarında kullanabilmek içindir. Visual Studio ile yazmış olsaydınız yada başka bir araç ile JSON file çağırıp değişkene atamanız yeterli olacaktı.

Yukarıda yazmış olduğumuz “Policy” tanımını AzureRM Powershell Modulü içerisinde bulunan “New-AzureRmPolicyDefinition” isimli cmdlet ile gerçekleştirebiliyoruz. Bu cmdlet bir takım parametreler alır ve bunlar aşağıdaki gibidir.

  • -Name : Oluşturulmak istenilen Policy adıdır.
  • -Description : Tanımlanan Policy için açıklama girilir ve daha sonra bakıldığında hatırlatma için fikir verebilir.
  • -Policy : Bu parametre geliştirdiğiniz JSON Template detayını gönderilecek olan kısımdır. Dilenirse yukarıda bulunan resimdeki Variable gönderilebilir veya bir Path üzerinde bulunan JSON yolu ifade edilebilir.


Resim-3

“New-AzureRMPolicyDefinition” cmdlet’inin resim içerisinde kullanımı bulabilirsiniz. Eğer geliştirdiğiniz Policy tanımlamalarında sıkıntı yok ise başarılı bir şekilde oluşturulacaktır. “Name” parametresine Policy adı olarak “RegionPolicy” ismini verdik.


Resim-4

Policy oluşturuldu. Artık bu Policy bir kaynak grubuna atamasını gerçekleştirelim. Yazmış olduğumuz politikayı Resource Group içerisinde oluşacak kaynaklar için atamasını yapalım. Atama işlemi için portal üzerinde herhangi bir Resource Group’un bir ResourceId’si bulunmaktadır. Bunu çok kolay bir şekilde Portal arayüzünden görebilirsiniz. Dilerseniz benim gibi aşağıdaki cmdlet yardımıyla Resource Id’si bulabilirsiniz.


Resim-5

“Get-AzureRMResourceGroup” cmdlet sayesinde -Name parametresine “Resource Group” adını göndererek ResourceId değerini döndürdük. Bu değeri Policy ilgili Resource atarken kullanıyor olacağız.

Bu konuyla ilgili sorularınızı  alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.

Referanslar

https://www.mshowto.org

Bu İçeriğe Tepkin Ne Oldu?
  • 0
    harika_
    Harika!!
  • 0
    be_enmedim
    Beğenmedim
  • 0
    _ok_iyi
    Çok iyi
  • 0
    sevdim_
    Sevdim!
  • 0
    bilemedim_
    Bilemedim!
  • 0
    olmad_
    Olmadı!
  • 0
    k_zd_m_
    Kızdım!

Hasan Güral, Istanbul doğumlu ve uzun yıllardır bilişim sektöründe danışmanlıktan eğitmenliğe farkli pozisyonlarda görev almıştır. Üniversite eğitimiyle birlikte bilişim sektöründe Kibar Holding, Bilge Adam Bilgi Teknolojileri Akademisi ve PeakUp Bilgi Teknolojileri gibi farkli kurumlarda Kıdemli Danışman ve Eğitmen olarak sektöre yön veren projelerde yer almistir.Microsoft Azure alanında yapmış olduğu paylaşımlar ve katkılarından dolayı Microsoft Valuable Professional (Azure) unvanına hak kazanmıştır. Cloud teknolojilerinin otomasyon alaninda gelişmesiyle birlikte zamaninin bir çoğunu PowerShell, Event-Driven Orchestration, Infrastructure as a Code ve Configuration as a Code ile geçirmektedir.Kariyerine Ingiltere’de DevOps Engineer ve Automation Enthusiast rolü ile Cloud Rundle’da devam etmektedir.

Yazarın Profili

Bültenimize Katılın

Tıklayın, üyemiz olun ve yeni güncellemelerden haberdar olan ilk kişi siz olun.

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Yorumlar (1)

    Bir yanıt yazın

    E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir