On a day-to-day basis, I’ll be looking up tickets by their reference numbers. Why? Why can’t I just get these tickets off of the current sprint board? Well, I don’t know about you, but I’ll be in the middle of a ticket, and a tester, business analyst, or product owner will drop me a message asking about XYZ-999.

What on earth was XYZ-999? I’ve managed to save a large amount of time by introducing custom search engines into google for simple tasks as quickly searching for a ticket reference.

Or even just looking up active pull requests or trying to find some documentation on confluence.

In this short article, I’ll share how I go about doing this so that you can save yourself some time, sure it’s 20-30 seconds here or there, but that adds up over a year.

Adding a custom search engine to Chrome

Open Chrome and right-click the address bar, and click Manage search engines...

Click the add button. Under the section other search engines, a small popup will show with 3 form fields to fill in.

Search Engine:
Keyword:
URL with %s in place of query

Fill this in with the info about your search engine. For example, confluence my be something like:

Search Engine: Wiki
Keyword: wiki
URL: https://<company>.atlassian.net/wiki/search?text=%s

How to use a custom search engine

Once you’ve added a custom search engine, you can use it by clicking on the address bar and using the keyword, followed by a space, then the text you want to search for, then press enter.

wiki which badger danced the best duck?<enter>

Examples from my uses

Search Engine: Jira
Keyword: jira
URL: https://<company>.atlassian.net/browse/ref-%s

Search Engine: BBPRs
Keyword: bbpr
URL: https://bitbucket.org/<company>/<repo>/pullrequests/%s

Search Engine: Gihub_ProjectPRs
Keyword: ghpr
https://github.com/<company>/<project>/pulls

Search Engine: Gihub_AllPRs
Keyword: ghapr
https://github.com/pulls

Wrap Up

This has been a very short post, but it is what it says on the tin, a very simple post showing you an easy tip to make searching GitHub, Jira, etc., much easier.

Sometimes things just go wrong, and the default error messages coming out is less than helpful.

This was the case for me this morning, I still don’t know why this happened, but when running terraform init, I would get the following error:

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/azurerm versions matching "2.9.0"...
- Installing hashicorp/azurerm v2.9.0...

Error: Failed to install provider

Error while installing hashicorp/azurerm v2.9.0: open
.terraform\plugins\registry.terraform.io\hashicorp\azurerm\2.9.0\windows_amd64\terraform-provider-azurerm_v2.9.0_x5.exe:
The system cannot find the path specified.

While this is a good error, it wasn’t enough to work out what the problem is. Fortunately, Terraform offers verbose logging, which gives way more information making it easier to debug through the issue.

You can find out more about Terraforms logging info in the Debugging Terraform section of the documentation. I highly suggest enabling verbose logging locally. The information is written out is much more helpful when running init, plan or apply.

It wasn’t immediately apparent how I would enable more verbose logging, so below are instructions for enabling this on both Windows and Linux. I set mine to TRACE, but you can also set the following log levels DEBUG, INFO, WARN, or ERROR. I went straight for the most verbose setting, as I wanted to dig through exactly what had gone on in hopes of finding out what was going wrong.

Configuring Terraform logging

To enable the different levels of logging, Terraform requires you to configure two environment variables, these are TF_LOG and TF_LOG_PATH. You need to configure both of these. Otherwise, you won’t get any additional logs. I chose to call my log file terraform.log, but you can name it whatever you like. You can also output the file where ever you want.

Enabling in your current session

If you only want to enable this level of logging temporarily to work through a problem, then you can configure these settings just for the session you are working in. Here’s how to enable these both in PowerShell and Bash; the next time you run a terraform command, your log file will be created and will contain the verbose logging.

PowerShell

> $env:TF_LOG="TRACE"
> $env:TF_LOG_PATH="./logs/terraform.log"

Bash

$ export TF_LOG="TRACE"
$ export TF_LOG_PATH="./logs/terraform.log"

This works great when you just need these detailed logs for a single session. There are times when I’ve run Terraform within VS Code. The output to the console is so large that it overwrites the terminal buffer, preventing my ability to scroll back far enough to capture all the info I want. It’s for this reason that I’ve set this up as a permanent option, though I do suggest you add the log file to your .gitignore file.

Setting up verbose logging permanently for your profile

I’ve become a big fan of this setting, as it means my logs are persisted. There’s no need to rerun a command that failed with a deeper logging level to determine what went wrong as the error is already in my logs.

PowerShell Profile

To set this up as a permanent option in your PowerShell profile, you’ll need to open your Powershell profile. This is simple enough to do with the $profile command in a PowerShell console. Just simply type $profile, and it will output the location of your profile file.

Open that file up and add the following two lines (you can change the name and location to suit you):

# Terraform log settings
$env:TF_LOG="TRACE"
$env:TF_LOG_PATH="./logs/terraform.log"

Close and reopen PowerShell and type the following to verify that the change has worked:

> echo $env:TF_LOG
TRACE
> echo $env:TF_LOG_PATH
/logs/terraform.log

Bash Profile

This is almost exactly the same as the PowerShell method, except the file name and location is different. Open your .bashrc file, which you can find located in your $home directory, then add the following lines:

# Terraform log settings
export TF_LOG=TRACE
export TF_LOG_PATH="./logs/terraform.logs"s

Close your bash console and reopen, and type the following to confirm the change has worked correctly.

$ echo $TF_LOG
TRACE
$ echo $TF_LOG_PATH
/logs/terraform.log

Wrap Up

That’s it. That’s all you need to do to get some really useful logs out of Terraform. Thanks to the verbose logging, I was able to find out what had gone wrong, though why I still don’t know.

The azurerm provider exe wouldn’t populate in the plugins folder. The folder’s paths would, just not the exe. The logs showed that the file was accessible over TCP but still nothing.

In the end, I just downloaded the file manually and placed it in the correct location. While that’s not the most ideal solution, it was enough to allow me to crack on with the rest of my day.

Thanks for reading. I hope this has been some use.

I hadn’t done this before, but surely it would be easy? Right? Well, it’s not difficult, but it’s also not as straight forward as you might expect, even more so if you work primarily on a windows machine.

The standard way to enable multiple GitHub logins on a single machine is to generate multiple SSH keys and alias the repo’s URL. First things first.

Generating the SSH Keys

Before you attempt to generate an SSH key, you should check for any existing SSH keys on the machine. If you are on a Mac/Linux, this can be achieved by running ls -al ~/.ssh; this command will list out of the existing and private key pairs if any exist.

