![]() ![]() Next up, you will notice several management related options. 443 outbound to certain endpoints) if you have used a self-hosted agent in the past. This is a very similar approach to Azure DevOps (e.g. Please review the required GitHub URLs that are needed to communicate back to GitHub. You should not need inbound connection to the Azure Virtual Machine from GitHub. You would likely have a jump box, Azure Bastion host or similar to ‘hop’ onto the Virtual Machine, so that you can keep it restricted from the public internet. IMPORTANT: In a production environment, this is not something that you would do. ![]() Though, be aware of the security risks that this brings - especially opening up port 22 to the public internet. If not (like my test environment), then you could opt for a Public IP. If you already have access to a jump box or Azure Bastion Host, then you could keep the virtual machine deployment as private, and login through that approach. Overall, we’ll need to make sure that we have access to the Virtual Machine. That’s perfectly fine for my requirements. This gives me the benefit of having a cost-efficient option, while having consistent performance at a lower level of IOPS. Tip: You can find a comparison of the disk options in the Azure Docs. Screenshot showing the initial Virtual Machine creation blade in the Azure Portalīeing cost conscious, I also decided to change the OS disk type to Standard SSD (locally-redundant storage). I’ve also selected the SSH public key authentication type and supplied my usual SSH public key, so that I can go ahead and easily authenticate using an existing public/private key pair from my local machine. This would of course depend on our build/deployment workflow, and if we had any additional requirements as part of that process. For the purposes of demonstrating this blog post, I’ll also create a relatively small virtual machine as we don’t have any significant requirements. I’m going to create an Ubuntu Server 18.04 LTS - Gen 1. You can do that either by typing Virtual Machine into the search bar at the top, or select Virtual Machine from the Azure Marketplace. Let’s navigate to the Azure Portal, and create a new Virtual Machine. This will allow us to enable the System Assigned Managed Identity functionality on the Virtual Machine, that the azure cli and the az login command would be able to leverage. Creating a Virtual Machine to host our GitHub self-hosted runner in AzureĪs we want to login with a System Assigned Managed Identity, we’ll first need to create an Azure Virtual Machine so that we can host the self-hosted runner. To use a managed service identity, we’ll need to be running on an Azure resource. In the meantime, let’s get our pre-requisites setup. I’ll talk a little about some of the drawbacks a little bit later on in the post, compared with using the Azure/login action. ![]() ![]() Given that I’m writing this blog post, you’ve likely already guessed that I have found a solution. However, from my initial research - I wasn’t able to see a way use the Azure/login GitHub Action to deploy into Azure using a System Assigned Managed Identity. Typically, the process is to use the Azure/login GitHub Action, and then use the azure/cli or another Azure GitHub Action to deploy into GitHub. I recently started thinking about the typical setup process for a GitHub Action Workflow which will requires access to Azure.
0 Comments
Leave a Reply. |