AKS Security: RBAC, Network Policies, Pod Identity

Kubernetes RBAC (Role-Based Access Control) is the primary mechanism for controlling access to the Kubernetes API server. In AKS, RBAC is enabled by default and integrated with Azure Active Directory (Azure AD) for user authentication, but Kubernetes RBAC governs authorization for both users and service accounts.

How it works: - Roles and ClusterRoles: A Role defines a set of permissions (verbs on resources) within a specific namespace. A ClusterRole is similar but cluster-scoped (non-namespaced resources like nodes, or can be used across all namespaces). - RoleBindings and ClusterRoleBindings: These bind a Role/ClusterRole to a subject (user, group, or service account). RoleBindings are namespace-scoped; ClusterRoleBindings are cluster-scoped. - Verbs: Typical verbs include get, list, watch, create, update, patch, delete. The exam tests knowledge of which verbs apply to which resources. - Resources: Examples: pods, deployments, services, secrets, configmaps, nodes, namespaces. Note that secrets and configmaps are often tested.

Default values and timers: There are no timers in RBAC; changes are effective immediately upon applying the binding. However, cached authorization decisions may take up to 5 minutes to refresh in some configurations, but this is not a default behavior.

Configuration example:

Create a Role that allows reading pods in the default namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Bind this role to a user:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: "alice@contoso.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Verification commands:

kubectl get roles --all-namespaces
kubectl get rolebindings --all-namespaces
kubectl describe role pod-reader -n default
kubectl auth can-i get pods --as alice@contoso.com -n default

Interaction with Azure AD: For human users, AKS integrates Azure AD to authenticate. The user's Azure AD token is presented to the API server, which validates it via Azure AD. Then Kubernetes RBAC authorizes the request. For service accounts (used by pods), Kubernetes issues its own tokens, but Pod Identity (discussed later) can be used to integrate with Azure AD for pod-level identities.

Network policies in Kubernetes are firewall rules that control traffic between pods at the IP address or port level. They are implemented by a network plugin (e.g., Azure CNI, Calico). In AKS, network policies can be enforced using Azure Network Policies (built-in) or Calico (third-party).

How it works: - Network policies are namespace-scoped and are applied to pods via label selectors. - A policy consists of podSelector (target pods), policyTypes (Ingress, Egress, or both), ingress rules (allowed inbound traffic), and egress rules (allowed outbound traffic). - By default, all pod-to-pod traffic is allowed. Once any network policy selects a pod, that pod becomes isolated: only traffic explicitly allowed by the policy is permitted. - Rules can specify from/to using podSelector, namespaceSelector, ipBlock, or a combination.

Key components and defaults: - PodSelector: If empty, the policy applies to all pods in the namespace. - PolicyTypes: If not specified, defaults to Ingress if any ingress rules exist, similarly for egress. But best practice is to specify both. - ipBlock: Used for traffic to/from outside the cluster (e.g., Azure SQL database). Must specify CIDR and optional except. - Ports: Can specify port number and protocol (TCP, UDP, SCTP). Default protocol is TCP if not specified.

Example network policy:

Allow only frontend pods to communicate with backend pods on port 6379:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:

- Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 6379

Verification commands:

kubectl get networkpolicy
kubectl describe networkpolicy backend-policy

How it interacts with related technologies: - In AKS, network policies require a network policy engine. Azure Network Policies is the default for clusters using Azure CNI. Calico can be used as an alternative, offering more advanced features like global network policies and egress access controls. - Network policies do not affect pod-to-service traffic (the service IP is virtual; the policy applies to the actual pod IPs). - For DNS resolution, pods need egress access to the DNS service IP (typically 10.0.0.10 in AKS). A common misconfiguration is blocking DNS, causing name resolution failures.

Azure AD Pod Identity enables pods in AKS to authenticate to Azure services (e.g., Key Vault, Storage, SQL Database) using a managed identity assigned to the pod, without embedding credentials. It is an add-on that must be enabled on the AKS cluster.

