Catégorie : Azure

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.

ACR | Chiffrement avec une Customer Managed Key (CMK)!

[English version below]

Bonjour!

Dans cet article, j’ai le plaisir de vous présenter une nouvelle fonctionnalité portant sur le chiffrement de votre Azure Container Registry. Par défaut, lorsque que vous stockez des images dans votre registry de containers Azure, Microsoft chiffre automatiquement le contenu de la registry avec des clés générées par le service lui meme.

Il est désormais possible (en preview à l’heure où j’écris cet article) de rajouter une couche de chiffrement en utilisant une clé que vous générez et stockez dans Azure Key Vault. On parle alors de Customer Managed Key (CMK) – je ne connais pas de traduction française pour ce terme, si vous en avez une, n’hésitez pas à m’en faire part.

Dans un premier temps, nous allons créer ensemble un ressource group:

az group create --name acrcmk --location canadacentral

Puis créez une identité managée de type: user-assigned

az identity create --resource-group acrcmk --name acrcmk-msi

identityID=$(az identity show --resource-group acrcmk --name acrcmk-msi --query 'id' --output tsv)

identityPrincipalID=$(az identity show --resource-group acrcmk --name acrcmk-msi --query 'principalId' --output tsv)

Nous créons notre Azure Key Vault avec la politique d’accès:

az keyvault create --name keyvaultmaxime --resource-group acrcmk --enable-soft-delete --enable-purge-protection

az keyvault set-policy --resource-group acrcmk --name keyvaultmaxime --object-id $identityPrincipalID --key-permissions get unwrapKey wrapKey

Nous générons notre clé depuis cet Azure Key Vault:

az keyvault key create --name keyacr --vault-name keyvaultmaxime
keyID=$(az keyvault key show --name keyacr --vault-name keyvaultmaxime --query 'key.kid' --output tsv)

Enfin, nous créons notre Azure Container Registry avec cette customer-managed key.

az acr create --resource-group acrcmk --name acrcmkmax --identity $identityID --key-encryption-key $keyID --sku Premium

Nous pouvons constater que le chiffrement est désormais activé sur notre registry de containers:

az acr encryption show --name acrcmkmax

Créer des clés et appliquer du chiffrement est une bonne chose, mais réaliser des rotations de ses clés est encore mieux! Je vous recommande donc d’automatiser cette action, tous les 90 jours.

az keyvault key create --name keyacr2 --vault-name keyvaultmaxime

keyID=$(az keyvault key show --name keyacr2 --vault-name keyvaultmaxime --query 'key.kid' --output tsv)

az acr encryption rotate-key --name acrcmkmax --key-encryption-key $keyID --identity acrcmk-msi

Enfin, si vous souhaitez révoquer l’accès d’une clé existante

az keyvault delete-policy --resource-group acrcmk --name keyvaultmaxime --object-id $identityPrincipalID

Pour conclure, cette fonctionnalité nous permet de rajouter une couche de chiffrement pour notre registry de containers (ACR).

Maxime.


Hello,

In this article, I would like to share with you a new security feature of Azure Container Registry : ACR CMK

By default, when you store a container image in ACR, Microsoft applies this own encryption with encrypted generated by the Azure Platform and managed by Microsoft. The goal of this new feature is to allow the use of your own key for the ACR encryption : Customer Managed Key (or CMK).

Please create a ressource group:

az group create --name acrcmk --location canadacentral

Create then a user-assigned managed identity

az identity create --resource-group acrcmk --name acrcmk-msi

identityID=$(az identity show --resource-group acrcmk --name acrcmk-msi --query 'id' --output tsv)

identityPrincipalID=$(az identity show --resource-group acrcmk --name acrcmk-msi --query 'principalId' --output tsv)

Next, create a KeyVault with an access policy

az keyvault create --name keyvaultmaxime --resource-group acrcmk --enable-soft-delete --enable-purge-protection

az keyvault set-policy --resource-group acrcmk --name keyvaultmaxime --object-id $identityPrincipalID --key-permissions get unwrapKey wrapKey

Subsequently, generate a key from our Key Vault

az keyvault key create --name keyacr --vault-name keyvaultmaxime
keyID=$(az keyvault key show --name --vault-name --query 'key.kid' --output tsv)

Finally, create a new Azure Container Registry with CMK feature

az acr create --resource-group acrcmk --name acrcmkmax --identity $identityID --key-encryption-key $keyID --sku Premium

Now, we can check if the encryption is enabled

az acr encryption show --name acrcmkmax

A security best practice is to rotate security key every 90 days. To do so, I recommend you to automate this process.

az keyvault key create --name keyacr2 --vault-name keyvaultmaxime

keyID=$(az keyvault key show --name keyacr2 --vault-name keyvaultmaxime --query 'key.kid' --output tsv)

az acr encryption rotate-key --name acrcmkmax --key-encryption-key $keyID --identity acrcmk-msi

And if you want to revoke the access of an existing key, please use this command

az keyvault delete-policy --resource-group acrcmk --name keyvaultmaxime --object-id $identityPrincipalID

In conclusion, this new security feature adds a new security layer on the top of AKS, and allows you to manage your own key for the encryption of your container images.

Maxime.