If you are on windows like myself, then the keys exist in:

C:\Users\<username>\.ssh\

If the default key pair exists ~/.ssh/id_rsa, this can be used. Otherwise, we can generate a default by running:

ssh-keygen -t -rsa -C "your email address."

• -t stands for ‘type’

• -C is for comment

You can run the command without passing in a comment; when you run the following, you’ll see the following: * if you are on windows and see an error, scroll down *

Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/<your_username>/.ssh/id_rsa):

Copy and paste the path /c/Users/<your_username>/.ssh/ and add a unique file name i.e. /c/Users/<your_username>/.ssh/id_rsa_githubPersonal

Make sure that you do not override the existing id_rsa, as this is your existing key, which you may have set up for GitHub or some other ssh connection

you will then be prompted for a passphrase

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

You can enter a passphrase, or you can press ‘ENTER’ twice to leave it blank.

you can check the folder c:/Users/<your_username>/.ssh/ on windows or for mac/linux run ls -al ~/.ssh

• ls list all the files in the current directory

• a is for listing all of the files, including the hidden ones

• l is for a listing in a long format

You should get an output somewhat similar to this:

total 46
drwxr-xr-x 1 your_username 1049089    0 Jan 26 10:40 .
drwxr-xr-x 1 your_username 1049089    0 Jan 23 12:12 ..
-rw-r--r-- 1 your_username 1049089 3309 Nov 30 11:21 id_rsa
-rw-r--r-- 1 your_username 1049089  547 Nov 30 11:21 id_rsa.pub
-rw-r--r-- 1 your_username 1049089 2675 Jan 26 10:40 id_rsa_githubPersonal
-rw-r--r-- 1 your_username 1049089  254 Jan 26 10:40 id_rsa_githubPersonal.pub
-rw-r--r-- 1 your_username 1049089  399 Nov 30 12:08 known_hosts

Either via the console or from the folder view, you should be able to see the new SSH key file that you’ve just created. as you’ll see above, I have two files, id_rsa_githubPersonal and id_rsa_githubPersonal.pub

• id_rsa_githubPersonal this is your private key, which is stored on your machine

• id_rsa_githubPersonal.pub this is your public key. This is the one we’ll give to GitHub

Before we move on, here’s how to fix this error when running this on windows.

‘ssh-keygen’ is not recognized as an internal or external command

So I ran ssh-keygen and got “‘ssh-keygen’ is not recognized as an internal or external command”, I had git for windows installed, my PATH variable was set properly. (make sure your PATH variable has C:\Program Files\Git\cmd)

Yet, still, the command would work.

For the command to work, you need to have ssh-agent started. I had a quick looking in services.msc and couldn’t see any service named ssh-agent or anything similar, now I was being a doughnut. It’s not uncommon. I fell back to Powershell: Start-Service ssh-agent

If you don’t want to be a doughnut like I was when looking in services.msc, look for OpenSSH Authentication Agent

That, however, resulted in:

Unable to start ssh-agent, error :1058

This error is because while ssh-agent is installed, the service isn’t started. To prove this, you can run the following:

 > Get-Service ssh-agent

You should see something like this:

Status   Name               DisplayName
------   ----               -----------
Stopped  ssh-agent          OpenSSH Authentication Agent

Ok, so it’s stopped. Actually, mine was disabled, which you can see by running:

> Get-Service ssh-agent | Select StartType

StartType
---------
Disabled

To start the service, run the following:

> Get-Service -Name ssh-agent | Set-Service -StartupType Manual
> Start-Service ssh-agent

This can all be done in the GUI; make sure to look for OpenSSH, not SSH Agent like I did.

Now in a new console window, if you type ssh-keygen it suddenly works!

Adding your new SSH key to the GitHub account.

Now that we’ve generated the public SSH key, we need to add it to your GitHub account.

First things first, we need to copy the public key, on windows open c:/Users/<your_username>/.ssh/id_rsa_githubPersonal with your favorite text editor. I suggest VsCode.

On Linux/Mac, you could use atom ~/.ssh/id_rsa_githubPersonal; the text editor you use is entirely your choice. When the file is opened, it should look something similar to this:

ssh-rsa AAAAB5hgxC1yc2EAAAADAQABABABAQDEmSbc7ms4TFIf7G0e9EqdrQRTB17VFTqRtCbQ55sSc11xZP5B07UXf9+................a955cf1GUzsNIr60E7VuVxirrr+K2.............nDEg1H/VbyJtEekh4Aav9csQw3r7y test@codewithadam.com

The key is longer than this, but I’ve shortened it and randomized it a bit for the tutorial.

To add this to your GitHub account, go to your Github account -> Settings -> SSH and GPG keys

Click on the New SSH key button.

Give your new SSH key a title, and then paste the new SSH key you copied earlier. I suggest naming your keys after the machine they are from and the purpose, i.e., personal, company, etc.

Registering the new SSH Key with ssh-agent

Now that we’ve created a key and added it to GitHub, we need to add it to our SSh agent. and this can be done by running:

ssh-add ~/.ssh/id_rsa_githubPersonal

windows:

ssh-add c:/Users/<your_username>/.ssh/id_rsa_githubPersonal

Now we have two choices as to how we want to work with the SSH keys going forward. First, we’ll cover the SSH configuration file. Secondly, I’ll show you how to have only one SSH key active in your ssh-agent at any one time.

Creating the SSH config file

In this file, you can specify different SSH configuration rules for different hosts, depending on the host in use will determine which SSH key to use.

The SSH config will live at ~/.ssh/ or c:/Users/<your_username>/.ssh/ and is a file called config. To create this file, you can use a few methods such as $ touch config, but I tend to use vs code so $ code config

This is where the magic happens. Update the config file to use your SSH keys like so:

# Personal account 
Host github.com
   HostName github.com
   User git
   IdentityFile ~/.ssh/id_rsa_githubPersonal
   
# Client account
Host github.com-clientX
   HostName github.com
   User git
   IdentityFile ~/.ssh/id_rsa_githubClientX

clientX is the GitHub user id for the client I am providing services to.

By using github.com-clientX as a notation, It can be used to differentiate the various Git accounts. However, you can also use “clientx.github.com”. I suggest being consistent with whatever notation you use. This becomes very relevant when you clone a repository or update the remote origin URL.

The configuration above tells the ssh-agent to:

• use id_rsa_githubPersonal for any git URL that uses @github.com

