> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nuphos.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Microsoft Azure

> Connect an Azure subscription with workload identity federation — no client secret to store or rotate.

Nuphos reaches Azure through **OIDC workload identity federation**. You register
an app in Entra ID, add a federated credential that trusts the Nuphos issuer, and
give that app an RBAC role on the subscription. Nuphos mints a short-lived token
per team and exchanges it at Entra for an ARM access token.

**No client secret is created, pasted, or stored** — the token *is* the
credential. Nuphos stores only three GUIDs: tenant, client, and subscription.

## Connect

The wizard in **Connectors → Connect → Azure** walks these steps; the values it
shows are scoped to your team, so copy them from the app rather than from here.

### 1. Register the app & federated credential

In the Azure portal, open **Entra ID → App registrations → New registration**.
Name it `Nuphos`, single tenant, no redirect URI.

Then open the app → **Manage → Certificates & secrets → Federated credentials →
Add credential**, scenario **Other issuer**:

| Field    | Value                                               |
| -------- | --------------------------------------------------- |
| Issuer   | `https://nuphos.ai`                                 |
| Type     | **Explicit subject identifier** (the default)       |
| Value    | `nuphos:team:<your-team-id>` — shown in the wizard  |
| Name     | `nuphos` (Entra will not let you change this later) |
| Audience | `api://AzureADTokenExchange`                        |

Note the app's **Application (client) ID** from its Overview page, and your
**Directory (tenant) ID** from **Microsoft Entra ID → Overview**. The last step
asks for both.

### 2. Assign a role on the subscription

Open the subscription → **Access control (IAM) → Add role assignment**. Pick
**Reader** to browse, or something broader for the work you want done — for
example *Azure Kubernetes Service Cluster User Role* for AKS.

On the **Members** tab, choose *User, group, or service principal* and **+ Select
members**. The panel is empty until you type: search for `Nuphos` to bring up the
app you registered.

### 3. Bind the subscription

Back in Nuphos, enter the tenant, client, and subscription IDs. Nuphos exchanges
a token and reads the subscription before saving, so a mismatched federated
credential or a missing role assignment is rejected right there rather than
failing later.

## In the Nuphos app

* **Apps** — the apps bound under this subscription, and for each one its RBAC
  role assignments: the "what can this actually do" readout.
* **Clusters** — AKS clusters discovered in the subscription land in the shared
  [cluster browser](/infrastructure/clusters) alongside EKS, GKE, and the rest.

## What the agent can do for you

The agent operates the subscription through Azure Resource Manager within
whatever role you assigned — inspecting resources, correlating them with your
other [connected accounts](/connectors/overview), and proposing changes as
[plans](/agent/plans).

## Permission admin

If you want the agent to be able to *widen its own* Azure access through an
approved [permission grant](/security/permission-admin), register a **second**
app named `Nuphos Permission Admin` and mark it as the permission-admin binding.
It needs two things the operational app does not:

* The **Microsoft Graph → Application permissions → `Application.Read.All`**
  permission, with **admin consent granted**. Nuphos resolves the target app's
  service principal through Graph before writing a role assignment; without it
  every grant fails with *"Insufficient privileges to complete the operation."*
* A role that can write role assignments — *Role Based Access Control
  Administrator*, or the wider *Owner*.

It must be a separate app: reusing the operational one would hand the agent's own
credential the power to widen itself, and Nuphos rejects the same app bound twice
on one subscription.

<Warning>
  A permission-admin binding is human-only. It is never handed to the agent and
  its credentials cannot be exported — see
  [Permission admin](/security/permission-admin).
</Warning>

## Permissions & authorization

* **The RBAC role you assigned** is the outer limit. Assign Reader if you only
  want the agent to look.
* **Hard boundary — who can use it.** Only team **Administrators** can bind or
  remove the subscription, and they can restrict it to specific members with a
  [member allow-list](/security/access-control).
* **Soft boundary — what the agent may do with it.** Reads run freely; changes go
  through [plan approvals](/security/approvals) and
  [Auto-authorization](/security/auto-mode).

## Good to know

* Entra fetches the issuer's JWKS itself, so there is no public key to paste and
  nothing to rotate on your side.
* The federated credential is pinned to **your team's** subject. Another Nuphos
  team's token cannot satisfy it — see the
  [IAM trust model](/security/iam-trust).