{
	"id": "1e05a1b3-945c-4855-a35c-8417f229af1b",
	"created_at": "2026-04-06T00:07:08.668423Z",
	"updated_at": "2026-04-10T13:12:06.222706Z",
	"deleted_at": null,
	"sha1_hash": "8f4bae4a8c32c61316050fb607340786402ced27",
	"title": "Concepts - Access and identity in Azure Kubernetes Services (AKS) - Azure Kubernetes Service",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 211497,
	"plain_text": "Concepts - Access and identity in Azure Kubernetes Services (AKS) -\r\nAzure Kubernetes Service\r\nBy palma21\r\nArchived: 2026-04-05 13:57:57 UTC\r\nYou can authenticate, authorize, secure, and control access to Kubernetes clusters in a variety of ways:\r\nUsing Kubernetes role-based access control (Kubernetes RBAC), you can grant users, groups, and service accounts\r\naccess to only the resources they need.\r\nWith Azure Kubernetes Service (AKS), you can further enhance the security and permissions structure using\r\nMicrosoft Entra ID and Azure RBAC.\r\nKubernetes RBAC and AKS help you secure your cluster access and provide only the minimum required permissions to\r\ndevelopers and operators.\r\nThis article introduces the core concepts that help you authenticate and assign permissions in AKS.\r\nKubernetes RBAC\r\nKubernetes RBAC provides granular filtering of user actions. With this control mechanism:\r\nYou assign users or user groups permission to create and modify resources or view logs from running application\r\nworkloads.\r\nYou can scope permissions to a single namespace or across the entire AKS cluster.\r\nYou create roles to define permissions, and then assign those roles to users with role bindings.\r\nFor more information, see Using Kubernetes RBAC authorization.\r\nRoles and ClusterRoles\r\nRoles\r\nBefore assigning permissions to users with Kubernetes RBAC, you'll define user permissions as a Role. Grant permissions\r\nwithin a namespace using roles.\r\nNote\r\nKubernetes roles grant permissions; they don't deny permissions.\r\nTo grant permissions across the entire cluster or to cluster resources outside a given namespace, you can instead use\r\nClusterRoles.\r\nClusterRoles\r\nA ClusterRole grants and applies permissions to resources across the entire cluster, not a specific namespace.\r\nRoleBindings and ClusterRoleBindings\r\nOnce you've defined roles to grant permissions to resources, you assign those Kubernetes RBAC permissions with a\r\nRoleBinding. If your AKS cluster integrates with Microsoft Entra ID, RoleBindings grant permissions to Microsoft Entra\r\nusers to perform actions within the cluster. See how in Control access to cluster resources using Kubernetes role-based\r\naccess control and Microsoft Entra identities.\r\nRoleBindings\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 1 of 12\n\nAssign roles to users for a given namespace using RoleBindings. With RoleBindings, you can logically segregate a single\r\nAKS cluster, only enabling users to access the application resources in their assigned namespace.\r\nTo bind roles across the entire cluster, or to cluster resources outside a given namespace, you instead use\r\nClusterRoleBindings.\r\nClusterRoleBinding\r\nWith a ClusterRoleBinding, you bind roles to users and apply to resources across the entire cluster, not a specific\r\nnamespace. This approach lets you grant administrators or support engineers access to all resources in the AKS cluster.\r\nNote\r\nMicrosoft/AKS performs any cluster actions with user consent under a built-in Kubernetes role aks-service and built-in\r\nrole binding aks-service-rolebinding .\r\nThis role enables AKS to troubleshoot and diagnose cluster issues, but can't modify permissions nor create roles or role\r\nbindings, or other high privilege actions. Role access is only enabled under active support tickets with just-in-time (JIT)\r\naccess. Read more about AKS support policies.\r\nKubernetes service accounts\r\nService accounts are one of the primary user types in Kubernetes. The Kubernetes API holds and manages service accounts.\r\nService account credentials are stored as Kubernetes secrets, allowing them to be used by authorized pods to communicate\r\nwith the API Server. Most API requests provide an authentication token for a service account or a normal user account.\r\nNormal user accounts allow more traditional access for human administrators or developers, not just services and processes.\r\nWhile Kubernetes doesn't provide an identity management solution to store regular user accounts and passwords, you can\r\nintegrate external identity solutions into Kubernetes. For AKS clusters, this integrated identity solution is Microsoft Entra\r\nID.\r\nFor more information on the identity options in Kubernetes, see Kubernetes authentication.\r\nAzure role-based access control\r\nAzure role-based access control (RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources.\r\nRBAC system Description\r\nKubernetes RBAC Designed to work on Kubernetes resources within your AKS cluster.\r\nAzure RBAC Designed to work on resources within your Azure subscription.\r\nWith Azure RBAC, you create a role definition that outlines the permissions to be applied. You then assign a user or group\r\nthis role definition via a role assignment for a particular scope. The scope can be an individual resource, a resource group, or\r\nacross the subscription.\r\nFor more information, see What is Azure role-based access control (Azure RBAC)?\r\nThere are two levels of access needed to fully operate an AKS cluster:\r\nAccess the AKS resource in your Azure subscription.\r\nControl scaling or upgrading your cluster using the AKS APIs.\r\nPull your kubeconfig .\r\nAccess to the Kubernetes API. This access is controlled by either:\r\nKubernetes RBAC (traditionally).\r\nIntegrating Azure RBAC with AKS for Kubernetes authorization.\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 2 of 12\n\nWith Azure RBAC, you can provide your users (or identities) with granular access to AKS resources across one or more\r\nsubscriptions. For example, you could use the Azure Kubernetes Service Contributor role to scale and upgrade your cluster.\r\nMeanwhile, another user with the Azure Kubernetes Service Cluster Admin role only has permission to pull the Admin\r\nkubeconfig .\r\nUse Azure RBAC to define access to the Kubernetes configuration file in AKS.\r\nAzure RBAC for Kubernetes Authorization\r\nWith the Azure RBAC integration, AKS will use a Kubernetes Authorization webhook server so you can manage Microsoft\r\nEntra integrated Kubernetes cluster resource permissions and assignments using Azure role definition and role assignments.\r\nAs shown in the above diagram, when using the Azure RBAC integration, all requests to the Kubernetes API will follow the\r\nsame authentication flow as explained on the Microsoft Entra integration section.\r\nIf the identity making the request exists in Microsoft Entra ID, Azure will team with Kubernetes RBAC to authorize the\r\nrequest. If the identity exists outside of Microsoft Entra ID (i.e., a Kubernetes service account), authorization will defer to\r\nthe normal Kubernetes RBAC.\r\nIn this scenario, you use Azure RBAC mechanisms and APIs to assign users built-in roles or create custom roles, just as you\r\nwould with Kubernetes roles.\r\nWith this feature, you not only give users permissions to the AKS resource across subscriptions, but you also configure the\r\nrole and permissions for inside each of those clusters controlling Kubernetes API access. For example, you can grant the\r\nAzure Kubernetes Service RBAC Reader role on the subscription scope. The role recipient will be able to list and get all\r\nKubernetes objects from all clusters without modifying them.\r\nBuilt-in roles\r\nAKS provides the following four built-in roles. They are similar to the Kubernetes built-in roles with a few differences, like\r\nsupporting CRDs. See the full list of actions allowed by each Azure built-in role.\r\nRole Description\r\nAzure Kubernetes\r\nService RBAC Reader\r\nAllows read-only access to see most objects in a namespace.\r\nDoesn't allow viewing roles or role bindings.\r\nDoesn't allow viewing Secrets . Reading the Secrets contents enables access to\r\nServiceAccount credentials in the namespace, which would allow API access as any\r\nServiceAccount in the namespace (a form of privilege escalation).\r\nAzure Kubernetes\r\nService RBAC Writer\r\nAllows read/write access to most objects in a namespace.\r\nDoesn't allow viewing or modifying roles, or role bindings.\r\nAllows accessing Secrets and running pods as any ServiceAccount in the namespace, so it\r\ncan be used to gain the API access levels of any ServiceAccount in the namespace.\r\nAzure Kubernetes\r\nService RBAC Admin\r\nAllows admin access, intended to be granted within a namespace.\r\nAllows read/write access to most resources in a namespace (or cluster scope), including the\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 3 of 12\n\nRole Description\r\nability to create roles and role bindings within the namespace.\r\nDoesn't allow write access to resource quota or to the namespace itself.\r\nAzure Kubernetes\r\nService RBAC Cluster\r\nAdmin\r\nAllows super-user access to perform any action on any resource.\r\nGives full control over every resource in the cluster and in all namespaces.\r\nMicrosoft Entra integration\r\nEnhance your AKS cluster security with Microsoft Entra integration. Built on decades of enterprise identity management,\r\nMicrosoft Entra ID is a multi-tenant, cloud-based directory and identity management service that combines core directory\r\nservices, application access management, and identity protection. With Microsoft Entra ID, you can integrate on-premises\r\nidentities into AKS clusters to provide a single source for account management and security.\r\nWith Microsoft Entra integrated AKS clusters, you can grant users or groups access to Kubernetes resources within a\r\nnamespace or across the cluster.\r\n1. To obtain a kubectl configuration context, a user runs the az aks get-credentials command.\r\n2. When a user interacts with the AKS cluster with kubectl , they're prompted to sign in with their Microsoft Entra\r\ncredentials.\r\nThis approach provides a single source for user account management and password credentials. The user can only access the\r\nresources as defined by the cluster administrator.\r\nMicrosoft Entra authentication is provided to AKS clusters with OpenID Connect. OpenID Connect is an identity layer built\r\non top of the OAuth 2.0 protocol. For more information on OpenID Connect, see the OpenID Connect documentation. From\r\ninside of the Kubernetes cluster, Webhook Token Authentication is used to verify authentication tokens. Webhook token\r\nauthentication is configured and managed as part of the AKS cluster.\r\nWebhook and API server\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 4 of 12\n\nAs shown in the graphic above, the API server calls the AKS webhook server and performs the following steps:\r\n1. kubectl uses the Microsoft Entra client application to sign in users with OAuth 2.0 device authorization grant flow.\r\n2. Microsoft Entra ID provides an access_token, id_token, and a refresh_token.\r\n3. The user makes a request to kubectl with an access_token from kubeconfig .\r\n4. kubectl sends the access_token to API Server.\r\n5. The API Server is configured with the Auth WebHook Server to perform validation.\r\n6. The authentication webhook server confirms the JSON Web Token signature is valid by checking the Microsoft Entra\r\npublic signing key.\r\n7. If the user is a member of more than 200 groups, the server application uses user-provided credentials to query group\r\nmemberships of the logged-in user from the MS Graph API. For users with group memberships of 200 or fewer the\r\ngroups claim already exists in the client token. No query will be performed.\r\n8. A response is sent to the API Server with user information such as the user principal name (UPN) claim of the access\r\ntoken, and the group membership of the user based on the object ID.\r\n9. The API performs an authorization decision based on the Kubernetes Role/RoleBinding.\r\n10. Once authorized, the API server returns a response to kubectl .\r\n11. kubectl provides feedback to the user.\r\nLearn how to integrate AKS with Microsoft Entra ID with our AKS-managed Microsoft Entra integration how-to guide.\r\nAKS service permissions\r\nWhen creating a cluster, AKS generates or modifies resources it needs (like VMs and NICs) to create and run the cluster on\r\nbehalf of the user. This identity is distinct from the cluster's identity permission, which is created during cluster creation.\r\nIdentity creating and operating the cluster permissions\r\nThe following permissions are needed by the identity creating and operating the cluster.\r\nPermission Reason\r\nMicrosoft.Compute/diskEncryptionSets/read Required to read disk encryption set ID.\r\nMicrosoft.Compute/proximityPlacementGroups/write\r\nRequired for updating proximity placement\r\ngroups.\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 5 of 12\n\nPermission Reason\r\nMicrosoft.Network/applicationGateways/read\r\nMicrosoft.Network/applicationGateways/write\r\nMicrosoft.Network/virtualNetworks/subnets/join/action\r\nRequired to configure application gateways\r\nand join the subnet.\r\nMicrosoft.Network/virtualNetworks/subnets/join/action\r\nRequired to configure the Network Security\r\nGroup for the subnet when using a custom\r\nVNET.\r\nMicrosoft.Network/publicIPAddresses/join/action\r\nMicrosoft.Network/publicIPPrefixes/join/action\r\nRequired to configure the outbound public\r\nIPs on the Standard Load Balancer.\r\nMicrosoft.OperationalInsights/workspaces/sharedkeys/read\r\nMicrosoft.OperationalInsights/workspaces/read\r\nMicrosoft.OperationsManagement/solutions/write\r\nMicrosoft.OperationsManagement/solutions/read\r\nMicrosoft.ManagedIdentity/userAssignedIdentities/assign/action\r\nRequired to create and update Log Analytics\r\nworkspaces and Azure monitoring for\r\ncontainers.\r\nMicrosoft.Network/virtualNetworks/joinLoadBalancer/action\r\nRequired to configure the IP-based Load\r\nBalancer Backend Pools.\r\nAKS cluster identity permissions\r\nThe following permissions are used by the AKS cluster identity, which is created and associated with the AKS cluster. Each\r\npermission is used for the reasons below:\r\nPermission Rea\r\nMicrosoft.ContainerService/managedClusters/*\r\nReq\r\ncrea\r\nand\r\nthe\r\nMicrosoft.Network/loadBalancers/delete\r\nMicrosoft.Network/loadBalancers/read\r\nMicrosoft.Network/loadBalancers/write\r\nReq\r\ncon\r\nload\r\nfor\r\nLoa\r\nserv\r\nMicrosoft.Network/publicIPAddresses/delete\r\nMicrosoft.Network/publicIPAddresses/read\r\nMicrosoft.Network/publicIPAddresses/write\r\nReq\r\nfind\r\ncon\r\npub\r\na\r\nLoa\r\nserv\r\nMicrosoft.Network/publicIPAddresses/join/action\r\nReq\r\ncon\r\npub\r\na\r\nLoa\r\nserv\r\nMicrosoft.Network/networkSecurityGroups/read\r\nMicrosoft.Network/networkSecurityGroups/write\r\nReq\r\ncrea\r\ndele\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 6 of 12\n\nPermission Rea\r\nsecu\r\nfor\r\nLoa\r\nserv\r\nMicrosoft.Compute/disks/delete\r\nMicrosoft.Compute/disks/read\r\nMicrosoft.Compute/disks/write\r\nMicrosoft.Compute/locations/DiskOperations/read\r\nReq\r\ncon\r\nAzu\r\nMicrosoft.Storage/storageAccounts/delete\r\nMicrosoft.Storage/storageAccounts/listKeys/action\r\nMicrosoft.Storage/storageAccounts/read\r\nMicrosoft.Storage/storageAccounts/write\r\nMicrosoft.Storage/operations/read\r\nReq\r\ncon\r\nstor\r\nacco\r\nAzu\r\nAzu\r\nMicrosoft.Network/routeTables/read\r\nMicrosoft.Network/routeTables/routes/delete\r\nMicrosoft.Network/routeTables/routes/read\r\nMicrosoft.Network/routeTables/routes/write\r\nMicrosoft.Network/routeTables/write\r\nReq\r\ncon\r\nrout\r\nand\r\nnod\r\nMicrosoft.Compute/virtualMachines/read\r\nReq\r\nfind\r\ninfo\r\nfor v\r\nmac\r\nVM\r\nas z\r\nfaul\r\nsize\r\ndisk\r\nMicrosoft.Compute/virtualMachines/write\r\nReq\r\natta\r\nAzu\r\nto a\r\nmac\r\nVM\r\nMicrosoft.Compute/virtualMachineScaleSets/read\r\nMicrosoft.Compute/virtualMachineScaleSets/virtualMachines/read\r\nMicrosoft.Compute/virtualMachineScaleSets/virtualmachines/instanceView/read\r\nReq\r\nfind\r\ninfo\r\nfor v\r\nmac\r\nvirtu\r\nmac\r\nscal\r\nsuch\r\nzon\r\ndom\r\nand\r\ndisk\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 7 of 12\n\nPermission Rea\r\nMicrosoft.Network/networkInterfaces/write\r\nReq\r\nadd\r\nmac\r\nVM\r\nload\r\nback\r\nadd\r\nMicrosoft.Compute/virtualMachineScaleSets/write\r\nReq\r\nadd\r\nmac\r\nscal\r\nload\r\nback\r\nadd\r\nand\r\nnod\r\nvirtu\r\nmac\r\nscal\r\nMicrosoft.Compute/virtualMachineScaleSets/delete\r\nReq\r\ndele\r\nvirtu\r\nmac\r\nscal\r\nload\r\nback\r\nadd\r\nand\r\ndow\r\nin a\r\nmac\r\nscal\r\nMicrosoft.Compute/virtualMachineScaleSets/virtualmachines/write\r\nReq\r\natta\r\nAzu\r\nand\r\nvirtu\r\nmac\r\na vi\r\nmac\r\nscal\r\nthe\r\nbala\r\nMicrosoft.Network/networkInterfaces/read Req\r\nsear\r\ninte\r\nand\r\nbala\r\nback\r\nadd\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 8 of 12\n\nPermission Rea\r\nfor v\r\nmac\r\nVM\r\nMicrosoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/read\r\nReq\r\nsear\r\ninte\r\nand\r\nbala\r\nback\r\nadd\r\nfor\r\nmac\r\nvirtu\r\nmac\r\nscal\r\nMicrosoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ipconfigurations/publicipaddresses/read\r\nReq\r\nfind\r\nIPs\r\nvirtu\r\nmac\r\nvirtu\r\nmac\r\nscal\r\nMicrosoft.Network/virtualNetworks/read\r\nMicrosoft.Network/virtualNetworks/subnets/read\r\nReq\r\nveri\r\nsubn\r\nfor t\r\ninte\r\nbala\r\nano\r\nreso\r\ngrou\r\nMicrosoft.Compute/snapshots/delete\r\nMicrosoft.Compute/snapshots/read\r\nMicrosoft.Compute/snapshots/write\r\nReq\r\ncon\r\nsnap\r\nAzu\r\nMicrosoft.Compute/locations/vmSizes/read\r\nMicrosoft.Compute/locations/operations/read\r\nReq\r\nfind\r\nmac\r\nfor\r\nAzu\r\nvolu\r\nlimi\r\nAdditional cluster identity permissions\r\nWhen creating a cluster with specific attributes, you will need the following additional permissions for the cluster identity.\r\nSince these permissions are not automatically assigned, you must add them to the cluster identity after it's created.\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 9 of 12\n\nPermission Reason\r\nMicrosoft.Network/networkSecurityGroups/write\r\nMicrosoft.Network/networkSecurityGroups/read\r\nRequired if using a network security group in another\r\nresource group. Required to configure security rules\r\nfor a LoadBalancer service.\r\nMicrosoft.Network/virtualNetworks/subnets/read\r\nMicrosoft.Network/virtualNetworks/subnets/join/action\r\nRequired if using a subnet in another resource group\r\nsuch as a custom VNET.\r\nMicrosoft.Network/routeTables/routes/read\r\nMicrosoft.Network/routeTables/routes/write\r\nRequired if using a subnet associated with a route table\r\nin another resource group such as a custom VNET with\r\na custom route table. Required to verify if a subnet\r\nalready exists for the subnet in the other resource\r\ngroup.\r\nMicrosoft.Network/virtualNetworks/subnets/read\r\nRequired if using an internal load balancer in another\r\nresource group. Required to verify if a subnet already\r\nexists for the internal load balancer in the resource\r\ngroup.\r\nMicrosoft.Network/privatednszones/*\r\nRequired if using a private DNS zone in another\r\nresource group such as a custom privateDNSZone.\r\nAKS Node Access\r\nBy default Node Access is not required for AKS. The following access is needed for the node if a specific component is\r\nleveraged.\r\nAccess Reason\r\nkubelet Required to grant MSI access to ACR.\r\nhttp app routing Required for write permission to \"random name\".aksapp.io.\r\ncontainer insights Required to grant permission to the Log Analytics workspace.\r\nSummary\r\nView the table for a quick summary of how users can authenticate to Kubernetes when Microsoft Entra integration is\r\nenabled. In all cases, the user's sequence of commands is:\r\n1. Run az login to authenticate to Azure.\r\n2. Run az aks get-credentials to download credentials for the cluster into .kube/config .\r\n3. Run kubectl commands.\r\nThe first command may trigger browser-based authentication to authenticate to the cluster, as described in the\r\nfollowing table.\r\nIn the Azure portal, you can find:\r\nThe Role Grant (Azure RBAC role grant) referred to in the second column is shown on the Access Control tab.\r\nThe Cluster Admin Microsoft Entra group is shown on the Configuration tab.\r\nAlso found with parameter name --aad-admin-group-object-ids in the Azure CLI.\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 10 of 12\n\nDescription Role grant required\r\nCluster admin Microsoft\r\nEntra group(s)\r\nWhen to use\r\nLegacy admin login\r\nusing client certificate\r\nAzure Kubernetes\r\nService Cluster Admin\r\nRole. This role allows az\r\naks get-credentials to\r\nbe used with the --\r\nadmin flag, which\r\ndownloads a legacy (non-Microsoft Entra) cluster\r\nadmin certificate into the\r\nuser's .kube/config .\r\nThis is the only purpose\r\nof \"Azure Kubernetes\r\nService Cluster Admin\r\nRole\".\r\nn/a\r\nIf you're permanently\r\nblocked by not having\r\naccess to a valid\r\nMicrosoft Entra group\r\nwith access to your\r\ncluster.\r\nMicrosoft Entra ID\r\nwith manual\r\n(Cluster)RoleBindings\r\nAzure Kubernetes\r\nService Cluster User\r\nRole. The \"User\" role\r\nallows az aks get-credentials to be used\r\nwithout the --admin\r\nflag. (This is the only\r\npurpose of \"Azure\r\nKubernetes Service\r\nCluster User Role\".) The\r\nresult, on a Microsoft\r\nEntra ID-enabled cluster,\r\nis the download of an\r\nempty entry into\r\n.kube/config , which\r\ntriggers browser-based\r\nauthentication when it's\r\nfirst used by kubectl .\r\nUser is not in any of these\r\ngroups. Because the user is not\r\nin any Cluster Admin groups,\r\ntheir rights will be controlled\r\nentirely by any RoleBindings or\r\nClusterRoleBindings that have\r\nbeen set up by cluster admins.\r\nThe (Cluster)RoleBindings\r\nnominate Microsoft Entra users\r\nor Microsoft Entra groups as\r\ntheir subjects . If no such\r\nbindings have been set up, the\r\nuser will not be able to excute\r\nany kubectl commands.\r\nIf you want fine-grained\r\naccess control, and you're\r\nnot using Azure RBAC\r\nfor Kubernetes\r\nAuthorization. Note that\r\nthe user who sets up the\r\nbindings must log in by\r\none of the other methods\r\nlisted in this table.\r\nMicrosoft Entra ID by\r\nmember of admin\r\ngroup\r\nSame as above\r\nUser is a member of one of the\r\ngroups listed here. AKS\r\nautomatically generates a\r\nClusterRoleBinding that binds\r\nall of the listed groups to the\r\ncluster-admin Kubernetes\r\nrole. So users in these groups\r\ncan run all kubectl commands\r\nas cluster-admin .\r\nIf you want to\r\nconveniently grant users\r\nfull admin rights, and are\r\nnot using Azure RBAC\r\nfor Kubernetes\r\nauthorization.\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 11 of 12\n\nDescription Role grant required\r\nCluster admin Microsoft\r\nEntra group(s)\r\nWhen to use\r\nMicrosoft Entra ID\r\nwith Azure RBAC for\r\nKubernetes\r\nAuthorization\r\nTwo roles:\r\nFirst, Azure Kubernetes\r\nService Cluster User\r\nRole (as above).\r\nSecond, one of the \"Azure\r\nKubernetes Service\r\nRBAC...\" roles listed\r\nabove, or your own\r\ncustom alternative.\r\nThe admin roles field on the\r\nConfiguration tab is irrelevant\r\nwhen Azure RBAC for\r\nKubernetes Authorization is\r\nenabled.\r\nYou are using Azure\r\nRBAC for Kubernetes\r\nauthorization. This\r\napproach gives you fine-grained control, without\r\nthe need to set up\r\nRoleBindings or\r\nClusterRoleBindings.\r\nNext steps\r\nTo get started with Microsoft Entra ID and Kubernetes RBAC, see Integrate Microsoft Entra ID with AKS.\r\nFor associated best practices, see Best practices for authentication and authorization in AKS.\r\nTo get started with Azure RBAC for Kubernetes Authorization, see Use Azure RBAC to authorize access within the\r\nAzure Kubernetes Service (AKS) Cluster.\r\nTo get started securing your kubeconfig file, see Limit access to cluster configuration file.\r\nTo get started with managed identities in AKS, see Use a managed identity in AKS.\r\nFor more information on core Kubernetes and AKS concepts, see the following articles:\r\nKubernetes / AKS clusters and workloads\r\nKubernetes / AKS security\r\nKubernetes / AKS virtual networks\r\nKubernetes / AKS storage\r\nKubernetes / AKS scale\r\nSource: https://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nhttps://learn.microsoft.com/en-us/azure/aks/concepts-identity\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://learn.microsoft.com/en-us/azure/aks/concepts-identity"
	],
	"report_names": [
		"concepts-identity"
	],
	"threat_actors": [],
	"ts_created_at": 1775434028,
	"ts_updated_at": 1775826726,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8f4bae4a8c32c61316050fb607340786402ced27.pdf",
		"text": "https://archive.orkl.eu/8f4bae4a8c32c61316050fb607340786402ced27.txt",
		"img": "https://archive.orkl.eu/8f4bae4a8c32c61316050fb607340786402ced27.jpg"
	}
}