• use id_rsa_githubClientX for any git URL that uses @github.com-clientx

One SSH Key active in ssh-agent at any one time

This approach doesn’t require an SSH config file. Instead, you’ve manually ensured that the ssh-agent has only the relevant active ssh key attached for your GIT operations.

ssh-add -l will list all the SSH keys attached to the ssh-agent at that moment in time. You would then remove all but the one you want to use. The easiest way to do this is to remove them and then re-add the key you want to use. You can do this like so:

$ ssh-add -D            //removes all ssh key entries from the ssh-agent
$ ssh-add ~/.ssh/id_rsa_githubPersonal                 // Adds the relevant ssh key

The ssh-agent now only has the key that’s mapped to my personal GitHub account. When I do a git push to my personal repository, it will use that key.

If I need to push to my client’s repository, then I’ll need to rerun the command but this time specifying the client’s key.

$ ssh-add -D 
$ ssh-add ~/.ssh/id_rsa_githubClientX

Setting the git remote URL on the local repositories

for the repositories that already exist on your machine, you can update the URL by running the following command:

git remote set-url origin git://<hostname>/<path to repo>.git

i.e.

git remote set-url orgin git://github.com-clientX/ClientX/AllTheCodes.git

Make sure to set the git username and email in each repo, which can be done by going into the repo and running git config user.name and git config user.email.

git config user.name "user x" // updates the git config username
git config user.email "userx@client.com" // updates the git config email

if you’ve done a git init then to set the remote URL, you can use the following

git remote add origin git@github.com-clientX/ClientX/AllTheCodes.git

Obviously, making the changes to match your SSH config and git URLs.

Just make sure that the string between the @ and : match the host you specified in your ssh config.

You can then push your initial commit to your GitHub repo.

git add .
git commit -m "Initial commit"
git push -u origin master

setting the host while cloning repositories

Like the above step, when we clone a repository for the first time, we can change the host to match the ssh key we want to use.

So hop into GitHub and grab the SSH clone URL; it’ll look something like this:

git clone git@github.com:personal_account_name/repo_name.git

update it to tie into the ssh-key

git clone git@github.com-clientX:acct_name/repo_name.git

The change I’ve made here is to update the host to match the name that I’ve set in the SSH config. The string between @ and : should match the SSH config.

Wait… I can’t use SSH Keys; GitHub config blocks it.

Ah… Welcome to my world.

After completing all of the above myself, I went to pull the latest from the client’s repository to be faced with an error stating that the use of SSH keys was prohibited and would need explicit approval.

My client had decided that personal access tokens were the way forward and that SSH was a no go. Fortunately, that has worked out well for me.

My personal GitHub Repos all use SSH and the methods I’ve detailed above; my current client uses personal access tokens, so I authenticate with GitHub over HTTPS using my email as my username and the personal access token as the password.

If you go to Your GitHub Account -> Settings -> Developer Settings -> Personal Access tokens, you can generate a new token there.

When you try to pull/clone on windows, you’ll get a popup asking for your username and password; enter your email and then the personal access token as the password. This will be stored in your credential manager.

This is what I’ve done, and it works very well. One caveat is that while you can add multiple entries within the credential manager (hit windows key and type Credential Manager, or enter it into the search bar), only one of them will work; the other won’t, so you can have both your personal and client credentials in the credential manager. Though I didn’t test out whether by modifying the host as we do above for the SSH config, whether that would work…

I get “remote: Repository not found” when I try to use the personal access token

This happens because you already have a GitHub credential cached in your system. That token doesn’t have access to the repositories you are trying to access. As above, open Credential Manager and update the credentials.

Wrap Up

Hopefully, this has helped you get your git all set up to work with multiple accounts. I know that I am happily working away with no problems now. I had hoped to find something like google where I can be logged into multiple email accounts at the same time, being able to open them all independently. Unfortunately, this isn’t something that GitHub supports. Instead, I ended up creating a new profile in Chrome and using that for the client-specific logins.

Testing them.

Typically, there are a finite number of environments that you can use to work on, i.e., Dev, Test, PreProd, etc., etc. Every company I’ve worked for has its own set of environments and naming conventions for those environments. That’s a bit irrelevant here. As developers, we have localhost, which doesn’t quite work the same as it does when deployed. There’s always a gotcha, i.e., if you are using Azure API management, well, you won’t be using that locally, and many other sorts of things. So feature branching works great for the most part locally, but when it’s pushed out to an environment for testing, we come up against an issue.

Firstly, that environment is now isolated to that feature. Any schema or data changes specific to that feature are now locked in. We can’t just deploy another feature branch as the data and or schema is out of sync. Also, testing resources… you may have several testers within your team. Now that the environment has been occupied by a feature, only the tester[s] involved can work on that feature; the others are sat, stuck waiting.

Sure we can have Dev1, Dev2, etc., or if your sprint team has a name, i.e., Nomad1, Nomad2, corpo4, etc., that gives some flexibility.

But, what if you could create an environment that is set up for isolated testing of just your work, regardless of data changes? Multiple features in test at any given time, the ability to have a dev/test feedback cycle isolated to just your changes, no undue pressure to get your work done, other than the sprint deadline, not “oh, I’ve got to release this environment so Y can get their work on it”.

Having an environment that exists just long enough for the work to be done, tested, and then merged back into the main development branch? Wouldn’t that save you money not spinning up (x) number of environments which may or may not be utilized, just sat waiting doing nothing, depending entirely on the throughput of the team, i.e., one sprint you may need 4 environments, the next 2. leaving 2 fully-fledged environments costing your company for no reason.

Well, you can, you can utilize your azure pipelines and your ARM/Terraform scripts to generate an environment isolated to just your changes, not just that, but you can do so for free or “almost free”, using the free tiers of Azure’s products and sharing the ones that cost money, the sharing aspect might not be ideal for every situation, but in those situations having one or two fully-fledged environments available is still a darn sight cheaper than having a range of environments sat about for no reason, personnel resource waiting while they wait for environments to clear up.

How it’s done.

I’ll show you an example of how I’ve accomplished it and how it worked in the teams. It won’t be a fully-fledged tutorial with all of the arm templates hanging about. I can’t see the value in that, your setup will be unique to you, so there will be some work to pull apart a chosen environment and see where you can split this out into isolated per deployment environments.

I will show you how to trigger a build that identifies the branches to build from.

Basically, I’ll show you how to enable this, but this isn’t a copy/paste exercise; it will require work on your side. I would suggest wrapping all the components into a single resource group for each feature branch.

