Kubernetes best practices in Azure: AKS name space isolation and AAD integration

Once you have decided to run your workloads in AKS service in Azure, there are certain best practices to be followed during design and implementation. In this blog we will discuss two of these recommended practices and the practical aspects of their implementation- Azure AD integration and name space isolation



While AAD helps to authenticate users to your AKS cluster using the existing users and groups in your Azure AD, name space isolation provides logical isolation of resources used by them. It is useful in multi tenant scenarios where the same cluster is being used by different teams/departments to run their workloads. It is also useful in running say a dev, test and QA environment for organization in the same cluster. Combining AAD integration with name spaces allow users to login to their namespace using their Azure AD credentials

AAD integration with AKS :

The following Microsoft document will get you started  with AAD integration of AKS cluster.: https://docs.microsoft.com/en-us/azure/aks/aad-integration


 Please note that you cannot convert a non-RBAC enabled cluster to RBAC enabled one. It has to be done during the cluster creation. Before following the steps in the document, you have to make sure that Azure tenant administrator rights to grant permissions to the server and client application.


The 'az aks create' command sample in the reference document should help with the cluster creation. It creates the cluster with three nodes, but if you want to tweak it a lil bit especially if you are playing around with the service for learning purpose and don't want to burn out your subscription credits, you can use the  " --node-count 1" argument to limit the number of nodes to 1. Additional options can be used with 'az aks create' command for further customization, for eg if you want to change VM SKU etc. Full reference for the options can be found here : https://docs.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest#az-aks-create

AKS namespaces and RBAC authentication:

Kubernetes has three initial namespaces - default,kube-system and Kube-Public.You can create  a new namespace using the following sample namespace.yaml file (Ref: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/ )


apiVersion: v1
kind: Namespace
metadata:
  name: testnamespace



Create the namespace using the Kubectl create command


Kubectl create -f namespace.yaml



Next step is to create a role and rolebinding. In the reference document for enabling RBAC for AKS , a role and rolebinding is created but for a cluster-admin role. However we need to create a role and rolebinding to give user access to resources within a namespace. The following K8S reference document has some sample files for role and rolebinding. You might want to tweak it a bit to change the namespace reference to the namespace you had created earlier : https://kubernetes.io/docs/reference/access-authn-authz/rbac/


Sample file for creating role that has access to read pods in a cluster:kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: testnamespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]




While using AKS with RBAC, it is beneficial to give access to Azure AD groups access to a given namespace by providing the Azure AD group ID reference in the rolebinding yaml as shown in sample below.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: testnamespace
subjects:
- kind: Group
  name: <Azure AD Group ID>
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader 
  apiGroup: rbac.authorization.k8s.io


After applying the configurations, you can login to AKS cluster using credentials of user added to the AD group (Ref: https://docs.microsoft.com/en-us/azure/aks/aad-integration#access-cluster-with-azure-ad )  
Tip: Users can change context to the namespace to which they have access before running kubectl commands. Else they would have to use the --namespace switch with each command they want to run in the cluster. Refer this ks8 document for instructions on switching namespace context :https://kubernetes.io/docs/tasks/administer-cluster/namespaces/

Read More

Introducing Azure Firewall

Azure firewall is the latest addition to Azure security features portfolio. It was announced in preview last week along with Azure virtual WAN. Along with other features such as NSG and WAF , Azure Firewall enables additional protection for your applications hosted in Azure. We know that NSG offers network level protection(L3) and helps in implementing restrictions on incoming and outgoing traffic at network layer. WAF enables inbound security for web applications at Layer 7.Azure Network firewall provides outbound network layer(L3-L4) and application level (L7) protection for Http and Https traffic.

There are two types of rules that can be created in Azure Firewall. Application rule and Network rule. As name indicates Network rule can be used to allow/deny traffic at network layer by defining the source IP & protocol + Destination IP& protocol. Application rules can be created to allow or restrict outbound traffic to specific FQDNs.

If you want to play around with Azure Firewall, Refer this document for a step by step approach.  It outlines the process of accessing a VM in a network protected using Azure firewall.

https://docs.microsoft.com/en-us/azure/firewall/tutorial-firewall-deploy-portal

 

Image courtesy:Microsoft

Few pointers here that will help you understand the configuration:

• Workload VM(Srv-Work) is created in the subnet Workload-SN
• The workload VM is accessed using a JumpBox server(Srv-Jump) as the workload VM does not have a public IP associated with it
• Workload-SN had a default rule applied that redirects all outbound traffic to the Firewall. If you review the effective rules of Workload VM NIC card, the default route will be listed that routes the outbound traffic to Azure Firewall.

 

• In the firewall, Network and application rules are created allowing only required traffic from the Workload VM. In the example, DNS resolution is allowed using network rules and access to GitHub is allowed using application rule.
• DNS resolution is restricted to specific DNS servers and the DNS server IPs are hard coded in the workload VM NIC as custom DNS

 

PS: The document has instructions for creating a network rule in Firewall to allow DNS using protocol TCP. However, I couldn’t get it working without adding UDP. I have provided feedback in the document to check on this.

Other than that, the instructions work like a charm and I could get the set up working without any other glitches. Since internet access is restricted to specific FQDN, access to any other website will be denied. If you try accessing a website whose FQDN is not defined in the rule, you will get the following message

 

 

Viola.. that’s your Azure firewall in Action!! You can also create and connect Azure Firewall to existing VNets from VNet -> Settings. However, do keep in mind that this service is currently in preview.

Read More