La gestion sécurisée des secrets dans AKS

Overview

Gérer les secrets de manière sécurisée est essentiel pour les organisations utilisant des applications cloud-native.
Dans cet article, nous intégrons Azure Key Vault avec AKS pour assurer une bonne gestion de secrets à travers terraform.
Vous pouvez trouver le lien du dépôt GitHub : aks-keyvault

Prérequis

• Azure subscription
• AZ CLI
• Terraform

Vous pouvez faire un clone du repos et exécuter les scripts de terraform pour faire le provisionnement de l’infrastructure.

Low Level Design

Examinons de plus près les composants clés :
Réseaux Virtuels (VNets) :
Nous avons deux VNets différents dans notre configuration :

• Un pour AKS (où se trouve notre cluster Kubernetes).
• Un pour Key Vault (où tous nos secrets sont stockés).

Ces VNets sont interconnectés, ce qui signifie qu'ils peuvent communiquer en toute sécurité entre eux via le réseau privé d'Azure.
Deux éléments clés pour faciliter et rendre la communication possible :

1. Peering : Le peering entre le VNet AKS et le VNet Key Vault permet une communication directe et fluide. Cela signifie que les ressources des deux VNets peuvent interagir sans passer par Internet, assurant ainsi une latence réduite et une meilleure performance.
2. Private Endpoint : Un Private Endpoint a été créé pour Azure Key Vault. Ce dernier joue un rôle crucial en permettant un accès sécurisé au Key Vault via une adresse IP privée appartenant au même VNET. Cela garantit que les requêtes envoyées depuis le VNet AKS vers le Key Vault restent à l'intérieur du réseau backbone Azure, protégeant ainsi les données sensibles des menaces externes. De plus, les pods/applications dans le VNet AKS peuvent utiliser des identités gérées pour s'authentifier ce qui va simplifier ainsi la gestion des accès.

À l'intérieur du VNet AKS :
Dans ce réseau, nous avons déployé notre cluster Kubernetes.
Supposant maintenant que votre pod est votre application qui a besoin d’un certain secret.
Chaque pod fonctionne à l'aide d'un service account ( SA ) . Ce SA est important car il détermine qui (ou quoi) a la permission d'accéder à des ressources comme les secrets appartenant à Azure Key Vault.

Nous utilisons par la suite le pilote Secret Store CSI pour permettre à notre application de récupérer des secrets depuis Key Vault et de les monter en tant que volumes dans les pods. Ainsi. Cela permet à l’application d’utiliser ces secrets comme des fichiers ordinaires, voire comme des variables d’environnement.

Comment les Pods Accèdent-ils aux Secrets ?

Voici où la sécurité entre en jeu :
Chaque SA est lié à une Identité Managée Assignée à l'Utilisateur (UAMI), qui est comme une « carte d'identité spéciale » attribuée par Azure à nos pods.
Cette identité est reconnue par Azure Key Vault et accorde au pod l'accès aux secrets en fonction de ses autorisations définies dans l’UAMI.

Intégration de l'Identité Fédérée et de l'UAMI dans AKS et Azure Key Vault

Pour sécuriser l'accès aux services Azure via AKS il est essentiel de comprendre l'identité fédérée et l'identité managée assignée à l'utilisateur (UAMI). Voici un résumé de ces concepts et de leur rôle dans la sécurité des applications.

Qu'est-ce qu'une Managed Identity ?

Une Managed Identity permet aux applications de s'authentifier auprès d'autres services Azure sans gérer directement les identifiants. Il existe deux types :

• System-Assigned Managed Identity : Créée automatiquement pour une ressource spécifique et supprimée avec celle-ci.
• User-Assigned Managed Identity (UAMI) : Créée indépendamment et pouvant être partagée entre plusieurs ressources, offrant plus de flexibilité.

Pourquoi Utiliser l'UAMI ?
L'UAMI simplifie l'accès à des ressources Azure pour plusieurs applications, permettant une gestion centralisée des autorisations et évitant d'insérer des informations sensibles dans le code.