i.e. rg-featurebranch-{env}

This will allow easy removal of these feature branches once they are done with, as we can just delete the entire resource group, which will take care of the removal of the unique resources.

Consul

In the past, I’ve done the same using consul and updating the consul config to point to a different deployed service rather than the official release for that environment. As an aside, a neat trick is to use technology such as mountebank. This can mock away entire services, allowing your UI to get responses similar to those it would from a real service. Enabling your front end team to work on the front end while the backend team creates the backend. A really handy feature of this is that with mountebank, you can simulate things going wrong, so the UI can specifically handle errors not easily replicated when the backend is present. I’ve even used it to simulate intermittent backend failures. You end up building a very robust front end when you utilize technologies such as these.

Triggering a feature branch build via PowerShell

The majority of the work is going to be handled by your azure pipelines. Still, we need a way to tell azure pipelines to generate a build against a specific branch and to give it an environment name, i.e., the name of your feature branch. For example, if you are using JIRA or any other issue tracking, work tracking system, there is usually some form of a unique identifier for the ticket that you are working on. This is a fantastic identifier to use as it links the agile/issue tracking board item to your environment. You can also have your build server update the ticket with information about the environment.

Such as the CosmosDB access token for the environment (should you use cosmos).

To do this, we’ll need to create a PowerShell script that can be run. This script will need a few pieces of information.

• the user’s email address

• the users access token for Azure DevOps, which can be generated here: https://dev.azure.com/{organization}/_usersSettings/tokens

• the name of the branch the user wishes to build

• the environment name

• (optional extra) the issue tracking ticket reference. This is so the build server can update the ticket with the build info; this is optional as you’ll need to implement the call to your issue tracker.

The PowerShell script will also need to know the project guid reference to trigger a build within; this can be found by calling this URL: https://dev.azure.com/{organization}/_apis/projects?api-version=5.0-preview.3. within the JSON response, you’ll see id and URL; both hold the guid you are looking for.

Here’s an example PowerShell script

param(
    [string] $emailAddress,
    [string] $token,
    [string] $branch,
    [ValidateLength(1,5)]
    [string] $environmentName
    [string] $ticketRef,    
)
$ErrorActionPreference = "Stop"
if (!$emailAddress) {
    Write-Error -Message "email address required -emailAddress"
}
if (!$token) {
    Write-Error -Message "Please provide azure devops access token: https://dev.azure.com/{organisation}/_usersSettings/tokens (Token needs Build Read & execute permissions) -token"
}
if (!$branch) {
    Write-Error -Message "Please provide the branch name to build -branch"
}
if (!$environmentName) {
    Write-Error -Message "Please provide an environment name -environmentName"
}

if (!$ticketRef) {
    Write-Output -Message "No ticker Reference Provided. Unable to update ticket with feature branch information"
    $ticketRef = "NA"
}



$environmentName = $environmentName.ToLower()

$body = '
{
    "stagesToSkip": [],
    "resources": {
        "repositories": {
            "self": {
                "refName": "refs/heads/' + $branch + '"
            }
        }
    },
    "templateParameters": {
        "ticketRef": "'+ $ticketRef + '",
        "EnvironmentName": "' + $environmentName + '"
    },
    "variables": {}
}
'
$bodyJson=$body | ConvertFrom-Json
Write-Output $bodyJson
$bodyString=$bodyJson | ConvertTo-Json -Depth 100
Write-Output $bodyString
$user=$emailAddress
$token=$token
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $user,$token)))

$Uri = "https://dev.azure.com/{organisation}/{projectGuid}/_apis/pipelines/{definitionId}/runs?api-version=5.1-preview"  # get project guid from: https://dev.azure.com/{organisation}/_apis/projects?api-version=5.0-preview.3 - Definition ID can be found in the url of the build you are triggering.
$buildresponse = Invoke-RestMethod -Method Post -UseDefaultCredentials -ContentType application/json -Uri $Uri -Body $bodyString -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)}
Write-Output $buildresponse

So, we’ve got a PS script that will generate a build via the Azure pipelines rest api. But what should we build?

The build

This will be unique to you, but what I suggest is that this triggers your standard build template; the easiest solution would be to duplicate your main dev pipeline and update them. Firstly, you won’t want this to be triggered by anything, as this will be handled via the Powershell script.

You’ll want the build to write out some files about this PR build, specifically the environment name, which will be vital for the release process.

param(
    [string] $ParameterKey,
    [string] $ParameterValue,
    [string] $directory
)

Write-Output $ParameterValue.trim() | Out-File "$directory/$ParameterKey.txt"

 - task: PowerShell@2
    displayName: Write EnvironmentName to a file
    inputs:
      targetType: 'filePath'
      filePath: $(Build.SourcesDirectory)\build\build_pipeline_scripts\write-BuildParameterToFile.ps1
      arguments: -ParameterKey "EnvironmentName" -ParameterValue "${{ parameters.EnvironmentName }}" -directory "$(Build.ArtifactStagingDirectory)/environment-info"
    env: 
      SYSTEM_ACCESSTOKEN: $(system.accesstoken)
  - task: PublishPipelineArtifact@1
    displayName: Package environment-info artifact 
    inputs:
      targetPath: '$(Build.ArtifactStagingDirectory)/environment-info'
      artifact: 'environment-info'

The rest of the build process will most likely mirror your existing pipeline, perhaps with a step here or there missing, such as not running code analysis on the build.

This can now trigger your feature branch environment release.

The release

One of the differences we’ll make to the release is that this will update the variables beforehand to include the feature branch environment name; we saved this in a folder called environment-info and a file named EnvironmentName.txt

• Step 1 - deploy the infrastructure (Cosmos, storage accounts, queues, etc.)

• Step 2 - Deploy code-based things such as function apps

• Step 3 - Provide access tokens

• Step 4 - API Management and the like

Step 1

So perhaps you have a storage account name variable in the main pipeline, then I suggest that this updates that variable to include the environment by running a script: Write-Host "##vso[task.setvariable variable=STORAGE_ACCOUNT_NAME]yournamingconvention$env"

Do this for all the infrastructure that doesn’t need to be shared. i.e., function apps, cosmos, storage, queues, etc.

It’s then a case of letting the release happen as it normally would; the only difference here is that the variables have been updated to include the environment, so each deployment will be unique. and asides any updates to the ticket via the ticketing system api

Step 2

