Devops professional projects & focuses

I am working on various Devops projects at the moment. Please see below a few examples of projects that I have been focussing on professionally

As an administrator of two Azure tenants with very different goals and purposes, the projects I work on can be very varied

Azure IAM & RBAC

My day to day includes the administration of three different Azure tenants; two of these are work related and consist of a Production, Stage, QA and UAT environment for websites and supporting workloads, such as SQL, Automation Accounts, Front Door and Monitor. The third tenant is my own personal tenant, which hosts this site as a showcase and has various services created in Storage Accounts, Automation Accounts and VMs.

I administer all of these tenants as one of the primary Global Administrators, and central to this responsiblity is the practise of always following best practise. This includes following the principle of least privilege.

When I inherited responsibility for both of the Azure tenants, I set out to establish and enforce best practise in all areas, especially during the assignment of IAM permissions. This was an essential task as experience varied between services and I also carefully needed to control the provisioning of services to ensure careful scaling, and to work within budget limitations

Users

It is imperative for a user to be given only the access that they require in order to adhere to the privilege of least privilege. This means, for example, a user who needs write access to a Storage Container only requires the Storage Blob Data Contributor at the Container level (not at the Storage Account level!) and only Contributor access is required, not Storage Blob Data Owner. It is important to note, however, that if a user needs to access a Sotrage Container through the Azure Storage Explorer, Reader access is required.

Service Principals

I have been using Service Principals to deploy code to App Service using both Azure Devops and Bitbucket, plus a range of Automation runbooks. Adhering to the principal of least privilege means providing Contributor access to these Service Principals, separately at the relevant Resource Group level.

Managed Identities

The use of a Managed Identity is to tie Azure resources together, which of course is in contrast to a Service Principal which is useful for allowing external services to access Azure resources, such as to deploy code.

I have been using Managed Identities recently to facilitate the back up of SQL databases. This is done through the use of an Automation account, which also provisions the Managed Identity. The Runbook, containing a Powershell script, uses the permissions that are assigned to the Managed Identity to access resources, in this case SQL Server and Storage Containers.

It is important to note that permissions for a Managed Identity need to be assigned through IAM. This means separately for Storage Containers and SQL Server

Managed Identity

Microsoft Entra

Bicep & ARM

I use Bicep to run blue/green deployments, which involved provisioning a new "blue" or "green" environment using Bicep, integrated with an Azure Devops pipeline. As part of the process and once infrastructure had been deployed, a DNS switch was needed for production to ensure the live site was pointing to the new release.

Once complete and verified and a few days later, the old stack could be torn down.

Azure Devops & Bitbucket

As part of my current role, I am responsible for day-to-day administration of both the Azure Devops and Bitbucket environments, which includes administration of pipelines, repositories and the development of YAML files that support each pipeline. The site that is being released has an effect on the environment used and both Azure Boards and Jira are used for ticketing.

Additionally, I am responsible for the following:

Security & Secrets

I have always kept all Secrets stored in Azure key vault. This includes secrets that support both Azure Devops and Bitbucket, in complete adherence to best practise. Secrets are then stored as variables to be used during deployment.

azdeploy

Monitoring & Logging

I have always found Azure Monitor to be a hugely beneficial and useful area on Azure to monitor infrastructure and applications - I find it's uses and capabilities quite unmatched when compared to other vendors. Colleagues who work in other infrastructure areas often take extended periods to attempt to diagnose infrastructure/application issues, whereas working with Azure Monitor and especially Application Insights, I find it much easier to diagnose and visualise issues efficiently before troubleshooting

Logging is an area that I find compliments the Monitoring section of Azure very well. It is essential to ensure historic logs can be queried:

Use of Git

I have so much fun using Git! Though it is extremenly important to understand the power of Git and the effect of commands. With this in mind, it is essential to ensure best practise is always followed, which includes never committing directly to the main/master branch!

Some example commands that I use regularly:

git-gif

Once a commit has been made to a feature branch or develop branch for example, a pull request is always required to merge to stage. From that point I would either merge further to main/master, or, if deploying to App Service, I would swap the slots to release changes that have been deployed to the stage slot, to production. This is an areas that I find App Service really excels, with the ability to swap slots to deploy to production, but also to swap slots back again quickly and efficiently.

Scripting / Automation

I use Azure automation with Powershell Runbooks to reduce manual overhead and enforce consistency across the various environment and Services that I work with.