Qu'est-ce que l'Identité Fédérée ?
L'identité fédérée établit une relation de confiance entre les workloads AKS et Azure Active Directory, permettant une authentification sécurisée avec des services Azure.

Rôle de l'Identité Fédérée

• Établissement de la Confiance : Permet aux pods d'accéder aux services Azure hard coder les identifiants.
• Authentification Simplifiée : Le compte de service AKS peut utiliser l'UAMI pour accéder aux ressources Azure.
• Sécurité Renforcée : Évite le stockage d'informations sensibles dans le cluster, protégeant ainsi les applications.

Dans la configuration ci-dessous de Terraform, nous avons créé un secret sur Azure Key Vault nommé MYSQL-DB-PASSWORDD qu’on va essayer de le récupérer plus tard dans le pod sur AKS. Puis nous avons créé une UAMI pour permettre à notre cluster AKS d'accéder à Azure Key Vault. Une attribution de rôle lui accorde des permissions, et une identité fédérée lie le compte de service AKS à l'UAMI facilitant l'authentification sécurisée sans intégrer d'identifiants sensibles.

Cette approche utilise RBAC (Role-Based Access Control) pour définir les permissions d'accès au Key Vault. Grâce à RBAC, nous pouvons attribuer des rôles spécifiques aux utilisateurs et aux services, assurant ainsi un contrôle d'accès granulaire et une meilleure sécurité des ressources. Cela facilite la gestion des accès au fil du temps, en alignant les permissions sur les rôles et les responsabilités des services, plutôt que de gérer des accès individuels par le biais de politiques d'accès qui va être  bientôt déprécier.
Ce code terraform résume les concepts racontés :

Dans cet exemple, le rôle Key Vault Administrator a été attribué à notre UAMI, mais il est possible de le remplacer par le rôle Key Vault Reader pour une approche plus restrictive.

Et assurez-vous de spécifier le bon nom du compte de service et du namespace qui seront créés.

Avant de créer notre SA, obtenez le clientId en utilisant la commande suivante et assurez-vous de le remplacer dans sa.yml à l'intérieur de azure.workload.identity/client-id: "" : 

Obtenez par la suite le tenantId et remplacez le dans secretprovider.yml

Assurez-vous d'utiliser le bon objectName, qui est MYSQL-DB-PASSWORDD, car nous l'avons déjà créé avec Terraform. Vous pouvez également référencer autant de secrets que nécessaire.

Voici un exemple de configuration pour référencer le secret dans votre fichier YAML :

Types d'ObjectType

L'attribut objectType peut principalement avoir trois valeurs possibles :

• secret : Représente des informations sensibles, telles que des mots de passe, des clés API ou des tokens, qui doivent rester confidentielles.
• key : Se réfère généralement à des clés cryptographiques utilisées pour chiffrer ou signer des données.
• cert : Désigne des certificats, utilisés pour authentifier des identités sur les réseaux (comme les certificats SSL/TLS).

Création d'un Pod pour Accéder aux Secrets Montés depuis Azure Key Vault

Maintenant que nous avons configuré notre SecretProviderClass et l'avons lié à Azure Key Vault, il est temps de créer un pod qui utilisera les secrets stockés dans Key Vault. C'est ici que la magie opère, car nous pouvons tirer parti de notre Service Account pour accéder en toute sécurité à ces secrets.

Configuration du Pod
Voici la configuration pour notre pod :
kubectl apply -f pod-poc-vault.yaml

Et enfin nous pouvons voir notre très fort mot de passe 😉:

Vous avez réussi à créer un cluster AKS, à configurer des réseaux virtuels et à intégrer Azure Key Vault pour une gestion sécurisée des secrets. Vos applications peuvent désormais accéder en toute sécurité aux secrets grâce au pilote Secret Store CSI, rendant votre déploiement Kubernetes plus sûr et plus efficace.

Sofiene GHARBI
Consultant Ingénieur Cyber