As part of the Azure 101 series of Blog posts, I felt that it was important to make sure and discuss the different ways that you might need to access your Azure subscription. That being said, I am not going to talk about how to get a new Account or Subscription within Azure as that process is going to be different if you are a long independent consultant versus part of a large enterprise. However, there is a good piece of learning that Microsoft has provided if you would like to try and get access to a subscription yourself and that can be found in the Addition Resources at the bottom of this article.
There are many different options for accessing your Azure resources, some that are graphical in nature and some that are command-line driven and then of course there are also all of the different SDKs and extensions on top of those. Here is a quick list of the possible access points today:
- Graphical
- Portal – Dashboards, Search and Blades
- Mobile Apps – Apple & Android
- Command-Line Tools
- CloudShell
- PowerShell & CLI
- Resources as a Code
- Azure Resource Manager Templates
- Terraform
- Azure SDKs (.NET, Java, JS, Python, PHP, Go, REST)
Using this list, I will provide you with some basic information and 100 level videos that will walk you through a few of these options as well as provide some helpful hints and recommendations. For those that I cannot easily provide a video walkthrough, then I will at the very least provide you with documentation down below so that you can learn more.
Authentication
Before accessing any of the interfaces mentioned above, I need to make sure that you understand how to authenticate into a given Azure subscription. The first thing to understand, is that all users or service principals/service identities/applications are authenticating against a Azure deployed Active Directory as a Service called Azure Active Directory (AAD). Every customer of Azure and Microsoft 365 has at least one AAD tenant with Users and Groups that can be synchronized with their existing on-prem Active Directory deployments. This is true even if you are a sole individual subscriber of Azure or 365.
Within AAD you have access to two different types of objects that require authentication, Users and Applications. Each one of them has the ability to authenticate to AAD and each one of them has the ability to have Role Based Access Controls assigned to them, thereby limiting their permissions. However, there is one distinct difference between the two:
- Users are considered Interactive
- Applications are considered Non-Interactive
What exactly do I mean by this? I mean that a User is required to authenticate through a web interface where they will put in their email address and password at a minimum. An application is not required to go through a web interface which means that the authentication process can happen within any kind of code, such as CLI scripting or SDK. If you are building Cloud Native applications, or Cloud Automation, then you will absolutely end up using both, but there are some customers that do everything through the Portal and therefore, really only use the standard Users for authentication.
NOTE: Needless to say, this is not a deep dive into AAD, so I did not talk about the types of authentication mechanisms possible, but AAD absolutely supports single sign-on and MFA as part of the authentication mechanism so that customers can move into a Password-less based environment.
Azure Portal
Now that you have been successfully authenticated into one or more Azure subscriptions, I highly recommend starting out with the Azure Portal. Although the Portal does not provide access to all features and services because of how quickly things move in the Cloud, it does contain 90%+ of them which means that it is going to be a great starting point for anyone wanting to actually visualize what is possible within Azure. It will also be a lot quicker for you try things out and see how they work within the Portal than trying to do it via PowerShell or one of the developer based SDKs.
With that as an intro, let’s take a look at the Portal interface and the different features that are available for you to use when working with your Azure resources.
TIP: One good use case for doing work in the Portal even if you are considered an expert in all things Azure, is that for larger architectures that are going to need to be deployed multiple times. It can be faster to build out that architecture for the first time in Azure inside a Resource Group and then use the Export feature available to create a Infrastructure as Code script that can the be parameterized to run the same deployment multiple times.
Command-Line Tools (PowerShell & Azure CLI)
As good of a job as Microsoft has done with the Azure Portal, especially in comparison to the competitors, it is not the only interface available and for some Architects, Developers, or Engineers it is not even the preferred interface. Some roles just feel more comfortable with a code first or command-line interface and Microsoft provides those as well. The most popular one is Azure Cloud Shell which is completely browser based and can be brought up inside of the Azure Portal as a separate window or pane or through its own browser tab. I have provided a link to the stand-alone Cloud Shell environment below.
In addition to the browser based Shell environment that Microsoft provides, which does support both of the scripting languages: PowerShell and Azure CLI. You can also install the latest Azure PowerShell modules or Azure CLI interfaces into your environment and then run the commands through any terminal that will recognize the CLI commands, such as the Integrated Terminal in Visual Studio Code. Let’s take a look at how this would look for both the Azure CLI and PowerShell:
NOTE: One of the advantages of using Cloud Shell over your Integrated Terminals is that your authentication is handled by the web interface. You will not have to go through any additional authentication based steps. However, using the Integrated Terminal in Visual Studio Code or the PowerShell ISE will provide you with a Intellisense based development environment that you cannot get in Cloud Shell.
Conclusion
Hopefully this gave you a starting point for getting access to your own Azure subscriptions through one of the many interfaces available. Needless to say, I am not able to go into depth with all of the possible interfaces, but that is why this is called Azure 101. Keep an eye out for other similar blog posts that you can use to learn even more about what Azure provides. Also, if you would like to learn more about some of the other possible interfaces, take a look at the links below as they should provide you access to additional documentation on the subject.
