Securing Windows workloads on Azure Kubernetes Service with Calico

by Contributed | May 8, 2023 | Technology

This article is contributed. See the original author and article here.

This blog post has been co-authored by Microsoft and Dhiraj Sehgal, Reza Ramezanpur from Tigera.

Container orchestration pushes the boundaries of containerized applications by preparing the necessary foundation to run containers at scale. Today, customers can run Linux and Windows containerized applications in a container orchestration solution, such as Azure Kubernetes Service (AKS).

This blog post will examine how to set up a Windows-based Kubernetes environment to run Windows workloads and secure them using Calico Open Source. By the end of this post, you will see how simple it is to apply your current Kubernetes skills and knowledge to rule a hybrid environment.

Container orchestration at scale with AKS

After creating a container image, you will need a container orchestrator to deploy it at scale. Kubernetes is a modular container orchestration software that will manage the mundane parts of running such workloads, and AKS abstracts the infrastructure on which Kubernetes runs, so you can focus on deploying and running your workloads.

In this blog post, we will share all the commands required to set up a mixed Kubernetes cluster (Windows and Linux nodes) in AKS – you can open up your Azure Cloud Shell window from the Azure Portal and run the commands if you want to follow along.

If you don’t have an Azure account with a paid subscription, don’t worry—you can sign up for a free Azure account to complete the following steps.

Resource group

To run a Kubernetes cluster in Azure, you must create multiple resources that share the same lifespan and assign them to a resource group. A resource group is a way to group related resources in Azure for easier management and accessibility. Keep in mind that each resource group must have a unique name.

The following command creates a resource group named calico-win-container in the australiaeast location. Feel free to adjust the location to a different zone.

az group create --name calico-win-container --location australiaeast

Cluster deployment

Note: Azure free accounts cannot create any resources in busy locations. Feel free to adjust your location if you face this problem.

A Linux control plane is necessary to run the Kubernetes system workloads, and Windows nodes can only join a cluster as participating worker nodes.

az aks create --resource-group calico-win-container --name CalicoAKSCluster --node-count 1 --node-vm-size Standard_B2s --network-plugin azure --network-policy calico --generate-ssh-keys --windows-admin-username 

Windows node pool

Now that we have a running control plane, it is time to add a Windows node pool to our AKS cluster.

Note: Use `windows` as the value for the ‘–os-type’ argument.

az aks nodepool add --resource-group calico-win-container --cluster-name CalicoAKSCluster --os-type Windows --name calico --node-vm-size Standard_B2s --node-count 1

Calico for Windows

Calico for Windows is officially integrated into the Azure platform. Every time you add a Windows node in AKS, it will come with a preinstalled version of Calico. To check this, use the following command to ensure EnableAKSWindowsCalico is in a Registered state:

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableAKSWindowsCalico')].{Name:name,State:properties.state}"

Expected output:

Name                                               State
-------------------------------------------------  ----------
Microsoft.ContainerService/EnableAKSWindowsCalico  Registered

If your query returns a Not Registered state or no items, use the following command to enable AKS Calico integration for your account:

az feature register --namespace "Microsoft.ContainerService" --name "EnableAKSWindowsCalico"

After EnableAKSWindowsCalico becomes registered, you can use the following command to add the Calico integration to your subscription:

az provider register --namespace Microsoft.ContainerService

Exporting the cluster key

Kubernetes implements an API Server that provides a REST interface to maintain and manage cluster resources. Usually, to authenticate with the API server, you must present a certificate, username, and password. The Azure command-line interface (Azure CLI) can export these cluster credentials for an AKS deployment.

Use the following command to export the credentials:

az aks get-credentials --resource-group calico-win-container --name CalicoAKSCluster

After exporting the credential file, we can use the kubectl binary to manage and maintain cluster resources. For example, we can check which operating system is running on our nodes by using the OS labels.

kubectl get nodes -L kubernetes.io/os

You should see a similar result to:

NAME                                STATUS   ROLES   AGE     VERSION   OS
aks-nodepool1-64517604-vmss000000   Ready    agent   6h8m    v1.22.6   linux
akscalico000000                     Ready    agent   5h57m   v1.22.6   windows

Windows workloads

If you recall, Kubernetes API Server is the interface that we can use to manage or maintain our workloads.

We can use the same syntax to create a deployment, pod, service, or Kubernetes resource for our new Windows nodes. For example, we can use the same OS selector that we previously used for our deployments to ensure Windows and Linux workloads are deployed to their respective nodes:

kubectl apply -f https://raw.githubusercontent.com/frozenprocess/wincontainer/main/Manifests/00_deployment.yaml

Since our workload is a web server created by Microsoft’s .NET technology, the deployment YAML file also packages a service load balancer to expose the HTTP port to the Internet.

Use the following command to verify that the load balancer successfully acquired an external IP address:

kubectl get svc win-container-service -n win-web-demo

You should see a similar result:

NAME                    TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)        AGE
win-container-service   LoadBalancer   10.0.203.176   20.200.73.50   80:32442/TCP   141m

Use the “EXTERNAL-IP” value in a browser, and you should see a page with the following message:

Perfect! Our pod can communicate with the Internet.

Securing Windows workloads with Calico

The default security behavior for the Kubernetes NetworkPolicy resource permits all traffic. While this is a great way to set up a lab environment in a real-world scenario, it can severely impact your cluster’s security.

First, use the following manifest to enable the API server:

kubectl apply -f https://raw.githubusercontent.com/frozenprocess/wincontainer/main/Manifests/01_apiserver.yaml

Use the following command to get the API Server deployment status:

kubectl get tigerastatus

You should see a similar result to:

NAME        AVAILABLE   PROGRESSING   DEGRADED   SINCE
apiserver   True        False         False      10h
calico      True        False         False      10h

Calico offers two security policy resources that can cover every corner of your cluster. We will implement a global policy since it can restrict Internet addresses without the daunting procedure of explicitly writing every IP/CIDR in a policy.

kubectl apply -f https://raw.githubusercontent.com/frozenprocess/wincontainer/main/Manifests/02_default-deny.yaml

If you go back to your browser and click the Try again button, you will see that the container is isolated and cannot initiate communication to the Internet.

Note: The source code for the workload is available here.

Clean up
If you have been following this blog post and did the lab section in Azure, please make sure that you delete the resources, as cloud providers will charge you based on usage.

Use the following command to delete the resource group:

Conclusion

While network policy is not relevant for lab scenarios, production workloads have a different level of security requirements to meet. Calico offers a simple and integrated way to apply network policies to Windows workloads on Azure Kubernetes Service. In this blog post, we covered the basics for implementing a network policy to a simple web server. You can check out more information on how Calico works with Windows on AKS in our documentation page.

Additional links:

• Tigera’s certification courses.


• Webinar CNCF On-Demand Webinar: Securing Windows Workloads.


• Ready to become an Azure expert? Enroll in Calico Azure course now.

Security baseline for Microsoft Edge version 113

by Contributed | May 6, 2023 | Technology

This article is contributed. See the original author and article here.

We are pleased to announce the security review for Microsoft Edge, version 113!

We have reviewed the new settings in Microsoft Edge version 113 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 112 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit.

Microsoft Edge version 113 introduced 3 new computer settings and 3 new user settings. We have included a spreadsheet listing the new settings in the release to make it easier for you to find them.

As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here.

Please continue to give us feedback through the Security Baselines Discussion site or this post.