As with step one, the main difference here is that we’ll update the variables to include the environment name; this is so we know where to deploy the code and also making sure that the software services have unique and identifiable names, i.e., FUNCAPPCACHERESETTER in dev would be FUNCAPPCACHERESETTER_1021 in your feature branch, assuming the reference was 1021.

Again, this release pipeline step will match your development one after the variables have been updated. asides any updates to the ticket via the ticketing system api

Step 3

Once the deployment of step 1 & two has been successful, we can use Azure Powershell to get the variables access tokens from storage accounts, cosmos, function apps, etc. This information can then be published on teams, slack, etc. Added to your ticket within the ticketing system.

As we have an environment now in Azure, all contained in its own resource group, any access tokens can be picked up by going to the individual resource. You may have app insights or log analytics enabled for your feature. As such, you can access those logs within your resource group.

Within the pipeline, you may have acceptance tests triggered against dev; if so, like we’ve modified the infrastructure, we can modify these to take in various variables, allowing you to run these acceptance tests against your version of the deployed assets, which should give you a high level of confidence that everything is working as it once was before you merge your changes to the develop or master or whatever branch. It also allows your testers (or yourself?) to add further acceptance tests to cover the feature and test them against your deployed environment.

Step 4

If you use something like API Management, then you’ll want a way of calling your APIs for your feature branch, bypassing the development ones. For example, This can be as simple as adding a header such as “x-featurebranch”. which can be used to route APIM to your APIs; you may need to also pass headers that have the relevant access token keys for each function.

The rest of your APIM policy will continue as is. Though you may have things, you need to change to work with your unique environment.

Wrap Up

When I started to write this post, I thought it would be much longer, but really, this builds on top of your very unique build and release pipelines. This turned into a “here’s an idea of how to” rather than a, here’s how to do it! I’m also not suggesting that this approach is the best, just an approach. There may be better ways to do this using Azure Blueprints or something entirely different.

The core concept that I hope I’ve shared is that it’s possible thanks to Azure, AWS, GCP, and the like to deploy infrastructure and code repeatably and uniquely. i,e. I can have a Development environment and an Adams Testing Badger land environment, which look exactly the same but run on their own instances of infrastructure and code. Because of this, we don’t need to keep environments hanging around, getting dirty, wondering why suddenly something isn’t working when it was yesterday, turns out someone changed a file.

No, we can deploy from scratch each time and do apples to apples comparisons, ensuring that tests pass repeatably. It also means that should we want to introduce load testing, we can. We can fire up a clean environment, load it with data, and hammer it. We’ll get predictable results each time, give or take the various networking and cloud platform niggles.

Event Hub decouples the produces of the events from the consumers reading the events. It can store events for up to 7 days. This helps you scale the application to fit with different load patterns that your customers might generate. Perhaps there is more activity during the weekend. Event hub support automatic scaling out and in.

Each event can be up to 256kb in size(this may have changed since writing, review the Azure documentation for latest limitations).

So, what is an Event?

An event is simply:

• a type of message

• Only contains information about what happened, not what triggered it. The sender and receiver are not dependant on each other.

• There are no expectations from the publisher as to how the event will be handled. The consumer will decide how it handles the event.

• Events Hubs can be easily integrated with both Azure and non-Azure services.

• You can automatically capture events to Azure blob storage or data lake as events enter the hub.

• An event can be consumed by multiple consumers from Event Hubs by using Consumer groups

Components of Event Hubs

• Namespace - Container for the event hubs

• ** Event produces** - Sends data to event hubs

• Partitions - Buckets of messages (1-32 partitions)

• Consumer groups - View of an event hub

• Subscribers - The applications that read events contained within an event hub

Create an Event Hub Client

Microsoft has amazing documentation and samples, so you can easily follow what’s shown in this article: Send events to and receive events from Azure Event Hubs - .NET (Azure.Messaging.EventHubs)

The client will look something like this:

using Microsoft.Azure.EventHubs;
using System;
using System.Text;
using System.Threading.Tasks;

namespace AzureEventHubClient
{
    public class Program
    {
        private static EventHubClient eventHubClient;
        private const string EventHubConnectionString = "{Event Hubs connection string}";
        private const string EventHubName = "{Event Hub path/name}";

        public static void Main(string[] args)
        {
            MainAsync(args).GetAwaiter().GetResult();
        }

        private static async Task MainAsync(string[] args)
        {
            // Creates an EventHubsConnectionStringBuilder object from the connection string, and sets the EntityPath.
            // Typically, the connection string should have the entity path in it, but for the sake of this simple scenario
            // we are using the connection string from the namespace.
            var connectionStringBuilder = new EventHubsConnectionStringBuilder(EventHubConnectionString)
            {
                EntityPath = EventHubName
            };

            eventHubClient = EventHubClient.CreateFromConnectionString(connectionStringBuilder.ToString());

            await SendMessagesToEventHub(100);

            await eventHubClient.CloseAsync();

            Console.WriteLine("Press ENTER to exit.");
            Console.ReadLine();
        }

