AKS | CNI security vulnerability in older AKS clusters and mitigation steps

Hi,

In this article, I would like to share with you a security notice about a new security vulnerability. This vulnerability has been identified in the container networking implementation (CNI) in CNI plugin versions v0.8.6 and older that may affect older AKS clusters.

Details

An AKS cluster configured to use an affected container networking implementation is susceptible to man-in-the-middle (MitM) attacks. By sending “rogue” router advertisements, a malicious container can reconfigure the host to redirect part or all of the IPv6 traffic of the host to the attacker-controlled container. Even if there was no IPv6 traffic before, if the DNS returns A (IPv4) and AAAA (IPv6) records, many HTTP libraries will try to connect via IPv6 first then fallback to IPv4, giving an opportunity to the attacker to respond.

This vulnerability has been given an initial severity of Medium with a score of 6.0.

Vulnerability analysis and verification

All AKS clusters created or upgraded with a Node Image Version later or equal than “2019.04.24” are not vulnerable, as they set net.ipv6.conf.all.accept_ra to 0 and enforce TLS with proper certificate validation.

Clusters created or last upgraded before that date are susceptible to this vulnerability.

You can verify if your current Node Image is vulnerable by running: https://aka.ms/aks/MitM-check-20200601  on a machine that has CLI access to the cluster’s nodes.

Windows nodes are not affected by this vulnerability.

Mitigation

If you identify nodes that are vulnerable, you can mitigate the vulnerability by performing a cluster upgrade using the following command:
$ az aks upgrade -n <cluster name> -g <cluster resource group> -k <newer supported kubernetes version>.

In addition, a permanent fix for this CVE is available at: https://github.com/containernetworking/plugins/releases/tag/v0.8.6 . AKS is rolling out this fix on the most recent VHD version.

Source: https://azure.microsoft.com/en-gb/updates/cni-security-vulnerability-in-older-aks-clusters-and-mitigation-steps/

Maxime.

AKS | System / User Node Pools

Salut!

Dans cet article, je vais vous présenter un nouveau concept du monde AKS, les system node pool et les user node pool. Mais avant tout chose, commençons ensemble par redéfinir le concept de Node Pool (pools de nœuds). Ls nœuds (node) d’une même configuration sont regroupés dans des pools de nœuds. Ces pools de nœuds contiennent les machines virtuelles sous-jacentes qui vont exécuter vos containers.

Un cluster AKS peut supporter plusieurs Node Pools, on retrouve plus souvent des architectures ou les node pools sont utilisés pour segmenter les applications critiques ou encore les application utilisants des ressources matériels spécifiques comme des GPUs.

Il est désormais possible de créer deux nouveaux types de node pools:

  • Node Pool System: Ce premier type de node pool va héberger l’ensemble des pods nécessaires au bon fonctionnement du cluster, c’est à dire Tunnelfront ou encore CoreDNS.
  • Node Pool User: Second type de node pool va héberger les pods de vos applications.

Si vous créer un cluster AKS, avec un seul node pool, ce node pool sera de type système. Il hébergera vos l’ensemble des pods nécessaire au bon fonctionnement du cluster ainsi que les pods de vos applications.

Dans ce premier exemple, nous allons créer un node pool de type system au sein d’un cluster AKS existant.

# - Add AKS Node Pool System to an existing AKS cluster
az aks nodepool add -g myResourceGroup --cluster-name myAKSCluster -n mynodepool --mode system

# - Show Node Pool Spec
az aks nodepool show -g myResourceGroup --cluster-name myAKSCluster -n mynodepool

Dans ce second exemple, nous allons créer un node pool de type user au sein d’un cluster AKS existiant.

# - Add AKS Node Pool System to an existing AKS cluster
az aks nodepool add -g myResourceGroup --cluster-name myAKSCluster -n mynodepool --mode user

# - Show Node Pool Spec
az aks nodepool show -g myResourceGroup --cluster-name myAKSCluster -n mynodepool

