Christos Polydorou

One of the very first problems when starting to deploy workloads in Azure Kubernetes Service is the segregation of the network. By default, all pods are part of the same network and can communicate with each other. In the majority of the cases, however, we want to restrict network access between pods, namespaces, applications, etc. Fortunately, K8s provide a way to easily control network traffic, called Network Policies . There are two types of policies that can be applied to a pod, Ingress and Egress. Ingress-type policies control the traffic inbound to the pod, whilst egress control the traffic outbound from a pod. In this post, we're going to work only with ingress-type policies since the configuration and principles are pretty much the same, it's just the direction that changes. To demonstrate the use of policies, we are going to be using three namespaces and each namespace will contain a deployment with containers that respond to ping requests and also contain the ping uti

Starting with the fact that every web application should be protected by a Web Application Firewall (WAF) and accelerated using a Content Delivery Network (CDN), combined with the simplicity of the deployment of the Azure Front Door service, gives you no excuses for not protecting your apps! In this blog post, we're going to deploy an AppService and protect it using Azure Front Door. For the purposes of this demo, we're going to use the NodeJS - RequestInformation app that is available in my Github repo over  here . This application provides information on the platform and incoming requests that is going to be very handy later on. To deploy the demo resources, you just have to clone this repository, change to the  FrontDoor-AppServiceBackend-001/101-Bicep-Templates/900-IaC-FullDeployment-001 directory, and execute the deploy.sh script. The script will create a subscription-level deployment that will deploy an AppService (including the plan) and an Azure Front Door. Make sur