Skip to main content
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: 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 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, and proposing changes as plans.

​
Permission admin

If you want the agent to be able to widen its own Azure access through an approved permission grant, 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.
A permission-admin binding is human-only. It is never handed to the agent and its credentials cannot be exported — see Permission admin.

​
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.
  • Soft boundary — what the agent may do with it. Reads run freely; changes go through plan approvals and Auto-authorization.

​
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.