KodeKloud Notes

Before diving into AKS authentication and authorization, it’s essential to understand the core Azure Active Directory (AAD) identity types. AAD identities establish trust, authenticate users and applications, and control access across Azure services.

Azure AD Identity Types

At a high level, Azure AD supports four identity types:

User Identity
An individual AAD account used for interactive sign-ins and access control.
Application Identity
A registered app in AAD that can authenticate and access resources on behalf of a user or itself.
Service Principal
A non-interactive app identity for automation, CI/CD pipelines, or service-to-service scenarios. It authenticates with a client ID and secret (or certificate).
Warning
Service principals require regular secret or certificate rotations. If credentials expire, any AKS operations using that principal will fail.
Managed Identity
A system-assigned or user-assigned identity created and managed by Azure. Eliminates manual secret management by obtaining tokens directly from AAD.

Note

If you’re familiar with on-premises Active Directory, managed identities behave like built-in system accounts that Azure handles automatically.

Service Principal vs. Managed Identity

Feature	Service Principal	Managed Identity
Credential Management	Secrets or certificates to rotate	No secrets; tokens issued transparently
Lifecycle	Provisioned manually	Auto-provisioned with Azure resources
Use Cases	Custom automation, CI/CD pipelines	AKS control plane, VM-to-Azure service access

The image explains identity management in Azure AD, highlighting Service Principal Identity and Managed Identity, with a note on using client ID, client secret, or certificates for authentication.

When you create an AKS cluster with default settings, Azure provisions:

A managed identity for the cluster control plane
Two service principals in the same resource group
The managed identity appears under Enterprise Applications in AAD

The image shows the Microsoft Azure portal interface for managing an enterprise application named "kodecloud-aks." It includes sections for properties, getting started steps, and updates on features.

Kubernetes Role-Based Access Control (RBAC)

Kubernetes RBAC lets you define fine-grained permissions via Roles and RoleBindings:

Roles (namespace-scoped) or ClusterRoles (cluster-wide) specify allowed verbs on resources.
RoleBindings or ClusterRoleBindings assign these roles to subjects (users, groups, or service accounts).

The image is an infographic about Kubernetes RBAC, showing components of identities (providers, users/groups, service accounts) and access control (namespace scoped roles, role bindings, cluster roles, and cluster role bindings).

Kubernetes supports multiple identity providers out-of-the-box:

The image outlines Kubernetes identity providers, including X509 Certificates, Kubernetes Service Accounts, and OpenID Connect (OAuth2), with brief descriptions of each.

X.509 Certificates
Service Accounts (in-cluster)
OpenID Connect (e.g., Azure AD)

Example ClusterRole

Grants get and patch on daemonsets and deployments (in the apps API group), and get on configmaps (in the core API group):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kodekloud-clusterrole
rules:
  - apiGroups: ["apps"]
    resources: ["daemonsets", "deployments"]
    verbs: ["get", "patch"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get"]

Example ClusterRoleBinding

Binds the above ClusterRole to an Azure AD group by its object ID:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-reader-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kodekloud-clusterrole
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: 8e9a4227-0e29-4d2a-9fd3-cacae5a6821e

AKS Authentication and Authorization Options

The image illustrates the progression of authentication and authorization methods in AKS, from local accounts with Kubernetes RBAC to Azure AD authentication with Kubernetes and Azure RBAC.

You can choose between three authentication and authorization modes when deploying AKS:

Method	Authentication	Authorization	Key Benefit
Local Accounts + Kubernetes RBAC (Default)	K8s service accounts, tokens	Kubernetes RBAC	Quick start with built-in K8s controls
Azure AD Auth + Kubernetes RBAC	Azure AD users/groups	Kubernetes RBAC	Leverage MFA, conditional access policies
Azure AD Auth + Azure RBAC	Azure AD users/groups	Azure role assignments	Centralized IAM across Azure resources

Local Accounts with Kubernetes RBAC (Default)
- Native service accounts, roles, and bindings stored in the cluster
- Auth via certificates, tokens, or basic auth
Azure AD Authentication with Kubernetes RBAC
- Users sign in with Azure AD credentials
- K8s RBAC enforces permissions
- Supports Azure AD features like MFA
Azure AD Authentication and Azure RBAC
- Azure AD handles both authentication and authorization
- Use Azure role assignments to grant AKS permissions
- Provides a seamless IAM experience across Azure

Feel free to experiment with these modes in your environment. Next up: Azure Defender for AKS.

Links and References

Watch Video

Watch video content