1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨

2. PROBLÉMATIQUE

Architecture Kubernetes dans Azure

• Le control plane, hébergé et managé par Microsoft (en PaaS)
• Les worker nodes (nœuds de travail) sont provisionnés dans votre propre souscription

Cela crée plusieurs enjeux :

• Comment sécuriser l’accès à l’API Server ?
• Comment centraliser les utilisateurs et les rôles ?
• Comment se passer de secrets dans les fichiers YAML ?
• Comment industrialiser la rotation des credentials ?

💡 Kubernetes dispose déjà de RBAC et d’authentification, mais ces mécanismes deviennent vite difficiles à maintenir à grande échelle.

➡️ La solution : Azure Entra ID + Managed Identity + Workload Identity.

3. IAM POUR LE CONTROL PLANE

🔹 Azure Entra ID comme fournisseur d’identité

AKS permet d’utiliser Azure Entra ID (anciennement Azure AD) comme Identity Provider pour gérer l’authentification sur l’API Server

Intégration native

• S’appuie sur les extensions d’authentification de Kubernetes
• Permet de réutiliser les comptes et groupes existants dans Azure
• Se configure lors de la création du cluster avec --enable-azure-rbac (et --enable-managed-identity)

Avantages majeurs :

• SSO pour les utilisateurs connectés à Microsoft 365
• Compatible avec les politiques MFA d’Entra ID (si configurées)
• Conditional Access pour affiner les règles (ex : appareil compliant, IP de confiance)
• Privileged Identity Management (PIM) pour une élévation temporaire des droits

💡 Attention :

• Les fonctionnalités avancées nécessitent une licence Entra ID P1 ou P2
• La propagation d’un droit PIM peut prendre quelques minutes
• Le compte admin local (--enable-local-accounts false) doit être désactivé pour forcer l’usage d’Entra ID
• et si vous passer par terraform , voici un Extrait du code :

resource "azurerm_kubernetes_cluster" "example" {
  ...
  azure_active_directory_role_based_access_control {
    azure_rbac_enabled     = true
    managed                = true
  }

  local_account_disabled   = true
}

Propagation des privilèges :

• Les élévations de privilèges nécessitent quelques minutes de propagation, ce qui peut être un point à surveiller en cas d’urgence

4. AZURE ENTRA ID RBAC POUR AKS

Rôles intégrés à Azure RBAC

AKS propose des rôles Azure RBAC spécifiques à AKS, appliqués au niveau de l’API Kubernetes (via Azure Entra ID), distincts du RBAC Kubernetes natif

Exemples de rôles

• Cluster Admin
  • Contrôle total du cluster
• Cluster Reader
  • Lecture seule (hors secrets)

Mise en œuvre

• Créer des groupes Azure AD pour gérer ces rôles (par exemple, groupes distincts pour les environnements de Dev et de Prod).
• Centraliser la gestion des permissions en attribuant ces rôles aux groupes appropriés.

Sécuriser l’accès

• Désactiver les comptes locaux :
  • Désactiver les comptes locaux pour éviter les accès hors Entra ID
  • Par exemple, pour empêcher tout accès non contrôlé pouvant contourner l’authentification via Azure Entra ID

Attribution granulaire des accès

• Mapper les groupes Azure AD sur les namespaces Kubernetes :
  • Permet de contrôler précisément les accès selon les environnements ou projets

Gestion centralisée

• Centraliser la gestion des accès :
  • Facilite l’audit et la maintenance en regroupant la gestion des autorisations via Azure Entra ID

5. QUI DOIT ACCÉDER A L’API SERVER ?

🔹 Définir les groupes d’accès Azure AD

Organiser les accès à travers plusieurs groupes AD permet de segmenter les responsabilités et de mieux tracer les actions.

Voici quelques typologies de groupes utiles :

Ces groupes peuvent être définis :

• par environnement (Dev, Préprod, Prod)
• par cluster
• ou par équipe fonctionnelle

