Deploying to Azure Using OpenID Connect

In this chapter, we’ll embark on an exciting journey of deploying applications to Azure using the dynamic combination of GitHub Actions and OpenID Connect (OIDC) authentication. With a focus on security and efficiency, we’ll explore various configuration options to create workflows that seamlessly authenticate and authorize themselves against Azure resources. Leveraging the robust capabilities of the Azure CLI and Bicep, we’ll establish the core infrastructure required for our deployments. By implementing a secure connection between GitHub Actions and Azure, we’ll ensure that our workflows possess the necessary permissions to interact with Azure resources, safeguarding sensitive information.

Our exploration begins with creating core infrastructure via the Azure CLI and Bicep. We’ll establish the essential authentication and authorization mechanisms using basic service principals. This foundation will allow...

Technical requirements

To follow along with the hands-on material in this chapter, you must follow the steps in the previous chapter or access the resources from that chapter if anything is ambiguous to you.

In addition to this, you will need the following:

• You will be required to have access to an email address to set up an Azure trial. You can set this up for free at https://azure.microsoft.com/free/.
• You’ll also need to follow Microsoft’s Install Bicep tools guide for your given IDE. In some cases, there is an extension available, such as for Visual Code and Visual Studio; however, if your chosen IDE is unavailable, you’ll have to use the CLI, which can normally be invoked by the IDE terminal window. Instructions for the CLI download and known IDE extensions can be found at https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/install. It’s recommended that you complete this before moving forward. It’s also recommended...

Exploring our infrastructure using Bicep

In this section, we’ll delve into the world of Bicep and explore its capabilities in providing essential Azure infrastructure components required throughout this chapter.

Bicep is a domain-specific language (DSL) that’s designed to define and deploy Azure resources. As a declarative language designed specifically for Azure resource deployment, it streamlines and simplifies the process of constructing and managing Azure resources. Creating infrastructure in Azure with Bicep is a breeze with its user-friendly syntax and intuitive structure; it represents a significant advancement in the field of cloud infrastructure management for Azure.

Here, we will uncover the core principles of Bicep, examining how it transforms complex infrastructure code into more readable, maintainable, and concise configurations, thereby empowering developers and IT professionals to orchestrate their Azure environments efficiently. The core Azure components...

Deploying locally with the Azure CLI

Bicep simplifies the deployment and management of Azure resources by providing a domain-specific language compiled into ARM templates using bicep-cli. Authorization for bicep-cli is facilitated through the Azure CLI, ensuring seamless integration and secure access to Azure resources.

In our Bicep implementation, we’ll begin by organizing our resources in a single main.bicep file and use separate resource-type files to enhance reusability. These .bicep files contain the definitions of our resources, making it easier to manage and maintain our infrastructure as code.

For a smooth development experience, you can use the Bicep extension in Visual Code or Visual Studio, which utilizes the Azure CLI internally. This extension offers a user-friendly interface, allowing you to interact with Bicep through prompts instead of running Azure CLI commands directly.

Throughout this section, we’ll guide you in deploying your infrastructure...

Deploying infrastructure alongside our application code

So far, we’ve created modules for reuse. In this section, we’ll focus on creating an implementation of these new modules. By taking a module-first mindset approach, you will work toward building a reusable library of modules for you and your team to use. You will find that most implementations will only be the calling of the module and provide a couple of parameters for use, leaving the naming convention policies to be managed by the module.

Before we jump into this, we have a bit of cleanup work to do.

The teardown

First, we’ll need to destroy the container registry we created previously. To do this, open the resource in Azure, click the Delete button, and click Yes:

Figure 7.6 – Confirm deletion of the resource

Through this hands-on experience, we’ll gain practical knowledge of Bicep’s capabilities and how it interacts with Azure services. By exploring...

Authorizing our deployments with Azure and OIDC

In this section, we will set up Azure so that we can authorize as our service principal using OIDC, which will have the required access rights to deploy to our infrastructure within an environment. As we covered OIDC in the previous chapter, we’ll jump into some specifics of Azure Identity and the steps required to roll this out.

There are a couple of ways to achieve this: we could set up an application or a GitHub credential under the Certificate & secrets section of the application in Azure. Those options are self-explanatory in the Microsoft Learn documents if you want to use them, and they provide a lot of launch and provision steps.

I will show you the Other issuer for Federated credential scenario to authenticate with a service principal, which allows you to set up an OIDC configuration with a few more options, making it more flexible for our use case.

To do this, what’s required here is a managed identity...

Summary

In this chapter, we explored Azure infrastructure using Bicep, a powerful and efficient language for defining and deploying Azure resources. We delved into the fundamentals of Bicep, including resources, modules, and parameters. With this knowledge, we created and deployed our infrastructure using the Azure CLI, setting up resource groups, container registries, and container instances. To enhance security and access control, we discussed important practices such as image scanning and utilizing service principals for image access from ACR. Additionally, we explored leveraging secrets or Azure leases via HashiCorp for managing sensitive data.

One of the highlights of this chapter was our focus on creating reusable workflows for both application and infrastructure deployments. We learned how to migrate existing actions to reusable workflows, offering a more streamlined and consistent approach to managing our deployments. Utilizing OIDC for authorizing deployments in the reusable...