RBAC & Managed Identity

VaultGuard360 uses a user-assigned managed identity to authenticate with Azure services and read Key Vault metadata. Dashboard access is controlled through Microsoft Entra ID and can be restricted to specific users or groups.

Managed Identity Authentication

The Function App authenticates to Azure using a user-assigned managed identity via DefaultAzureCredential. No passwords, API keys, or connection strings are stored for Key Vault access — the identity is established by the Azure platform.

The managed identity is configured using the AZURE_CLIENT_ID app setting, which must match the clientId of the user-assigned identity attached to the Function App.

Required RBAC Role

Key Vault Reader is the only role required on your subscriptions. This role allows the managed identity to:

• List Key Vaults in the subscription
• List item names (secrets, certificates, keys) within each vault
• Read expiration date metadata for each item

This role does not permit:

• Reading secret values
• Reading certificate contents or private keys
• Reading key material
• Modifying any resource
• Creating or deleting any resource

Note: You do not need to assign the Azure Reader role separately. The Key Vault Reader role is sufficient for all VaultGuard360 scanning operations.

Assigning the Role

Assign the Key Vault Reader role to the managed identity at subscription scope. This grants access to all Key Vaults within the subscription without requiring per-vault assignments.

# Get the principal ID of the managed identity
PRINCIPAL_ID=$(az identity show \
  --name id-vaultguard360 \
  --resource-group <managed-resource-group> \
  --query principalId -o tsv)

# Assign Key Vault Reader at subscription scope
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Key Vault Reader" \
  --scope /subscriptions/<subscription-id>

Repeat for each subscription you want VaultGuard360 to monitor.

Note: Role assignment propagation can take 5–10 minutes after creation. A scan that runs immediately after role assignment may show missing vaults. Wait a few minutes and trigger a manual scan if vaults are missing.

Scope Recommendations

Subscription scope is recommended for most deployments. It minimizes the number of role assignments to manage and automatically covers new vaults added to the subscription.

Verifying Role Assignments

# List all role assignments for the managed identity
az role assignment list \
  --assignee $PRINCIPAL_ID \
  --scope /subscriptions/<subscription-id> \
  -o table

# Check permission status via the API
curl https://<function-app>.azurewebsites.net/api/permission-status

The /api/permission-status endpoint returns a breakdown by subscription with hasKeyVaultAccess boolean flags, making it easy to identify which subscriptions are missing role assignments.

Key Vault RBAC Authorization Requirement

VaultGuard360 requires Key Vaults to use RBAC authorization (not legacy access policies). Verify that each Key Vault has RBAC authorization enabled:

az keyvault show --name <vault-name> \
  --query properties.enableRbacAuthorization
# Must return: true

If a vault is using legacy access policies, the Key Vault Reader role assignment will not grant access. You have two options:

1. Enable RBAC authorization on the vault (recommended — this is the modern Azure approach)
2. Add the managed identity to the vault's access policy with List permissions for secrets, certificates, and keys

Dashboard Access Control

Default Behavior

By default, any user in your Microsoft Entra ID tenant can authenticate to the VaultGuard360 dashboard. Authentication is handled automatically by EasyAuth — no additional identity configuration is required.

Restricting Access to Specific Users or Groups

To limit dashboard access to your security team, use User Assignment on the Enterprise Application in Entra ID. This is the standard Azure approach and requires no changes to VaultGuard360.

1. Open the Azure Portal → Microsoft Entra ID → Enterprise Applications

2. Find VaultGuard360: Search by the Application (client) ID shown in the Function App's authentication settings, or search by name

3. Enable assignment requirement:

   • Go to Properties
   • Set "Assignment required?" to Yes
   • Click Save

4. Assign users or groups:

   • Go to Users and groups → Add user/group
   • Select the security groups or individual users who should have access
   • Click Assign

5. Verify: Have a non-assigned user try to access the dashboard — they should receive an AADSTS50105 error before reaching VaultGuard360

What Happens to Non-Assigned Users

When "Assignment required" is enabled:

• Assigned users: Normal login and dashboard access
• Non-assigned users: Entra ID blocks the request with an authorization error before the Function App ever sees the request

Using Security Groups (Recommended)

Create a dedicated security group for easier ongoing management:

1. Entra ID → Groups → New group
2. Name: e.g., VaultGuard360 Admins
3. Type: Security
4. Members: Add users who need dashboard access
5. Assign this group to the Enterprise Application

To grant or revoke access later, add or remove users from the group — no need to touch the Enterprise Application assignment.

Conditional Access Policies

For organizations with Entra ID P1 or P2, Conditional Access provides additional controls for VaultGuard360 specifically:

To create a Conditional Access policy targeting VaultGuard360:

1. Entra ID → Security → Conditional Access → New policy
2. Assignments → Target resources → select the VaultGuard360 application
3. Configure your desired conditions and access controls
4. Enable the policy

Federated Identity Support

If your organization uses a federated identity provider (ADFS, F5 APM, Okta, PingFederate), authentication works transparently:

1. EasyAuth redirects to Entra ID
2. Entra ID detects the federated domain and redirects to your identity provider
3. User authenticates with their corporate credentials (possibly SSO via Kerberos if on the corporate network)
4. Identity provider issues a token to Entra ID
5. Entra ID issues an OAuth token to VaultGuard360

VaultGuard360 only sees the final Entra ID token — the federation flow is completely transparent.

Enterprise Tier: Private Endpoint Authentication

For Enterprise customers with Private Endpoints enabled:

1. User on the corporate network navigates to the Function App URL
2. Private DNS zone resolves the hostname to the private IP within your VNet
3. EasyAuth redirects to login.microsoftonline.com (public Entra ID endpoint — this must remain reachable)
4. User authenticates via Entra ID
5. Entra ID redirects back to the Function App URL, which DNS resolves to the private IP again

Note: Users must be on a network that can resolve the private DNS zone (corporate VPN, ExpressRoute, or directly on the VNet). Users outside the private network cannot reach the Function App even with valid credentials.