How it works: - The Pod Identity add-on deploys two components: the Node Management Identity (NMI) daemon and the Managed Identity Controller (MIC). - A pod is assigned an Azure AD identity through a custom resource called AzureIdentity and AzureIdentityBinding. - When a pod makes a request to Azure Instance Metadata Service (IMDS) endpoint (169.254.169.254), NMI intercepts the request, checks if the pod has a matching identity, and acquires a token from Azure AD on behalf of the pod. - The token is then returned to the pod, which can use it to access Azure resources.

Key components: - AzureIdentity: Defines the Azure AD managed identity (user-assigned) that will be used by pods. It specifies the resource ID of the managed identity. - AzureIdentityBinding: Links the AzureIdentity to a pod based on a selector label. Pods with a matching label are allowed to use that identity. - Managed Identity Controller (MIC): Watches for changes to identities and bindings, and updates the NMI daemon with the mapping. - Node Management Identity (NMI): Runs as a DaemonSet on each node, intercepts IMDS requests, and acquires tokens.

Configuration example:

az aks enable-addons --addons pod-identity --name myAKSCluster --resource-group myResourceGroup

apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentity
metadata:
  name: my-identity
spec:
  type: 0  # User-assigned managed identity
  resourceID: /subscriptions/<sub>/resourcegroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity
  clientID: <client-id-of-identity>
---
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentityBinding
metadata:
  name: my-identity-binding
spec:
  azureIdentity: my-identity
  selector: my-label

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    aadpodidbinding: my-label
spec:
  containers:
  - name: my-container
    image: my-image

The pod can now request a token using the IMDS endpoint.

Verification commands:

kubectl get azureidentity
kubectl get azureidentitybinding
kubectl describe pod my-pod

Interaction with related technologies: - Pod Identity is often used with Azure Key Vault via the Key Vault FlexVolume driver or CSI driver, allowing pods to mount secrets as files. - It replaces the need for service principal credentials in container images. - The pod identity is bound to the pod's lifetime; if the pod is deleted, the identity assignment is removed.

Common pitfalls: - The managed identity must have appropriate RBAC permissions on the target Azure resource (e.g., Key Vault access policy). - Pod Identity does not work with system-assigned managed identities; only user-assigned. - The NMI modifies iptables rules on the node to intercept IMDS traffic; this can conflict with other network plugins if not properly configured.

A financial services company runs a microservices application on AKS where each microservice is in its own namespace. They need to ensure that only the frontend service can talk to the backend service, and the backend service can only talk to the database. They implement Kubernetes network policies: a policy in the frontend namespace allows egress to backend namespace on port 8080, and a policy in the backend namespace allows ingress from frontend on port 8080 and egress to database service IP on port 5432. They also use Azure Network Policies for simplicity. In production, they run 50 namespaces with hundreds of pods. Performance is not impacted because network policies are enforced at the node level using iptables. Common issues: forgetting to allow DNS egress (port 53) causes pod startup failures. They monitor network policy logs using Azure Monitor for containers.

A healthcare startup stores patient data in Azure Key Vault. Their AKS pods need to retrieve secrets (API keys, connection strings) without embedding them in images. They enable Pod Identity add-on and create a user-assigned managed identity with Key Vault Secrets Officer role. They deploy AzureIdentity and AzureIdentityBinding for each microservice. The application code uses the Azure SDK to request a token from IMDS (169.254.169.254) and then calls Key Vault. They use the Key Vault CSI driver to mount secrets as volumes, which simplifies code. In production, they have 20 identities and 200 pods. Issues: if the NMI daemon fails, pods cannot get tokens; they run multiple replicas of NMI to ensure availability. They also set --enable-pod-identity-pod-identity-exception to allow certain pods to bypass the interception.

An enterprise runs a shared AKS cluster for multiple teams. Each team has its own namespace. They integrate Azure AD and use Azure AD groups for access control. The platform team has cluster-admin via a ClusterRoleBinding. Each team has a custom Role that allows full control within their namespace. They use kubectl with Azure AD authentication. They enforce that no one can create RoleBindings that grant cluster-admin. They audit RBAC changes using Azure Policy for Kubernetes. In production, they have 500 users across 10 teams. Issues: users often request more permissions than needed; they use kubectl auth can-i to verify before granting. They also use Azure AD Privileged Identity Management (PIM) for temporary elevation.