Azure Resources and Permissions

This page documents every Azure resource that Container Assist creates on your behalf, every role assignment it makes, and the Azure permissions you need to use the feature.

Prerequisites: Azure Account Permissions

Container Assist operates across multiple resource groups and requires both resource management and role assignment permissions. This section explains which built-in roles work, which don’t, and why.

Which built-in roles work?

Why Contributor alone is not enough: The Contributor role explicitly excludes Microsoft.Authorization/roleAssignments/write. Container Assist assigns up to 9 RBAC roles across multiple resources (see Role Assignments below). Without role assignment permissions, the OIDC setup completes partially – the managed identity and federated credential are created, but the pipeline will fail at runtime because the identity lacks access to the cluster and ACR. The extension warns you which roles could not be assigned so you can request them from an admin.

Why subscription-level access is needed

Container Assist touches up to 4 separate resource groups during a single run:

The extension also lists all AKS clusters and ACRs across the subscription during the selection wizard, which requires subscription-level read access (Microsoft.Resources/subscriptions/resources/read).

If your account is scoped to a single resource group, the cluster/ACR listing fails before you can even start.

Detailed permission breakdown

For least-privilege or custom role setups, here are the specific permissions required:

These permissions must be granted at subscription scope (or across all relevant resource groups) for the full workflow to succeed.

Azure Resources Created

Container Assist may create the following Azure resources during the OIDC setup flow. These resources appear in your Azure subscription and may incur governance or cost implications.

Resource Group

User-Assigned Managed Identity

Note: If you select “Use existing managed identity”, no new identity is created. The selected identity is reused.

Federated Identity Credential

The subject uses your repository’s owner/repo from the git remote and the detected default branch (usually main).

Role Assignments

Container Assist assigns Azure RBAC roles at two distinct stages: ACR selection (during the main wizard) and OIDC setup (when configuring the GitHub workflow pipeline). The principals and scopes differ between these stages.

Stage 1: ACR Selection (Main Wizard)

When you select an Azure Container Registry that is not already attached to your AKS cluster, the extension offers to assign the AcrPull role:

Why: This allows your AKS cluster to pull container images from the selected ACR at runtime. Without this, pod image pulls will fail with authentication errors.

Principal: The AKS cluster’s kubelet identity (from identityProfile.kubeletidentity). For service-principal-based clusters, the service principal is used instead.

Stage 2: OIDC Setup (GitHub Workflow Pipeline)

When you run the OIDC setup to configure GitHub Actions authentication, role assignments are created for the OIDC managed identity (the identity that your GitHub Actions workflow uses to authenticate with Azure). The roles assigned depend on whether you are deploying to a user namespace or a managed namespace.

User Namespace Path

For standard (non-managed) Kubernetes namespaces:

Note on role #4: The AKS RBAC Writer role is only assigned when the cluster has Azure RBAC enabled (aadProfile.enableAzureRBAC). If the cluster uses Kubernetes-native RBAC instead, this role is skipped and you will need to create a Kubernetes ClusterRoleBinding or RoleBinding manually.

Managed Namespace Path

For AKS managed namespaces, roles are scoped to the specific namespace rather than the entire cluster: