Cloud, Sunshine and Rainbow https://docs.microsoft.com/archive/blogs/dsilva/feed.xml Let's talk cloud Tue, 16 Apr 2019 06:03:41 GMT en-US hourly 1 Azure Subscription Governance – Controlling resources with Tags, Policies, and Locks https://docs.microsoft.com/archive/blogs/dsilva/azure-subscription-governance-controlling-resources-with-tags-policies-and-locks Thu, 12 Apr 2018 15:16:30 GMT https://blogs.technet.microsoft.com/dsilva/?p=415 my last post, today I will talk about how you can take control of resources in your subscription by utilizing resources offered by Azure. Why is that important? Consider the following scenarios:
  • Unplanned deployment of resources to subscriptions preventing identification, tracking, and effective automation/billing
  • Deployment of resources that violate policies and regulations
  • Accidental deletion of modification of critical resources that have the potential to cause widespread outages or loss of data
Whether you are a DevOps engineer, Cybersecurity analyst, CIO or CISO, you certainly do not want to stand out for the wrong reasons. Read on to find out how you can leverage Azure features to control resources in your subscriptions. 1 – Tags A tag is an arbitrary key/value pair that can be assigned to a resource group or a particular resource. Tags are very powerful and play a key role in automation, management, and billing of Azure resources. From an automation/management perspective, once tags have been assigned, resources can be collectively targeted. Scenario: A group of DEV servers needs to be shut down every day at 6:00 PM.
  • Add a tag with a key called "shutdown" and give it the value of "1800":
  • Use automation to target the VMs based on tags:
Here are some other common use cases for tags:
  • Cost Center
  • Environment: Dev/UAT/Prod
  • Project
  • Owner: Person/Group
  • Application: SCCM/Exchange/AD
  • Importance: Low/Medium/Critical