🔹 Composition des groupes

Les groupes Azure AD peuvent inclure plusieurs types d’identités :

• Utilisateurs (dévs, admins, observateurs)
• Service Principals (Terraform, pipelines)
• Managed Identities (composants AKS, pods)
• Applications (ex. Azure DevOps)

📌 Chaque type doit avoir des permissions claires et traçables.

6. IAM AU NIVEAU NAMESPACE

Une bonne pratique est de mapper les groupes Azure AD sur des namespaces Kubernetes.
Cela te permet de :

• RBAC plus fin avec Role et RoleBinding
• Isolation par projet ou équipe
• Meilleure gouvernance des accès

Exemple YAML :

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: devops-access
  namespace: dev
subjects:
- kind: Group
  name: aks-devops-dev
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: devops-role
  apiGroup: rbac.authorization.k8s.io

🔐 Et surtout :

Désactive le compte admin local par défaut, qui contourne Azure Entra ID

7. MANAGED IDENTITIES POUR AKS

🔹 Pourquoi les utiliser ?

• 🟢 Authentification sécurisée
• 🟢 Pas de secrets dans les fichiers
• 🟢 Rotation automatique

🔹 Deux types d’identités :

Recommandation : utilise user-assigned pour :

• Meilleure gouvernance
• Nom clair
• Réutilisation cross-environnements (ex : blue/green)

🔹 Permissions requises pour les Managed Identities

1. Identité du Cluster pour l’Interaction avec Azure

• Chaque cluster (control plane) nécessite une identité dédiée pour interagir avec les ressources Azure.
• Pré-requis : Créer l’identité (system-assigned ou user-assigned) avant la création du cluster.

2. Rôle et Assignations Spécifiques

• Rôles dédiés sur le groupe de ressources managé par AKS (ex. resource group du cluster).
• Permissions requises pour différentes actions :
  • Networking : exécuter l’action join sur les subnets (Microsoft.Network/virtualNetworks/subnets/join/action).
  • Load Balancer : gestion des pools back-end et des IP publiques.
  • Stockage : création et gestion de disques, file shares, etc.
  • Autres ressources : actions sur les interfaces réseau, VM, snapshots, etc.

3. Sécurité et Gestion Automatique

• Rotation automatique des credentials (tous les 45 jours) pour limiter les risques liés aux secrets.
• Amélioration de la posture de sécurité par rapport à l’utilisation de service principals (ID et secret fixes).

4. Cas d’Usage et Scénarios Détaillés

• Stratégie fine : Assigner des rôles sur des scopes précis afin de limiter l’accès aux seules ressources nécessaires.

• Déploiement d’applications : Nécessité de permissions adaptées pour les pods interagissant avec Azure (via Key Vault, par exemple).

• Scénarios avancés : Intégration de nouvelles fonctionnalités (Azure Backup, snapshots, etc.) nécessitant des permissions additionnelles.

🔹 Chaque composant AKS dispose de sa propre identité

Différentes identités dans le cluster

• Control Plane vs. Worker Plane :
  • Le control plane utilise une identité dédiée pour interagir avec Azure (via Managed Identity).
  • Le worker plane utilise également des identités pour des tâches spécifiques (ex. pull d’images depuis ACR).

🔹 Par composant :

📌 Chaque composant doit avoir le moins de droits possibles (principe du moindre privilège).

Points clés à retenir

• Chaque composant peut disposer de sa propre identité pour limiter les privilèges aux seules actions nécessaires.
• L’utilisation de user-assigned identities est recommandée pour garantir un contrôle précis et une cohérence lors des mises à jour ou migrations.
• Certains composants ne supportent que l’identité système, tandis que d’autres offrent la flexibilité du choix.

8. GESTION DES SECRETS

🔹 Workload Identity

1. Objectif

• Permet aux pods d’accéder aux ressources Azure en se présentant via une identité centralisée d’Azure AD (OIDC), sans stocker de credentials dans les fichiers de configuration.

