Catégorie : Kubernetes

ACR | Rôle & Autorisation

Hello,

Dans cet article nous allons voir ensembles les différents « Rôle/Autorisation » que nous pouvons mettre en place pour notre registry : Azure Container Registry.

Rôle/autorisationAccéder à Resource ManagerCréer/supprimer le RegistrePousser (push) l’imageExtraire (pull) l’imageSupprimer les données d’imageChanger de stratégiesSigner les images
PropriétaireXXXXXX
ContributeurXXXXXX
LecteurXX
AcrPushXX
AcrPullX
AcrDeleteX
AcrImageSignerX

Vous pouvez ainsi constater que le rôle « Lecteur » est permissif, un utilisateur avec ce rôle peut « pull » l’ensemble des images Docker présentes au sein de la registry …

Maxime.

AKS | Cluster Managed Identity

Hello,

Dans cet article, nous allons voir ensemble comment déployer un cluster AKS utilisant les identités managées (Managed Identity). Le service est encore en public preview au moment où j’écris cet article.

L’objectif d’utiliser des identités managées au sein d’un cluster AKS est de pouvoir s’affranchir des services principaux qui ont une date d’expiration. Ce qui peut poser de nombreux problèmes de sécurité sur des clusters AKS de productions, rotation, expiration, …

AKS crée deux identités managées :

  • Identité managée affectée par le système : identité utilisée par le fournisseur de cloud Kubernetes pour créer des ressources Azure au nom de l’utilisateur. Le cycle de vie de l’identité affectée par le système est lié à celui du cluster. L’identité est supprimée en même temps que le cluster.
  • Identité managée affectée par l’utilisateur : identité utilisée pour l’autorisation dans le cluster. Par exemple, l’identité affectée par l’utilisateur sert à autoriser AKS à utiliser des enregistrements de contrôle d’accès (ACR) ou à autoriser le kubelet à obtenir des métadonnées d’Azure.

Etape 1 : Depuis Azure Cloud Shell https://shell.azure.com, nous activons les fonctionnalités preview AKS avec la commande suivante:

az extension update --name aks-preview
az extension list

Etape 2 : Souscrire à la fonctionnalité MSI Preview

az feature register --name MSIPreview --namespace Microsoft.ContainerService

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

az provider register --namespace Microsoft.ContainerService

Etape 3 : Créer son cluster avec les identités managées

# Création d'un ressource group
az group create --name aksmsi --location canadacentral

# Création du cluster AKS
az aks create -g aksmsi -n AKSMSICluster --enable-managed-identity

# On obtient les information pour se connecter au cluster
az aks get-credentials --resource-group aksmsi --name AKSMSICluster

Quelques rappels:

  • Les clusters AKS avec des identités managées ne peuvent être activés que pendant la création du cluster.
  • Il est impossible de mettre à jour ou de mettre à niveau des clusters AKS existants pour activer des identités managées.

Dans un prochain article, nous verrons ensemble comment utiliser les identités managées aux niveaux des Pods de notre cluster.

Maxime.

Threat Protection pour Azure Kubernetes Service (AKS) avec Azure Security Center

Hello,

Il est désormais possible de bénéficier d’un système de détection des menaces pour vos clusters AKS depuis Azure Security Center. Cette nouvelle fonctionnalité est encore en preview au moment où j’écris cet article.

Cette fonctionnalité va vous permettre de renforcer vos postures de sécurité et ainsi détecter des menaces au sein de vos clusters AKS.

Dans l’exemple ci-dessous, nous pouvons voir que nous avons un container qui va s’exécuter avec des privilèges élevés dans le cluster. Ceci peut facilement être utilisé par un utilisateur malveillant afin récupérer un accès root sur le node qui exécute le container.

Alertes au niveau du cluster AKS