        // Creates an event hub client and sends 100 messages to the event hub.
        private static async Task SendMessagesToEventHub(int numMessagesToSend)
        {
            for (var i = 0; i < numMessagesToSend; i++)
            {
                try
                {
                    var message = $"Message {i}";
                    Console.WriteLine($"Sending message: {message}");
                    await eventHubClient.SendAsync(new EventData(Encoding.UTF8.GetBytes(message)));
                }
                catch (Exception exception)
                {
                    Console.WriteLine($"{DateTime.Now} > Exception: {exception.Message}");
                }

                await Task.Delay(10);
            }

            Console.WriteLine($"{numMessagesToSend} messages sent.");
        }
    }

Create an Event Hub

Rather than walking you through this step by step, I’m going to defer to Microsoft who’ve put together this excellent article

To create an event hub, you’ll need to:

• Create a resource group

• Create an event hub namespace

• Create an event hub within the new or existing namespace

• Set your partition count (max 32), and message retention (max 7 days)

Once your event hub has been created, create a new shared access policy, I suggest you set send/list as permissions. Once created, copy the primary connection string. You’ll need this for deploying and testing.

Create an Event Hub .NET Core client

Again, Microsoft has amazing documentation and samples, so you can easily follow what’s shown in this article:

Send events to and receive events from Azure Event Hubs - .NET (Azure.Messaging.EventHubs)

You’ll end up with something that looks like this:

Create a function app trigger

Just create the default Azure function app trigger template for an event hub. This is shipped with visual studio.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.Azure.EventHubs;
using Microsoft.Azure.WebJobs;
using Microsoft.Extensions.Logging;

namespace MyFirstFunctions
{
    public static class EventHubHelloWorld
    {
        [FunctionName("EventHubHelloWorld")]
        public static async Task Run([EventHubTrigger("helloworld", Connection = "AzureEventHubConnectionString",  ConsumerGroup = "$Default")] EventData[] events, ILogger log)
        {
            var exceptions = new List<Exception>();

            foreach (EventData eventData in events)
            {
                try
                {
                    string messageBody = Encoding.UTF8.GetString(eventData.Body.Array, eventData.Body.Offset, eventData.Body.Count);

                    // Replace these two lines with your processing logic.
                    log.LogInformation($"C# Event Hub trigger function processed a message: {messageBody}");
                    await Task.Yield();
                }
                catch (Exception e)
                {
                    // We need to keep processing the rest of the batch - capture this exception and continue.
                    // Also, consider capturing details of the message that failed processing so it can be processed again later.
                    exceptions.Add(e);
                }
            }

            // Once processing of the batch is complete, if any messages in the batch failed processing throw an exception so that there is a record of the failure.

            if (exceptions.Count > 1)
                throw new AggregateException(exceptions);

            if (exceptions.Count == 1)
                throw exceptions.Single();
        }
    }
}

When I went to build, this is had two problems. Firstly the using Microsoft.Azure.EventHubs was showing as missing. I had to go and reference that NuGet package manually.

Secondly, the EventHubTrigger attribute was shown as unknown… (.net core), so it wouldn’t build. After some digging, I found this GitHub issue, which mentions that you’ll need to reference Microsoft. Azure.Web jobs.extensions.eventhubs. This is echoed in this [GitHub issue] (https://github.com/Azure/azure-webjobs-sdk/issues/1558)

You may also find that when you start your local Azure function emulator that you get an error like method not found microsoft.azure.eventhubs.eventhubclient to fix this you’ll need to reference a the following nuget package Microsoft.Azure.EventHubs.Processor

Make sure to add the hub connection strings to your local.settings.json file:

When you deploy for the first time, you may see an error like this: Microsoft.Azure.WebJobs.Host: Error indexing method (..) Microsoft.Azure.WebJobs.EventHubs: Value cannot be null. Parameter name: receiverConnectionString

If you do, simply go back to the publish screen and hit Edit Azure App Service Settings Edit the settings and set the connection string to that of your event hub (the one we copied earlier)

This should now deploy correctly.

Wrap Up

Azure functions are a fantastic tool for integrating with event hub.

If you do end up creating your own modules, you should be testing them and version controlling them.

When using modules within your terraform configurations, you shouldn’t really be downloading and packaging these manually. Fortunately Terraform has a fantastic feature which allows you to configure your terraform code to pull these modules directly from a git repository.

I’ll take you through how to set this up to work with Azure Devops and Github repositories.

This was a challenge, me and my team had to overcome when we were looking to deploy our Terraform code from our Azure Devops pipelines, hopefully I’ll save you from some of the pain we went through.

Referencing your custom terraform modules in Git

To be able to use common terraform modules directly from a git repo, the first thing you need to do is amend your terraform configurations to call out for those modules from a git repo instead of a local folder. This change is rather single, it’s just a case of changing the source field to reference a git url rather than a folder path, cool eh?

SSH or HTTPS?

If you are accessing an unsecured repo, then using HTTPS is most likely be the easiest solution. You can grab the url from github, but it’ll look something like https://github.com/codewithadam/terraform-common-modules.git

For repositories that are secured, whether in private Github repos, Azure Repos, or some other flavor, using an SSH key is often the easiest solution, than trying to work with credentials over HTTP. Even more so if you are going to be running your terraform code on a non-windows machine such as a linux build agent.

for SSH the url will looking something like: git@github.com:codewithadam/terraform-common-modules

Do note that with either method, both have the username/organisation specified in the urls.

Changes to make to your Terraform files

So you have your git url, now, as I mentioned above, you need to update your terraform files to look at git rather than your folder path.

module "az-function-app" {
  source       = "c:\\Dev\\terraform\\modules\\functionApp"
  app_name     = "BadgerDuck"
  regions      = ["uksouth", "ukwest"]
}

To switch to use of the url versions update the source from a folder to a url:

https

module "az-function-app" {
  source       = "https://github.com/codewithadam/terraform-common-modules.git"
  app_name     = "BadgerDuck"
  regions      = ["uksouth", "ukwest"]
}

ssh

module "az-function-app" {
  source       = "git@github.com:codewithadam/terraform-common-modules"
  app_name     = "BadgerDuck"
  regions      = ["uksouth", "ukwest"]
}

If you are lucky enough to be using an unathenticated repository then all your need to do is run terraform init and your modules should download and work as they did before, if however you are using an authenticated repo using ssh then further steps are required, this is how I ended up setting this up.

Setup SSH Keys

To allow your local machine or build agent to access the authenticated repo via ssh, you’ll need to setup an SSH key, I’ll take you through the steps to set this up in Azure DevOps and in Github.

Generate an SSH Key

The very first thing you’ll need to do is to generate a public and private key pair that you can use for authenication. OpenSSH is capable of doing this and is available on most systems. Open a command prompt and run the following command, replace the with a string that works for you, I used the name of the module collection.

ssh-keygen -C "<your filename>"

This command will ask you where you want the files to be saved, enter a full folder path and file name c:\ssh-keys\<string>, you’ll also be asked for a passphrase, this is simply a password to protect your keys, you can immediate hit enter twice and not enter one or you can take the extra step and setup a password. Once all done you’ll get two files

• - this will be your private key

• .pub - this will be your public key

Adding your key to Azure DevOps

Open up the Azure DevOps Port, and click on the settings icon at the top right of the screen and go to “SSH Public Keys”

Click on the “New Key” button, enter a name for your public key, make it make sense as to what it’s for, then put into the “public Key Data” section the contents of the <your filename>.pub file, this will start with ssh-rsa your account is now setup to use SSH keys.

Adding your key to GitHub

Within github, go to your repository, click on settings, then on the left click on Deploy Keys.

Click Add deploy key, in the title field, give it a meaningful name, enter the contents of your <your filename>.pub file which will start with ssh-rsa, you can then select Allow write access if you need your pipeline to be able to make changes to the repo, otherwise leave it unchecked for read access. Then click Add key.

Accessing Terraform Modules in Azure DevOps Pipelines

With our Terraform code files referencing git repos for their supporting modules and with our SSH keys setup, we can now look at getting Azure DevOps Pipeslines setup to be able to run these Terraform build and deployments.

As our repositories are all authenticated and used SSH we need to setup our pipelines with the correct information to connect over SSH.

Upload your private key

Firstly, we need to add our private key, the one we generated earlier into Azure DevOps, without it, we won’t be able to connect. Now being a secure key, we need to store this securely. Thankfully, Azure Pipelines has a method to handle this, within the Library we can upload a secure file, isn’t that handy!

In your Azure DevOps project, go to the pipelines section, then select Library, in the top menu you’ll see a section called Secure Files click this.

Click on the + Secure File button and upload the <your filename> from before, not the one ending in .pub.

Known Host

This is something, that I missed on the first go at this. An important bit of information that Azure Devops needs, is the known host entry. This information identifies the server we wish to connect to and tells Azure DevOps to trust it, this stops it prompting us to ask if it’s ok to connect, which is ideal, as during a build/release we have no way to answer that prompt.

To get the known hose you need to run the following command:

ssh-keyscan <hostname of your repo>

replace <hostname of your repo> with the actual hostname of the repo you are connecting to. For example, if you were using github like us then it’ll be github.com or it’ll be ssh.dev.azure.com if you are using an Azure DevOps repo. This command will return a block of text, you’ll need to copy this test, see the bits highlight below.

Create the DevOps Pipeline

We now have done all the pre-work and have the values we need to successfully create a pipeline. The very first thing we’ll need to do is setup some variables to hold these values. Because these values are all sensitive varibles, we’ll create them using the variable pane in the DevOps pipelines, we’ll need to create the following varibles.

• known_host - this will contain the text collected from the ssh-keyscan we collected above

• ssh_public_key - this will contain the contents of your <your filename>.pub

• ssh_passphrase - if you entered a passphrase to protect your generated key, you should enter this here.

• ssh_privateKeyName - this will be the name of <your filename> which you uploaded to secure files

With the variables configured, we can move onto setting up the pipelines, the first task we’ll need, is a take to install an ssh key, without this Terraform won’t be able to use our SSH keys. We’ll need to use the Install SSH Key Task. The Yaml will look something like this.

task: InstallSSHKey@0
  inputs:
    knownHostsEntry: $(known_host)
    sshPublicKey: $(ssh_public_key)
    sshPassphrase: $(ssh_passphrase)
    sshKeySecureFile: $(ssh_privateKeyName)

Deploy your Terraform config

With the SSH keys setup and our Terraform files all referencing the git repo using SSH, that’s it, it should just work now. Now when we run Terraform init as a part of the build pipeline it will use the installed keys to automatically checkout your modules directly from git.

Congratulations! Hopefully, you found this without spending hours look into why it’s not working!

Versions and Branching

The url’s mentioned above will checkout your modules from the main/master branch of your repository. Sometimes you’ll want to checkout a specific branch or tag. Such as:

• you are developing a new version of the module on a branch and you want to test it

• you’ve tagged a release of your module with a version number and want to lock yourself to that version

Both very sensible reasons, if you want to use a specific version or tag then all you need to do is to amend the url used in your Terraform configurations to use the ref attribute, here you can specify the branch or tag name.

getting a specific branch

module "az-function-app" {
  source       = "git@github.com:codewithadam/terraform-common-modules?ref=develop"
  app_name     = "BadgerDuck"
  regions      = ["uksouth", "ukwest"]
}

getting a specific tag

module "az-function-app" {
  source       = "git@github.com:codewithadam/terraform-common-modules?ref=v1.0.0"
  app_name     = "BadgerDuck"
  regions      = ["uksouth", "ukwest"]
}

Gotchas

Terraform expects you to have 1 git repo per module, if you don’t conform to this you’ll get an error Error: Failed to download module with a further explanation fatal: Could not read from remote repository.

If you look at how The Terraform registry is laid out this will make sense.

Wrap Up

Hopefully this article has been helpful,I was stumped for a while, hence this article, now I can’t take entire credit for this, as the missing piece of the puzzle was given to me by Sam Cogan, it was his fantastic article which led me to the known_hosts issue.

There is a new way to generate in the new Blob Storage SDK, and the big thing here is the ability to generate those SAS tokens without a storage account key.

User Delegation SAS

The typical way to generate a SAS token in code requires the storage account key. This assumes you have the storage account key, and there are scenarios where you just won’t have access to that. This is the situation I found myself in. You’ll find many answers online, but none of them lead you down the right path if you are as unlucky as I was. If you need to use “Managed Identity” to control access to your storage accounts in code, which is something I highly recommend wherever possible as this is a security best practice. In this scenario, you won’t have a storage account key, so you’ll need to find another way to generate the shared access signatures.

To do that, we need to use an approach called “user delegation” SAS . By using a user delegation SAS, we can sign the signature with the Azure Ad credentials instead of the storage account key.

I’ll show you below exactly what code you need to generate the user delegation SAS URI with the .Net storage SDK; I’ll also cover a few gotchas that caught me out and how to test this within visual studio locally.

Generating a User Delegation SAS

Connecting to Azure Storage using Entra Id (Azure Active Directory) Credentials is made incredibly easy thanks to the DefaultAzureCredential. This helper class tries a variety of different techniques to source the credentials required to access a storage account.

Firstly it checks for environment variables. If these aren’t present, it attempts to use a managed identity (this is what you want in production!). Should that fail, it has a range of fallback options that it will try, and these are great for local development. It can use the credentials you logged into visual studio, Visual Studio (VS) Code, Azure CLI with. So in a range of development environments, this will work. I’ll show you below how to set the managed identity you want to use in Visual Studio, which can be the one you’ve logged in with or something else entirely.

Here’s how you would use the DefaultAzureCredential to create a BlobServiceClient:

var storageAccountName  = "ducksandbadgersstore";
var storageAccountUriString = $"https://{storageAccountName}.blob.core.windows.net";
var credential = new DefaultAzureCredential();
var blobServiceClient = new BlobServiceClient(new Uri(storageAccountUriString), credential);

With that, you’ve successfully created a blob service client using managed identity. You can test this by uploading a file into the storage account.

var blobContainerClient = blobServiceClient.GetBlobContainerClient("duckcontainer");
var blobClient = blobContainerClient.GetBlobClient("duck.txt");
if(!await blobClient.ExistsAsync())
{
    using var ms = new MemoryStream(Encoding.UTF8.GetBytes("This is my secret blob"));
    await blobClient.UploadAsync(ms);
}

All being well, you should have a file in your blob storage container. Which proves that managed identity is working.

Now let’s generate a shared access signature. The first start is to create a user delegation key.

The duration of this SAS token can only be set to a maximum of 7 days Otherwise, you’ll get an error if you request a longer duration. You also get an error if you mess up the dates, I sent in the same start and end date of “Now” due to a config issue. When that happens, you’ll see an error with an HTTP status code of 400 (bad request) with the error being "The value for one of the XML nodes is not in the correct format," which isn’t the most helpful error. If you get this, check the values, make sure they make sense! Asking for a SAS token that immediately expires isn’t sensible!

To get the user delegation key is this simple:

var userDelegationKey = await blobServiceClient
    .GetUserDelegationKeyAsync(DateTimeOffset.UtcNow, 
                               DateTimeOffset.UtcNow.AddDays(7));

We can use the user delegation key with the BlobSasBuilder and BlobUriBuilder helpers to generate the SAS token URI. You can access the file or provide a token allowing someone write access to upload a file to your container. In the example below, I’m asking for a SAS token that’s valid for 7 days for a specific file. Do not that the SAS token doesn’t need to have the same lifetime as the user delegation key, but it cannot be longer If you attempt to create a SAS token URI with a lifespan that’s longer than the lifespan of the user delegation key, you will get a 403 error response.

var sasBuilder = new BlobSasBuilder()
{
    BlobContainerName = blobClient.BlobContainerName, // duckcontainer from above
    BlobName = blobClient.Name, // duck.text from above
    Resource = "b", // b for blob, c for container
    StartsOn = DateTimeOffset.UtcNow,
    ExpiresOn = DateTimeOffset.UtcNow.AddDays(7),
};

sasBuilder.SetPermissions(BlobSasPermissions.Read |
                        BlobSasPermissions.Write); // read and write permissions

var blobUriBuilder = new BlobUriBuilder(blobClient.Uri)
{
    Sas = sasBuilder.ToSasQueryParameters(userDelegationKey,
                                        blobServiceClient.AccountName)
};

var sasUri = blobUriBuilder.ToUri();

The sasUri can be used to download the file until the SAS token expires or the user delegation key expires. Whichever happens first will invalidate this SAS token.

To test the SAS token URI, here’s a simple bit of code that will download the file’s contents.

var httpClient = new HttpClient();
try
{
    var blobContentsString = await httpClient.GetStringAsync(sasUri).ConfigureAwait(false);
    Console.WriteLine(blobContentsString);
}
catch (HttpRequestException e)
{
    Console.WriteLine("Sas token failed - Unable to download: " + e.Message);
}

Testing Locally

If you attempt to test this locally or use a service in Azure, you may find that this doesn’t work. There’s a reason for that. You need to give the identity accessing the storage account some RBAC permissions.

• Storage Account Contributor

• Storage Blob Data Contributor

This may surprise you, as being the owner of the storage account isn’t sufficient.

You can test this in Azure CLI and even see if you can tighten the permissions by attempting the following.

$ACCOUNT_NAME = "ducksandbadgersstore"
$CONTAINER_NAME = "duckcontainer"

# use this to test if you have the correct permissions
az storage blob exists --account-name $ACCOUNT_NAME `
                        --container-name $CONTAINER_NAME `
                        --name duck.txt --auth-mode login

If you haven’t assigned the right RBAC permissions within the storage account, the above will fail. Head on into Azure, go to your storage account, then Access Control (IAM), then role assignments to set the permissions. Take a look at this article to see the various ways to grant the relevant RBAC permissions.

I personally do this within the CLI myself, and it’s this simple. Firstly look you our Azure AD object ID using our email address:

$EMAIL_ADDRESS = 'adam@redturtlesoftware.com'
$OBJECT_ID = az ad user list --query "[?mail=='$EMAIL_ADDRESS'].objectId" -o tsv

Now we need the id of the storage account to set the RBAC permissions on:

$STORAGE_ID = az storage account show -n $ACCOUNT_NAME --query id -o tsv

This will return a string that contains the subscriptionId, resource group, and the storage account name. For example:/subscriptions/770476dd-69ac-465d-96cc-gh12bc676chk/resourceGroups/badger-rg/providers/Microsoft.Storage/storageAccounts/ducksandbadgersstore

We can add the RBAC permissions Storage Blob Data Contributor role scoped to this storage account container with this information.

az role assignment create `
    --role "Storage Blob Data Contributor" `
    --assignee $OBJECT_ID `
    --scope "$STORAGE_ID/blobServices/default/containers/$CONTAINER_NAME"

If this still doesn’t work for you, there is a gotcha to get around when working within visual studio. The DefaultAzureCredential may not select the correct Azure AD tenant id. There are two ways to get around this. Firstly you can set it in code like this:

var azureCredentialOptions = new DefaultAzureCredentialOptions();
azureCredentialOptions.VisualStudioTenantId = "5546dcdg-6581-66f0-a200-da76560045433s";
var credential = new DefaultAzureCredential(azureCredentialOptions);

Setting Visual Studio’s Managed Identity

Secondly, you can go into Visual Studio, go to Tools -> Options. Then Azure Service Authentication. It’s here where you can select an account. Or even add another account. I mentioned above about using an account that isn’t specifically the one you are logged into Visual Studio with. This is the settings section you would use to set another managed identity to use.

Summary

Managed Identities can sound a bit scary to those who haven’t used them, but actually, they are incredibly simple to use and end up making code much simpler and more secure. In the past, I’ve had to manage load balancing of storage queues and passing in storage account keys by using Azure Key Vault. It’s just a complication you can get rid of.

On top of that, Managed Identities are a much more secure way for you to access your cloud resources, giving a fine grained control as to what can be done to those resources, an account key gives complete access, RBAC gives you the ability to use the principle of least privilege. Sure, when it comes to generating SAS tokens, there is an additional hoop to jump through, but it’s still less of a hassle than setting up KeyVault and passing the secret into the code.

Hopefully, the steps above have shown you how to set the correct RBAC roles to your local user or managed identity. The C# example code is enough to help you generate that user delegation key, which is the key to SAS token generation with managed identity.

You are limited to a lifetime of 7 days with this approach, but that’s a good thing. The longer something is open, the more likely it will be attacked. It’s best practice to only have your SAS tokens alive for the shortest amount of time necessary.