Maxime.


Hello,

In this article I would like share with you a new AKS concept: System Node Pool and User Mode Pool.

System node pools and user node pools are two different node pool modes for your AKS clusters.

  • System node pools serve the primary purpose of hosting critical system pods such as CoreDNS and tunnelfront.
  • User node pools serve the primary purpose of hosting your application pods.

However, application pods can be scheduled on system node pools if you wish to only have one pool in your AKS cluster. Every AKS cluster must contain at least one system node pool with at least one node.

In this first example, we will create system node pool inside our existing AKS cluster.

# - Add AKS Node Pool System to an existing AKS cluster
az aks nodepool add -g myResourceGroup --cluster-name myAKSCluster -n mynodepool --mode system

# - Show Node Pool Spec
az aks nodepool show -g myResourceGroup --cluster-name myAKSCluster -n mynodepool

In this second example, we will create user node pool inside our existing AKS cluster.

# - Add AKS Node Pool System to an existing AKS cluster
az aks nodepool add -g myResourceGroup --cluster-name myAKSCluster -n mynodepool --mode user

# - Show Node Pool Spec
az aks nodepool show -g myResourceGroup --cluster-name myAKSCluster -n mynodepool

Maxime.

Azure Security Center | Alerts Suppression Rules

[English below]

Bonjour!

Aujourd’hui, je vais vous présenter une nouvelle fonctionnalité disponible en public preview vous permettant de créer des règles afin de supprimer des alertes détectées par Azure Security Center Threat Protection.

Pour cela, je vous donne rendez-vous dans votre console Azure Security Center et je vous invite à cliquer sur « Suppression rules ».

Nous allons ajouter une nouvelle règle en cliquant sur : « Create new suppression rule »

Nous sélectionnons notre souscription Azure – dans cet exemple : Visual Studio Enterprise. Je vous invite ensuite à sélectionner l’alerte dont vous souhaitez rejeter les résultats. Dans cet exemple, il s’agit de l’alerte : « Role binding to the cluster-admin role detected ».

Nous donnons un nom à cette règle, son statut sera activé et nous pouvons choisir la raison de la création de cette alerte.

Enfin, nous pouvons définir une date de fin d’application de cette règle, et nous pouvons cliquer sur simuler afin de tester notre nouvelle règle. Pour finir, je vous invite à appliquer les modifications en cliquant sur : « Apply »

Nous pouvons constater que notre règle de suppression est désormais activée.

Cette fonctionnalité de suppression d’alertes Azure Security Center peut être vraiment intéressante dans des scénarios où vous avez des alertes qui sont un peu trop verbeuses à votre goût ou encore des faux positifs! Mais attention, ceci peut-être également dangereux : si vous masquez des alertes, vous perdez ainsi la visibilité sur de potentiels incidents de sécurité.

Maxime.


Hello,

In this article, I would like to share with you a new feature of Azure Security Center Threat Protection: Suppression rule

The goal of this new preview feature, released during Microsoft Build 2020 is to suppress false positives or other unwanted security alerts in Azure Security Center.

From the Azure Security Center Console, please click on « Security Alerts » and then click on « Suppression rules ».

In this second step, we will add a new rule. Please click on « Create new suppression rule »

Select your Azure Subscription – in this example: « Visual Studio Enterprise ». And then, select the security alert to hide – in this example: « Role binding to the cluster-admin role detected ».

Define a rule name, select enable for the state of this rule and select a reason.

In this last step, define a rule expiration date and click on the simulate button. To enable this new rule, please click on « Apply ».

As you can see here, our suppression rule is enabled.

When a single alert isn’t interesting or relevant, you can manually dismiss it. Alternatively, use the suppression rules feature to automatically dismiss similar alerts in the future. Typically, you’d use a suppression rule to:

  • suppress alerts that you’ve identified as false positives
  • suppress alerts that are being triggered too often to be useful

Be careful when you create a suppression rule, you loose visibility on potential security incident.

Maxime.