{"id":1619,"date":"2021-05-12T15:52:53","date_gmt":"2021-05-12T22:52:53","guid":{"rendered":"http:\/\/blog.nillsf.com\/?p=1619"},"modified":"2021-05-12T17:14:19","modified_gmt":"2021-05-13T00:14:19","slug":"block-public-load-balancers-on-azure-kubernetes-service-using-azure-policy","status":"publish","type":"post","link":"https:\/\/blog.nillsf.com\/index.php\/2021\/05\/12\/block-public-load-balancers-on-azure-kubernetes-service-using-azure-policy\/","title":{"rendered":"Block public load balancers on Azure Kubernetes Service using Azure policy"},"content":{"rendered":"\n

In this post, I’ll explain to you how you can use Azure Policy to restrict the creation of load balancers with a public IP in AKS using Azure policy.<\/p>\n\n\n\n

Azure policy is a way to ensure your Azure deployments follow your standards. Policies are a set of restrictive rules, that control what can be deployed in your Azure environment. They do not control who gets access to your environment, that is controlled through role-based access control.<\/p>\n\n\n\n

Azure policy has a plugin available that allows you to configure Azure policy on top of Kubernetes as well. This gives you the ability the use Azure policy to manage the state of your resources inside a Kubernetes cluster. To make this work, Azure policy under the covers uses a combination of Gatekeeper<\/a>, Open Policy Agent<\/a>, and admission webhooks<\/a>. <\/p>\n\n\n\n

To restrict the creation of public load balancers, we’ll use Azure policy on a new cluster. Let’s get this going:<\/p>\n\n\n\n

Setup<\/h2>\n\n\n\n

For this small experiment, I created a new cluster with Azure policy enabled at the creation time:<\/p>\n\n\n\n

az group create -n aks-policy -l westus2\naz aks create -n aks-policy -g aks-policy --enable-managed-identity --enable-addons azure-policy --node-count 1\naz aks get-credentials -n aks-policy -g aks-policy<\/code><\/pre>\n\n\n\n
I then went into the portal to assign a new Azure policy to this cluster. The policy I was looking for was: “Kubernetes clusters should use internal load balancers”.<\/p>\n\n\n\n
Once you open Azure policy in the portal, select the Kubernetes category and look for the keyword “internal”, as shown in the picture below:<\/p>\n\n\n\n
\"\"
Finding the right policy<\/figcaption><\/figure>\n\n\n\n
The next screen shows you the actual policy in JSON, and giving you the ability to assign it:<\/p>\n\n\n\n
\"\"
Overview of the policy definition<\/figcaption><\/figure>\n\n\n\n
Next up, you have to select the scope for this policy. In my case, I’m only assigning it to the resource group of the cluster. In your case, you could apply it to your full subscription or management group if you want to have it apply everywhere:<\/p>\n\n\n\n
\"\"
Assigning the policy to the right scope<\/figcaption><\/figure>\n\n\n\n
Next, you can configure certain inclusion\/exclusions. In this example, I’ll have it apply to all namespaces except the default 3 and the internet namespace:<\/p>\n\n\n\n
\"\"
Exclusion of the internet namespace (along the default namespace exclusions)<\/figcaption><\/figure>\n\n\n\n
Finally, we can review and create the policy:<\/p>\n\n\n\n
\"\"
Creating the policy<\/figcaption><\/figure>\n\n\n\n
Once you hit the create button, you’ll get a popup confirming the policy is being applied. It can take up to 30 minutes for it to appear on your cluster:<\/p>\n\n\n\n
\"\"
Verification that the policy was created<\/figcaption><\/figure>\n\n\n\n
After those 30 minutes have passed, let’s try this out!<\/p>\n\n\n\n
Trying out the policy<\/h2>\n\n\n\n
To verify the policy, I’ll be using an example from my latest book: the guestbook all-in-one example,<\/a> which includes a public load balancer.<\/p>\n\n\n\n
Let’s start by trying it out in the default namespace:<\/p>\n\n\n\n
kubectl create ns blocked\nkubectl create -n blocked -f https:\/\/raw.githubusercontent.com\/PacktPublishing\/Hands-on-Kubernetes-on-Azure-Third-Edition\/main\/Chapter05\/guestbook-all-in-one.yaml<\/code><\/pre>\n\n\n\n
This resulted in the (expected) error:<\/p>\n\n\n\n
\"\"
In the blocked namespace, we are getting the policy error<\/figcaption><\/figure>\n\n\n\n
Let’s try the same using an internal load balancer:<\/p>\n\n\n\n
k create -f https:\/\/raw.githubusercontent.com\/NillsF\/blog\/master\/aks-policy\/ilb.yaml -n blocked<\/code><\/pre>\n\n\n\n
Which does not result in an error, since this is allowed:<\/p>\n\n\n\n
\"\"
Creating an internal load balancer in the ILB namespace doesn’t result in an error<\/figcaption><\/figure>\n\n\n\n
Let’s try creating a public load balancer in the internet namespace:<\/p>\n\n\n\n
kubectl create ns internet\nkubectl create -n internet -f https:\/\/raw.githubusercontent.com\/PacktPublishing\/Hands-on-Kubernetes-on-Azure-Third-Edition\/main\/Chapter05\/guestbook-all-in-one.yaml<\/code><\/pre>\n\n\n\n
Which – as expected – succeeded without the error:<\/p>\n\n\n\n
\"\"
In the internet namespace, we are not getting the error.<\/figcaption><\/figure>\n\n\n\n
This shows you how to use Azure policy to limit the creation of Azure public load balancers.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
This post explained to you how to use Azure policy to limit the creation of public services in AKS. This post showed you how to create a new cluster with Azure policy enabled, how to assign the “Kubernetes clusters should use internal load balancers” policy to your cluster. You then saw how the policy shows a visual error when public services get created. <\/p>\n","protected":false},"excerpt":{"rendered":"
In this post, I’ll explain to you how you can use Azure Policy to restrict the creation of load balancers with a public IP in AKS using Azure policy. Azure policy is a way to ensure your Azure deployments follow your standards. Policies are a set of restrictive rules, that control what can be deployed […]<\/p>\n","protected":false},"author":1,"featured_media":1630,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[2,3,58,4,36],"tags":[115,102,18,132,38],"class_list":["post-1619","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-devops","category-kubernetes","category-management","category-networking","tag-azure-kubernetes-service","tag-azure-policy","tag-kubernetes","tag-load-balancing","tag-networking"],"jetpack_featured_media_url":"https:\/\/nillsfblog.blob.core.windows.net\/media\/2021\/05\/2021-05-12-15_48_30-PowerPoint-Slide-Show-Customize-core-dumps-in-Azure-Kubernetes.pptx.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/1619","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/comments?post=1619"}],"version-history":[{"count":5,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/1619\/revisions"}],"predecessor-version":[{"id":1635,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/1619\/revisions\/1635"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media\/1630"}],"wp:attachment":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media?parent=1619"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/categories?post=1619"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/tags?post=1619"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}