Multi-Subscription Setup

Before you start

Complete the collection setup first. Grant Reader and Monitoring Reader at a management group rather than per subscription: Azure RBAC inherits down the management-group tree, so that one assignment covers every subscription beneath it, including subscriptions created later.

For one subscription added by hand, use Single Subscription Setup instead.

The wizard

Settings → Integrations → Azure → Add New Azure Account → Multi Subscription. Four screens — App Registration → Discovery → Review → Enrolled — and nothing is created until you approve the plan on the third.

Screen 1 — App Registration

Three numbered sections, in the order the work happens. Verification comes first because everything below depends on working credentials, and the second section stays dimmed until they are verified.

1. Connect your App Registration.

Then select Verify credentials. In workload-identity mode there is no button: the identity belongs to the controller rather than the dashboard, so it is proved when discovery runs on the next screen.

2. Choose which subscriptions. Dimmed until the credentials verify. Leave everything empty to enrol every subscription the App Registration can see.

If the management-group list comes back empty, your tenant may not use management groups at all, which is normal. Name your subscriptions explicitly instead.

3. Configure collection. A region each newly enrolled subscription starts with, and the resource types to enable. These are applied when a subscription is first enrolled; changing an individual subscription's settings afterwards is safe, since enrollment never overwrites per-subscription choices on a later cycle.

Select Next. That one button saves the configuration and moves on — discovery runs server-side against the saved enrollment, so saving is what unlocks it, and the plan you approve is guaranteed to be the plan you configured. The enrollment is created in preview: nothing is enrolled yet.

Screen 2 — Discovery

Lists the subscriptions your App Registration can see, after your scope filters, and what KubeSense would do with each. Three counters summarise it — Total listed, Would enroll, Skipped.

Subscriptions in the Warned or PastDue states are enrolled, not skipped: those are billing states in which resources keep running and Azure keeps answering for them.

Read the list before continuing — it is the last checkpoint before collection starts. A subscription you expected is missing means it sits outside the management groups or the include list; nothing listed at all means the App Registration has no role assignment anywhere, so the assignments did not apply or applied to a different principal.

Screen 3 — Review, and enable

The Review screen restates what you configured — authentication mode, tenant, scope, include/exclude lists and status — so you approve a plan you can see rather than one you have to remember.

Two choices, and they are two different outcomes rather than one Next: Finish without enrolling keeps it in preview, with nothing created; Enable Enrollment starts collection.

On enable, KubeSense enrols the approved subscriptions straight away rather than waiting for the next cycle, and reports how many it created. After that the reconcile loop keeps the set current:

Screen 4 — Enrolled

Lists the subscriptions this enrollment created integrations for, each Collecting or Paused — paused meaning it left the configured scope, became disabled, or was excluded, reversibly and with automatic resumption if it returns. Only subscriptions this enrollment created are listed.

This is also where the client secret's status lives, and where Rotate secret applies a new one to every enrolled subscription in a single step.

Operating it

Verify. Verify credentials and then discovery prove the credential. Resources appear within a minute or two as a count per resource type on each integration, and metrics take up to 10 minutes for the first cycle.

Rotating the client secret. Do this before the old secret expires — when it lapses, every subscription in the enrollment stops collecting at once. Mint a new secret by re-running the setup script, which appends one without disturbing the existing role assignments, or with terraform apply -replace=azuread_application_password.kubesense. Then use Rotate secret on the enrolled-subscriptions view: it pushes the new secret to every enrolled subscription in one step. Record the new expiry date at the same time.

Adding scope. Re-run the script with the new management group or subscription — or add it to management_group_ids and re-apply — then select it in the wizard. A new subscription inside a management group you already cover needs none of this: the assignment already reaches it, and enrollment picks it up on its next cycle.

Pausing enrollment. Switch the enrollment off. Subscriptions already enrolled keep collecting, so switching off can never silently stop collection.

Troubleshooting