Accessing and updating your runner’s Key Vault

CloudRadial AutomationAI runner secrets, including the AI-provider configuration, extension credentials, and any per-company credentials, live in a private Azure Key Vault inside your runner's virtual network. This article is for the technician who needs to reach that vault for the first time after a deployment, or to add or change one of those secrets directly in Azure. It assumes you have access to the Azure subscription where the runner is deployed.

Deploying from the Azure Marketplace is now the preferred way to set up a new runner. A Marketplace deployment does not give you access to the runner's Key Vault — you grant yourself that access afterwards, in two steps: assign yourself the Key Vault Secrets Officer role, and open your own IP address on the vault's networking. Both are covered below. With those two done, you can add and manage secrets.

Important -> The runner Key Vault is private by design. If you open its firewall to edit a secret, re-lock it as soon as you are done. See Re-lock the vault below.

In this article:

• First access after a Marketplace deployment
• Before you start
• Find your runner Key Vault
• Grant yourself the Key Vault Secrets Officer role
• Allow your IP address through the vault firewall
• Add or change a secret
• Apply the change
• Re-lock the vault
• Runner secret reference
• Per-company secrets

First Access After a Marketplace Deployment

When a runner is deployed from the Azure Marketplace, the wizard creates the vault and the runner's own access to it, but it does not grant you anything. That is deliberate: the runner reads its secrets through its managed identity, and no human needs standing access for the runner to work. The first time you need to add or change a secret — to set an AI provider's key, or to add an extension credential — do these two things, in this order:

1. Assign yourself the Key Vault Secrets Officer role on the vault, under Access control (IAM). See Grant yourself the Key Vault Secrets Officer role below.
2. Allow your own IP address on the vault's Networking page. See Allow your IP address through the vault firewall below.

You need both. The role decides whether you may read and write secret values; the firewall decides whether you can reach the vault at all. Granting one without the other fails in a way that looks like the other is wrong — a missing role reads as a permissions error, a closed firewall as a connection failure.

Important -> Re-lock the vault when you are finished. See Re-lock the vault below.

Before You Start

You need two independent things to edit a secret:

• The Key Vault Secrets Officer role on the vault, which lets you read and write secret values.
• A network path to the vault. The vault has no public access, so you must either work from a host on the runner virtual network (or a peered/VPN network) or temporarily allow your own IP address through the vault firewall.

The steps below use either the Azure portal or Az PowerShell. For the PowerShell commands you also need PowerShell 7 and the Az module on your machine, plus a Connect-AzAccount sign-in. See Runner prerequisites and Azure requirements for how to install them.

The vault is RBAC-mode and private: public network access is disabled and the default network action is deny. The role alone is not enough, because without a network path the portal and PowerShell still cannot reach the vault. A network path alone is not enough either, because writing a secret value requires the role.

Find Your Runner Key Vault

The vault name is stored on every runner Function App as the RUNNER_KV_NAME app setting, so you do not have to memorize it. From a machine signed in with the Az PowerShell module:

$rg = 'crautomationai-rg'
$runnerId = '<your runner identity id>'   # from the Runners page

# every app belonging to THIS runner, matched on the tag the installer stamps
$apps = @(Get-AzFunctionApp -ResourceGroupName $rg |
Where-Object { $_.Tag['RunnerIdentityId'] -eq $runnerId })

if ($apps.Count -eq 0) {
throw "No Function App in '$rg' is tagged RunnerIdentityId '$runnerId'. Check the runner identity id on the Runners page and the resource group name."
}

$kv = (Get-AzFunctionAppSetting -ResourceGroupName $rg -Name $apps[0].Name)['RUNNER_KV_NAME']
$kv

The vault name has the form crrun-<stamp>-kv. Use it as the vault name in the steps below, and keep $apps — the stop and start commands later in this article reuse it. Filtering on the tag matters: a resource group should hold only one runner, but matching on the tag means the commands cannot touch anything that is not part of this runner.

Grant Yourself the Key Vault Secrets Officer Role

The vault uses Azure RBAC, so access is granted through role assignments rather than access policies. Assign yourself the Key Vault Secrets Officer role at the vault scope. You need Owner or User Access Administrator on the vault (or its resource group) to assign roles.

In the Azure portal, open the vault and go to Access control (IAM) > Add > Add role assignment, choose Key Vault Secrets Officer, and assign it to your account. Or with PowerShell:

$me = (Get-AzADUser -SignedIn).Id
New-AzRoleAssignment -ObjectId $me -RoleDefinitionName 'Key Vault Secrets Officer' `
-Scope (Get-AzKeyVault -VaultName $kv).ResourceId

Key Vault Secrets Officer grants read and write on secret values. The runner Function Apps use the read-only Key Vault Secrets User role through their managed identities, so leave that assignment in place.

Allow Your IP Address Through the Vault Firewall

Because the vault has no public access and your workstation is not on the runner virtual network, you cannot reach it to edit secrets until you open a path. The safe approach is to allow only your own public IP through the vault firewall while leaving the default action at Deny, so nothing else is exposed and the private endpoint is untouched. Two ways to do this:

• With the installer (recommended). Re-run the runner installer with -OpenKeyVaultToDeployer (and optionally -DeployerIpAddress <ipv4-or-cidr> to skip auto-detection). It enables public access, keeps the default action at Deny, and allow-lists only your IP. It prints the exact re-lock command when it finishes.
• In the portal. Open the vault, go to Networking > Firewalls and virtual networks, select the option to allow access from specific networks, add your client IP under Firewall, and save. Leave the default action at Deny.

Note: Allow a minute for the firewall change to take effect before you try to read or write a secret.

Add or Change a Secret

With the role and a network path in place, add or update the secret using its exact name from the reference below. In the portal, open the vault and go to Objects > Secrets, then use Generate/Import for a new secret, or open an existing secret and create a new version. With PowerShell:

Set-AzKeyVaultSecret -VaultName $kv -Name 'openai-api-key' `
-SecretValue (Read-Host 'New value' -AsSecureString)

Key Vault keeps prior versions, so updating a secret creates a new current version without deleting the old one.

Apply the Change

The runner Function Apps read these secrets as Key Vault references when their process starts, and hold the value for the life of that process. A new value is not picked up until the app starts again.

Important -> On a Flex Consumption runner a restart is not enough. Stop the app, leave it stopped for at least five minutes so the cached value clears, then start it again. Restarting in place — or stopping and starting straight away — can hand the app the same value it already had, and your change appears not to have taken. This is the single most common reason a corrected secret seems to be ignored.

# $apps is the tag-filtered collection from Find your runner Key Vault above
foreach ($a in $apps) {
Stop-AzFunctionApp -ResourceGroupName $rg -Name $a.Name -Force
}

# wait at least five minutes before starting them again
Start-Sleep -Seconds 300

foreach ($a in $apps) {
Start-AzFunctionApp -ResourceGroupName $rg -Name $a.Name
}

Each app reports in on its next poll after it starts. If a runner still behaves as though the old value were in place, it was almost certainly started again too soon; repeat the stop, wait, start sequence. See also Verifying and troubleshooting runner connectivity.

Re-Lock the Vault

If you opened the firewall, close it as soon as you are done so the vault returns to private-only. Set public network access back to Disabled (in the portal, the vault's Networking page). The private endpoint and the runner Function Apps keep working because they reach the vault over the virtual network, not the public path. If you used the installer to open the firewall, run the re-lock command it printed.

Runner Secret Reference

These are the secrets you may need to add or change. Use the names exactly as shown.

For switching the AI provider, see the article on choosing the runner AI provider. For the Microsoft 365 credentials, see the article on creating a Microsoft 365 app registration. For the Microsoft Exchange Online credentials, see the article on using the Microsoft Exchange Online extension.

Per-Company Secrets

An extension credential does not have to be a single shared value. If you have registered companies in your workspace, you can give a company its own copy of a credential and have workflows scoped to that company use it automatically.

A per-company secret is an ordinary secret in this same vault, named by appending the company's secret suffix to the base secret name:

<BaseSecretName>-<secretSuffix>

For example, a company whose secret suffix is 990001 would have its copy of Autotask-ApiKey stored as Autotask-ApiKey-990001. Add it exactly as you would any other secret, using the steps above. The base secret stays where it is and is still used by anything not scoped to a company.

Which of the two the runner reads is decided by the secret policy set on the base name in AutomationAI, not by anything in the vault. A policy of Prefer company falls back to the base secret when the company's copy is absent, while Require company fails the step instead. Per-company credentials require a runner on version 1.7.0 or later. For setting policies and secret suffixes, see the article on managing companies and per-company credentials.

If you are still having trouble, we're here to help! Submit a ticket for assistance, and don't forget to check our status page to ensure there are no outages in your area.