From a billing perspective, it is important to know that tag is one of the fields listed by the Azure Billing API. Enterprise customers often use tags as criteria to build insightful billing reports using tools such as PowerBI and Azure Cost Management. Scenario: A customer wants to find out how much a specific application/workload costs. By tagging all resources (storage account, VM's, Web Apps, etc.) that belong to that particular app/workload with application information, this customer could leverage the billing report options mentioned above to effectively calculate the cost of a workload. Read more about tags here. 2 – Azure Policies Azure policies give customers the ability to define how resources are deployed to a subscription and can help ensure compliance requirements are met. Policies work hand in hand with RBAC, but they perform different functions, while RBAC focuses on who can manage resources, policies focus on how resources should be deployed/configured. Policies are inherited by child resources and can be assigned at the following levels: management groups, subscription, and resource group. Scenario: A customer must abide by regulations that demand that data must reside in their country.
  • Create a policy that defines allowed locations and assign it to the subscription:
  • Once assigned, policies will be enforced and will prevent anyone (including subscription admins) from creating/modifying resources that would cause violations. Notice what happens when I try to create a resource in a location that violates the resource policy:
Here are some other common use cases for policies:
  • Allowed virtual machine SKUs – Helps control cost by restricting VM sizes
  • Enforce tag and its value – Ensures resources are always deployed with the appropriate tag for consistency/compliance purposes
  • Allowed/Not allowed resource types – Allows or prevents the creation of specific resource types. Example: Define a policy that prevents the creation of network gateways to prevent administrators from potentially exposing the environment by inadvertently creating a rogue VPN connection
Some policies can be created for audit purposes only and would not enforce settings or prevent resources from being created/modified. Example: Audit VMs that do not have managed disks. Those policies can then be audited using policy compliance. For a detailed list of policy templates, check out Templates for Azure Policy. Read more about resource policies here. 3 – Resource Locks Resource locks is a feature that prevents resources from being deleted or modified inadvertently. Locks are inherited by child resources and can be applied at the following levels: subscription, resource group or resource. There are two types of locks: Delete – Prevents any user from deleting resources, but still allows modifications by authorized users ReadOnly – Prevents any user from deleting or modifying resources, but still allows authorized users to read the resource Scenario: A customer wants to protect their domain controllers from accidental deletion.
  • Place a "Delete" lock on the domain controller VM:
  • Once the lock has been applied, even subscription administrators will be prevented from deleting those resources. Notice what happens when I try to delete a VM protected by a lock:
  In order to modify such resources, the administrator needs to remove the lock first. Locks should be in place to protect any critical workload, however, core infrastructure components such as domain controllers, DNS servers, network appliances, VPN gateways, etc., should definitely have locks, since the accidental deletion or modification of those resources could have a massive impact. A common practice I have seen with customers out there is the creation of a dedicated subscription for infrastructure resources with resource groups containing the critical infra components and locks applied at the RG level. Read more about locks here. 4 – Managed Groups This feature is currently in preview, therefore, I will only briefly mention it here as it is shaping up to be yet another important tool to have under your belt when it comes to Azure resource management. The premise of management groups is to provide a scope level that is above subscriptions. Consider the scenario above where we created a policy to restrict the deployment of resources to a specific location. This is an easy task if you have one or few subscriptions, however, if you need to apply the same policy to dozens of subscriptions, this is where management groups come in handy. The same policy could be applied to a management group that, in turn, is inherited by multiple subscriptions, the same applies to RBACs and this will greatly simplify the management of resources across multiple subscriptions. Read more about management groups here. Summary Among all the features discussed above, customers have the tools they need to make sure they have full control of the resources deployed to their subscriptions. It is important to highlight that there is not a one size fits all or best practices strategy when it comes to the use of these features, however, I consider all of them equally important in subscriptions of any size. Hopefully, the examples given here will help you make an informed decision.]]> Azure Subscription Governance - Resource Group and Naming Convention Strategies https://docs.microsoft.com/archive/blogs/dsilva/azure-subscription-governance-resource-group-and-naming-convention-strategies Fri, 10 Nov 2017 12:14:02 GMT https://blogs.technet.microsoft.com/dsilva/?p=176 1 - How many subscriptions should I create? There are mainly three aspects to consider here: Billing, Access Control and Subscription limits, each one of them will play a role in the decision-making process, but should not be the only single factor weighing in that decision. Customers should aim to have as fewer subscriptions as possible to keep it simple. Billing Billing reports can be generated by subscriptions, if you have multiple internal departments and need to do chargeback, a possible scenario is to create subscriptions by department/project. Billing can also be achieved through other methods such as EA Departments and the billing API, therefore, there is flexibility here. Access Control A subscription is a deployment boundary for Azure resources in the same way a domain is a deployment boundary for Active Directory objects, every subscription is associated with an Azure AD tenant that provides administrators the ability to set up role-based access control (RBAC). When designing a subscription model, one should consider the deployment boundary factor, some customers have separate subscriptions for Development and Production, each one is completely isolated from each other from a resource perspective and managed using RBAC. More Info: Azure RBAC Subscription Limits Subscriptions are bound to some hard limitations. For example, the maximum number of Express Route circuits per subscription is 10. Those limits should be considered during the design phase, if there is a need to go over those limits in particular scenarios, then additional subscriptions may be needed. If you hit a hard limit, there is no flexibility here. More Info: Azure Subscription Limits If your Azure subscription is part of an Enterprise Agreement, please check out the following document to find out more about subscription/cost management considerations: EA Onboarding Guide I have seen a mix of those approaches out there, but most large customers I have interacted with, primarily create subscriptions for the different environments (Dev/UAT/Prod) and then control access using resource groups and RBAC. I have also seen some customers creating different subscriptions to host resources that belong to a particular project which are isolated from the Dev/Prod environment, this way, they can control access and track costs for that particular project. 2 - What is the best strategy for creating resource groups? There are mainly three things to consider here: Resource groups (RGs) can be used for RBAC, Automated Deployments, and Billing/Monitoring purposes. RBAC From an RBAC perspective, RGs are like OUs in Active Directory, they are a container for resources and can be a scope of RBAC for delegation purposes. Here is an analogy between AD and Azure: [caption id="attachment_186" align="aligncenter" width="379"] AD/Azure Analogy[/caption]   One possible scenario is to group resources that are managed by a common team together. Example: Some customers create RGs for infrastructure resources like domain controllers, virtual networks, file servers, storage accounts etc., then delegate access to the infrastructure team to manage that RG. Note that RBAC can also be scoped at the resource level, therefore, there is flexibility here. Automated Deployments RGs are also deployment boundaries from an automation perspective. Consider a multi-tier application with Web, App, and DB tiers, when deploying all those tiers in a resource group, it is possible to automate the entire deployment of that application by generating an ARM template from the resource group. The entire solution could then be redeployed later in an automated fashion, this is probably the most important factor to consider since one of the major benefits of the cloud is agility/scalability with automation playing a key role here. More Info: Export an Azure Resource Manager template from existing resources Billing and Monitoring Although there are more efficient methods for billing and monitoring i.e.: Billing API / OMS, RGs can also be used to display resource costs and for monitoring purposes by setting up metrics and alerts. 3 – Do I need a naming convention strategy? Absolutely! - I find that this one is often overlooked. Let me tell you that defining a naming convention strategy is as important as the other topics discussed above. Once the number of workloads in an Azure subscription grows, a lot of the management tasks will be performed via command line interfaces like CLI and PowerShell, in addition, deployment using automation becomes key to unlock the agility/scalability benefits that Azure offers. Automation is made a whole lot easier with a naming convention strategy in place, some customers even use naming convention to pull billing reports based on a number of criteria. More Info: Azure Naming Conventions Summary This should get you started and pointed in the right direction, it is important to note that there is not a one size fits all strategy or strict best practices, large customers I that have interacted with, use a combination of the strategies outlined above. In a future post, I will talk about how to take control of your Azure resources with things like tags, resource groups, and resource policies.]]>