Cerberius AgentsHelp
Sign in
More in Access to your live system

Microsoft Azure

Connect Azure subscriptions with an app registration (Microsoft 365's or its own), so the agent can look into virtual machines, app services, databases and settings, and propose fixes a person approves.

In the appPlatformSettingsAccounts and cloudMicrosoft Azure

Connect a client's Azure subscriptions so the agent can see what is really running: virtual machines, web apps, databases and networks, their health, and the activity log of who changed what.

What the agent may do is up to you: it is set in Azure, by the roles you give the app. Nothing is off limits, access included, but every change waits for a person to approve it. See Changes below.

Connect it#

  1. 1

    Here, go to Settings › Accounts and cloud. Click Connect an account (or Connect another), and choose Microsoft Azure.

  2. 2

    Under Sign-in, choose Use the Microsoft 365 app registration if Microsoft 365 is already connected: nothing new to type. Otherwise choose A separate app registration, and make one as for Microsoft 365 (its IDs and a client secret; it needs no Graph permissions). Click Save.

  3. 3

    In the Azure portal (portal.azure.com), open each subscription the agent should see. Go to Access control (IAM) › Add › Add role assignment. Choose Reader to let it look, or Contributor (or a role of your own) to let it propose changes. Under Members, choose User, group, or service principal, select the app by its name, and assign the role.

  4. 4

    Here, reload the page. The subscriptions the app can see show under Where to look, each with its role. Tick the ones to look in (none ticked: all of them, ticked for you when you save), click Save, then Check connection. A new role can take a few minutes to work.

The settings#

SettingWhat it is
Use the Microsoft 365 app registrationSigns in as the app connected for Microsoft 365, with its secret.
A separate app registrationIts own directory ID, client ID and client secret. Once saved, the secret is never shown again.
Where to lookThe subscriptions the agent searches, and the only ones changes may go to, with the app's role on each. None ticked: all the app can see, ticked for you when you save. If the list can't be read (your runner keeps the secret, say), type the subscription IDs: with none typed, the agent looks in every one it can see and no change is made.
Changes in Microsoft AzureThe same switch as under Settings › Approved changes.
Check connectionSigns in, lists the subscriptions with the app's roles, and counts the virtual machines, web apps and databases it can see.
DisconnectOn the card. Removes the settings and the separate secret. Microsoft 365's stays.

How the agent uses it#

  • At the start of each investigation, Cerberius Agents signs in as the app and gives the agent a pass that lasts about an hour. The agent never sees the client secret.
  • Its tools only read (GET), only in the platform's subscriptions. They can't call actions such as listKeys, so they never see a key or a connection string.
  • What it reads can appear in its findings as evidence. Secrets are removed first.
  • Fix runs (a change to code) never get Azure.

Changes#

To let the agent propose Azure changes, switch on Changes in Microsoft Azure on this page, or under Settings › Approved changes. See Allowing changes.

The agent then puts the exact requests in a change, such as restarting a web app or giving someone back a role. When it's approved (by two people, if you asked for that):

  1. Cerberius Agents reads what each request edits, removes or acts on. If one can't be read, nothing runs.
  2. It sends the requests in order, and stops at the first one Azure refuses. Long jobs, such as resizing a virtual machine, carry on in Azure afterwards.
  3. The agent checks the result and drafts the reply to the requester.

A few requests are never sent, whatever the roles allow: any that hands out a key, a password, a connection string or a token (it would land in the ticket), and any that sets a password the agent wrote.

With your own runner#

When the agent runs on your own runner, a separate client secret is kept by you (Scrambled for your runner, or In your store as azure-secret); with Microsoft 365's app registration, its secret is the one already kept. Your runner then signs in for each investigation, checks the connection and makes the approved changes. It makes none until its own rules allow them: add an azure section naming the resource providers changes may touch, for example providers: [Microsoft.Web]. It needs version 0.13.0 or later.