2. Avantages

• Passwordless : Authentification sans mot de passe ni rotation manuelle de secrets.
• Standardisé et sécurisé : Utilisation d’un protocole OIDC conforme aux standards de sécurité.
• Centralisation : Remplace la gestion locale des service accounts par une gestion unifiée dans Azure AD, facilitant la maintenance et la sécurité.
• Interopérabilité : Compatible avec des environnements hybrides (cloud et on-premise) et permet d’intégrer des fournisseurs d’identité alternatifs si nécessaire (ex. pour des partenaires ou des cas spécifiques).

3. Points Clés

• Chaque pod utilise un ServiceAccount mappé à une federated credential dans Entra ID.
• Réduit la nécessité de gérer manuellement des secrets et simplifie l’architecture d’authentification pour les applications déployées sur Kubernetes.

🔹 CSI Driver avec Key Vault

1. Objectif

• Externaliser la gestion des secrets en évitant leur stockage non sécurisé dans ETCD (seulement encodés en Base64).
• Stocker et gérer les secrets dans Azure Key Vault.

2. Fonctionnement

• Utilisation d’une Custom Resource Definition (CRD) :
  • Création d’objets SecretProviderClass pour configurer la connexion avec Key Vault.
• Secrets montés comme volume dans le pod (/mnt/secrets)
• Synchronisation possible vers objets Kubernetes Secret

3. Avantages

• Synchronisation :
  • Possibilité de synchroniser aussi vers des objets secrets Kubernetes si nécessaire.
  • Synchronisation en temps réel possible, si l’application est capable de recharger dynamiquement le fichier
• Sécurité Renforcée :
  • Limite l’exposition des secrets et permet une gestion centralisée et sécurisée via Azure Key Vault

🔹 Key Management Service (KMS) et chiffrement ETCD

1. Contexte et Objectif

• Par défaut, les secrets dans ETCD sont seulement encodés en Base64, sans chiffrement réel.
• L’intégration avec Azure KMS permet un chiffrement réel, avec des clés stockées dans Azure Key Vault.

2. Fonctionnalités et Avantages

• Chiffrement des données ETCD :
  • Utilisation de clés (avec rotation automatique) pour protéger les secrets.
• Rotation automatique des clés :
  • Permet une mise à jour régulière des clés sans intervention manuelle, réduisant ainsi les risques de compromission.

3. Limitations et Considérations

• ❌Incompatibilité avec AKS Start/Stop :
  • La fonctionnalité ne fonctionne pas si le cluster est arrêté et redémarré, ce qui peut impacter les environnements Dev visant à économiser des coûts.
• ❌Restrictions sur les Key Vault filtrés par le réseau :
  • Les Key Vault nécessitant un filtrage réseau ne sont pas supportés par cette intégration.

PROCHAIN ARTICLE

👉 Dans le prochain article, on change de couche pour aborder un sujet tout aussi stratégique : la gestion du Compute

Au programme :

• Choix d’architecture pour les nœuds et pools (System vs User)
• Sizing des clusters : quelle taille pour quelle charge ?
• Optimisation des coûts : autoscaling, burst, spot nodes
• Gestion du waste : comment éviter le surprovisionnement

📎 Pour aller plus loin (docs Microsoft) :

• Configure Azure AD integration with AKS
• Use Azure RBAC for Kubernetes Authorization
• Create and manage Azure AD groups
• Use Kubernetes RBAC with Azure AD groups
• Use managed identities in AKS
• Use Azure Key Vault secrets in AKS with CSI driver
• Encrypt Kubernetes secrets with KMS in AKS

🙏 Remerciements

Cet article prolonge des échanges issus de plusieurs workshops conduits par Benoît Sautierre, dont la vision et l’animation ont largement nourri les réflexions présentées ici. Expert engagé et passionné, il a su créer un cadre de réflexion stimulant, pour lequel je lui adresse mes plus vifs remerciements.