AlerteDescription
PRÉVERSION – Liaison de rôle au rôle d’administrateur de cluster détectéL’analyse du journal d’audit Kubernetes a détecté une nouvelle liaison au rôle d’administrateur de cluster aboutissant à des privilèges d’administrateur. Le fait de fournir inutilement des privilèges d’administrateur peut entraîner des problèmes d’escalade de privilèges dans le cluster.
PRÉVERSION – Tableau de bord Kubernetes exposé détectéL’analyse du journal d’audit Kubernetes a détecté une exposition du tableau de bord Kubernetes par un service LoadBalancer. Les tableaux de bord exposés permettent un accès non authentifié à la gestion des clusters et constituent une menace pour la sécurité.
PRÉVERSION – Nouveau rôle avec privilèges élevés détectéL’analyse du journal d’audit Kubernetes a détecté un nouveau rôle avec des privilèges élevés. Une liaison à un rôle avec des privilèges élevés donne à l’utilisateur/au groupe des privilèges élevés dans le cluster. Le fait de fournir inutilement des privilèges élevés peut entraîner des problèmes d’escalade de privilèges dans le cluster.
PRÉVERSION – Nouveau conteneur détecté dans l’espace de noms kube-systemL’analyse du journal d’audit Kubernetes a détecté un nouveau conteneur dans l’espace de noms kube-system qui ne fait pas partie des conteneurs qui s’exécutent normalement dans cet espace de noms. Les espaces de noms kube-system ne doivent pas contenir de ressources utilisateur. Les attaquants peuvent utiliser cet espace de noms pour masquer des composants malveillants.
PRÉVERSION – Conteneur d’extraction de données monétaires numériques détectéL’analyse du journal d’audit Kubernetes a détecté un conteneur qui a une image associée à un outil d’extraction de monnaies numériques.
PRÉVERSION – Conteneur privilégié détectéL’analyse du journal d’audit Kubernetes a détecté un nouveau conteneur privilégié. Un conteneur privilégié a accès aux ressources du nœud et rompt l’isolation entre les conteneurs. En cas de compromission, un attaquant peut utiliser le conteneur privilégié pour accéder au nœud.
PRÉVERSION – Conteneur avec un montage de volume sensible détectéL’analyse du journal d’audit Kubernetes a détecté un nouveau conteneur avec un montage de volume sensible. Le volume détecté est un type hostPath qui monte un fichier ou un dossier sensible depuis le nœud sur le conteneur. Si le conteneur est compromis, l’attaquant peut utiliser ce montage pour accéder au nœud.

Alertes au niveau de l’hôte

AlerteDescription
Conteneur privilégié détectéLes journaux de la machine indiquent qu’un conteneur Docker privilégié est en cours d’exécution. Un conteneur privilégié a un accès complet aux ressources de l’hôte. En cas de compromission, un attaquant peut utiliser le conteneur privilégié pour accéder à l’ordinateur hôte.
Exécution d’une commande privilégiée dans le conteneurLes journaux de la machine indiquent qu’une commande privilégiée a été exécutée dans un conteneur Docker. Une commande privilégiée a des privilèges étendus sur la machine hôte.
Démon Docker exposé détectéLes journaux de la machine indiquent que le démon Docker (dockerd) expose un socket TCP. Par défaut, la configuration Docker n’utilise pas le chiffrement ou l’authentification quand un socket TCP est activé. Toute personne ayant accès au port approprié peut alors obtenir un accès complet au démon Docker.
Le serveur SSH s’exécute à l’intérieur d’un conteneurLes journaux de la machine indiquent qu’un serveur SSH est en cours d’exécution dans un conteneur Docker. Bien que ce comportement puisse être intentionnel, il indique fréquemment qu’un conteneur est mal configuré ou a subi une violation.
Conteneur avec une image d’extracteur détectéLes journaux de la machine indiquent l’exécution d’un conteneur Docker exécutant une image associée à l’extraction de monnaies numériques. Ce comportement peut éventuellement indiquer que vos ressources font l’objet d’un abus.
Demande suspecte à l’API KubernetesLes journaux de la machine indiquent qu’une demande suspecte a été adressée à l’API Kubernetes. La demande a été envoyée à partir d’un nœud Kubernetes, éventuellement à partir de l’un des conteneurs en cours d’exécution dans le nœud. Bien que ce comportement puisse être intentionnel, il peut indiquer que le nœud exécute un conteneur compromis.
Demande suspecte au tableau de bord KubernetesLes journaux de la machine indiquent qu’une demande suspecte a été adressée au tableau de bord Kubernetes. La demande a été envoyée à partir d’un nœud Kubernetes, éventuellement à partir de l’un des conteneurs en cours d’exécution dans le nœud. Bien que ce comportement puisse être intentionnel, il peut indiquer que le nœud exécute un conteneur compromis.

Afin d’activer cette fonctionnalité au sein de Azure Security Center, je vous donne rendez-vous au sein du service. Puis je vous invite à sélectionner « Pricing & settings », ainsi que vous souscription Azure.

Sélectionner le plan « Standard » et cliquer sur « Enabled » pour le type de ressource: « Kubernetes Services (Preview) »

N’hésitez pas à me partager vos retours d’expérience dans les commentaires de cet article.

Maxime.