<p>I'm reading the docs on <a href="https://learn.microsoft.com/en-us/azure/aks/azure-ad-integration-cli" rel="nofollow noreferrer">integrating AAD with AKS</a> and it doesn't seem like a great solution. It takes the approach of including group membership claims in the token itself, but in JWTs there is a max of 200 group claims allowed - easily surpassed for users in large organizations, since the claims include transitive group membership. There are two much superior approaches:</p>

<ol>
<li>Associate security groups with roles in the service principal object, then have AKS make authorization decisions based on what roles are in the JWT (<a href="https://learn.microsoft.com/en-us/azure/architecture/multitenant-identity/app-roles" rel="nofollow noreferrer">docs</a>)</li>
<li>Add the AAD Graph Directory.Read.All scope to the AKS AAD application so AKS can query group membership on request with the on-behalf-of flow (requires AAD admin consent, which is annoying, but whatever).</li>
</ol>

<p>Since the current solution does not fit our needs, I have to ask - if we can't integrate AAD with AKS then how is the cluster secured? Is it insecure by default?</p>

ahelwer
<p>By default its using <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="nofollow noreferrer">Kubernetes security model</a>, when you integrate it with AAD nothing really changes, you just can assign AAD principles to Kubernetes roles. That's it. So its no more secure with AAD integration, its just more convenient to manage permissions using AAD principles compared to having to create users inside kubernetes and grant them permissions</p>
