Durcissement de la sécurité du Horizontal Pod Autoscaler Kubernetes : exemples pratiques et pièges à éviter

Introduction

La sécurisation du Horizontal Pod Autoscaler (HPA) Kubernetes est souvent négligée, car il semble être un composant purement opérationnel. Pourtant, un HPA mal configuré peut exposer des métriques, fuiter des secrets via sa configuration ou permettre une élévation de privilèges par des règles RBAC trop larges. Ce guide présente des étapes pratiques de durcissement, avec des commandes, les sorties attendues et les chemins de récupération. Il s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui doivent passer de l'observation d'un problème à un état vérifié et sécurisé.

Chaque recommandation est versionnée, observable et réversible lorsque Kubernetes le permet. Nous commencerons par l'inventaire de l'environnement, puis configurerons le HPA de manière sécurisée, vérifierons son comportement, nous préparerons aux défaillances et terminerons par une liste de contrôle opérationnelle et les pièges courants.

Inventaire des versions et de l'environnement

Avant de modifier quoi que ce soit, sachez ce que vous avez. Déterminez la version de Kubernetes et la version de l'API HPA utilisée. Le HPA a évolué à travers les versions d'API : autoscaling/v1 ne prend en charge que les métriques CPU, tandis que autoscaling/v2 et v2beta2 prennent en charge les métriques custom et externes. Connaître la version évite les erreurs de manifeste incompatibles.

Tout d'abord, vérifiez la version du cluster :

kubectl version --short

La sortie ressemble à :

Client Version: v1.28.2
Server Version: v1.28.2

Listez les ressources d'API disponibles pour l'autoscaling :

kubectl api-versions | grep autoscaling

Vous devriez voir des lignes comme :

autoscaling/v1
autoscaling/v2
autoscaling/v2beta2

Si seulement v1 est listée, vous ne pouvez pas utiliser de métriques mémoire ou personnalisées dans les manifestes HPA sans mise à niveau ou activation de feature gates.

Ensuite, inspectez les objets HPA existants dans tous les namespaces :

kubectl get hpa --all-namespaces

Exemple de sortie :

NAMESPACE     NAME       REFERENCE             TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
default       web-hpa    Deployment/web        50%/80%         2         10        3          5d

Lisez l'état actuel d'un HPA sans le modifier :

kubectl describe hpa web-hpa -n default

Recherchez la section Metrics: pour voir quelles métriques sont utilisées. Si elle liste quelque chose comme resource cpu on pods, vous utilisez la mise à l'échelle CPU uniquement de style v1. Si vous voyez resource memory ou une external metric, la v2 est active.

Vérifiez également que le pod du contrôleur HPA est en cours d'exécution dans kube-system :

kubectl get pods -n kube-system | grep hpa

Sortie typique :

kube-controller-manager-...   1/1     Running   0          10d

Si le contrôleur manager n'est pas en cours d'exécution, les décisions du HPA ne seront pas appliquées. Consultez ses journaux :

kubectl logs -n kube-system kube-controller-manager-<pod-name> | grep -i hpa

Enregistrez toutes les sorties avec des horodatages pour une comparaison ultérieure. Ne stockez jamais de secrets en texte brut ; utilisez un système de notes sécurisé ou un gestionnaire de secrets spécifique à l'environnement.

Chemin de configuration sécurisé

Une fois l'inventaire réalisé, durcissez le HPA lui-même. La surface d'attaque principale est les permissions RBAC et la source des métriques. Une approche de moindre privilège signifie que le contrôleur HPA ne doit avoir que les permissions nécessaires pour mettre à l'échelle les ressources, et le HPA de votre application ne doit référencer que les métriques autorisées.

RBAC pour le contrôleur HPA

Par défaut, le kube-controller-manager utilise un compte de service privilégié. Dans les clusters managés (EKS, GKE, AKS), cela est abstrait, mais dans les clusters auto-gérés, vérifiez ses liaisons de rôles. Listez les ClusterRoleBindings pour le controller manager :

kubectl get clusterrolebinding -o wide | grep system:controller

Recherchez system:controller:horizontal-pod-autoscaler. S'il est lié à un compte de service personnalisé, inspectez ses permissions :

kubectl describe clusterrole system:controller:horizontal-pod-autoscaler

Le rôle doit autoriser get, list, watch sur les pods, replicationcontrollers et deployments, et update sur replicationcontrollers/scale et deployments/scale. S'il accorde des permissions plus larges comme sur , resserrez-les immédiatement avec un rôle personnalisé.

Exemple de rôle personnalisé (hpa-controller-role.yaml) :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: restricted-hpa-controller
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments/scale"]
  verbs: ["get", "update"]
- apiGroups: [""]
  resources: ["replicationcontrollers/scale"]
  verbs: ["get", "update"]

Appliquez-le et liez-le au compte de service du contrôleur. Dans les clusters auto-gérés, vous devrez peut-être modifier le manifeste du controller manager ; dans les clusters managés, utilisez les rôles IAM du fournisseur cloud si possible.

Durcissement du manifeste HPA

Votre manifeste HPA doit éviter de référencer des serveurs de métriques externes qui pourraient être compromis. Si vous utilisez des métriques personnalisées, assurez-vous que l'adaptateur de métriques dispose d'une authentification et de TLS. Un manifeste HPA sécurisé typique pour la v2 avec CPU et mémoire ressemble à :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 500Mi

N'incorporez pas de secrets directement dans les manifestes HPA. Si vous utilisez des métriques externes nécessitant une authentification, référencez un objet Secret plutôt que de coder en dur des jetons. Par exemple, si votre fournisseur de métriques personnalisées a besoin d'une clé API, stockez-la dans un Secret et configurez l'adaptateur pour la lire à partir de là, et non à partir du manifeste HPA.

Séquence d'implémentation

Testez toujours d'abord dans un namespace non productif. Créez un déploiement fictif et un HPA, puis vérifiez le comportement de mise à l'échelle avec un petit test de charge. Exemple :

kubectl create namespace hpa-test
kubectl apply -f web-deployment.yaml -n hpa-test
kubectl apply -f web-hpa.yaml -n hpa-test

Vérifiez le statut du HPA :

kubectl get hpa -n hpa-test -w

Observez les réplicas changer lorsque vous générez de la charge. Si vous voyez des erreurs comme unable to get metrics, vérifiez la disponibilité du serveur de métriques :

kubectl get --raw /apis/metrics.k8s.io/v1beta1

Une réponse réussie renvoie du JSON avec les métriques. Si elle expire, le serveur de métriques n'est pas installé ou n'est pas joignable.

Une fois vérifié, passez en production avec un déploiement progressif.

Vérification et diagnostic

Après avoir appliqué les modifications de durcissement, vérifiez que le HPA se comporte comme prévu et qu'aucune régression de sécurité ne se produit.

Vérifier le statut et les événements du HPA

kubectl describe hpa web-hpa -n default

Recherchez les Events en bas. Les événements de mise à l'échelle réussis ressemblent à :

Normal  SuccessfulRescale  5m   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target

Si vous voyez des avertissements comme FailedGetResourceMetric ou unable to fetch metrics, enquêtez sur le pipeline de métriques.

Tester les restrictions RBAC

Créez un compte de service temporaire avec les permissions exactes que vous destinez à un utilisateur qui ne devrait lire que les objets HPA. Ensuite, tentez de mettre à l'échelle un déploiement en utilisant cette identité.

kubectl auth can-i update deployments/scale --as=system:serviceaccount:default:readonly-user -n default

Sortie attendue :

no

Si cela renvoie yes, votre RBAC est trop permissif. Révisez les liaisons de rôles.

Diagnostiquer la collecte de métriques

Si vous utilisez le serveur de métriques Kubernetes, assurez-vous que son pod est en cours d'exécution :

kubectl get pods -n kube-system | grep metrics-server

Consultez ses journaux :

kubectl logs -n kube-system metrics-server-<pod>

Les problèmes courants incluent des problèmes de certificat TLS lors de l'utilisation de certificats auto-signés. Dans ce cas, configurez le serveur de métriques avec --kubelet-insecure-tls uniquement pour la non-production ; en production, utilisez des certificats appropriés.

Vérifier que les secrets ne sont pas exposés

Si votre HPA référence un Secret indirectement (par exemple, pour des métriques externes), confirmez que l'objet HPA ne révèle pas la valeur du secret :

kubectl get hpa web-hpa -o yaml | grep -i secret

La sortie doit montrer une référence comme secretKeyRef avec un nom et une clé, pas le contenu réel du secret. Si vous voyez les données du secret dans le manifeste, supprimez-les et utilisez un objet Secret.

Modes de défaillance et récupération

Même avec une configuration soignée, des échecs surviennent. Être préparé avec des étapes de récupération minimise les temps d'arrêt et l'exposition de sécurité.

Modes de défaillance courants

1. Serveur de métriques indisponible : le HPA ne peut pas obtenir de métriques, il arrête donc de mettre à l'échelle. Symptômes : kubectl get hpa affiche unknown dans la colonne TARGETS, et les événements montrent unable to fetch metrics. Récupération : installez ou redémarrez le serveur de métriques, vérifiez les politiques réseau qui pourraient bloquer l'accès du controller manager à l'API de métriques.

1. RBAC trop restrictif : après avoir resserré les permissions, le contrôleur HPA peut perdre la capacité de mettre à jour les échelles, provoquant des échecs de mise à l'échelle avec des erreurs forbidden. Récupération : utilisez kubectl auth can-i pour tester les permissions, ajustez le ClusterRole progressivement et annulez si nécessaire.

1. Métriques mal configurées : si le HPA utilise une métrique personnalisée qui n'est rapportée par aucun pod, les réplicas actuels peuvent être réduits au minimum ou augmentés au maximum de manière imprévisible. Récupération : vérifiez les valeurs de métriques avec kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/... et vérifiez les labels des pods. Supprimez la métrique mal configurée du HPA jusqu'à ce que le fournisseur de métriques soit corrigé.

1. Fuite de secrets dans les manifestes : commettre accidentellement un manifeste avec un jeton codé en dur l'expose dans le contrôle de version. Récupération : faites pivoter le secret immédiatement, révoquez le jeton et remplacez le manifeste par une référence Secret. Analysez vos dépôts pour des fuites similaires.

Vérification de la récupération

Après toute récupération, confirmez que le cluster est stable :

kubectl get hpa --all-namespaces
kubectl get events --sort-by='.metadata.creationTimestamp' | tail -20

Vérifiez que le pod du contrôleur HPA est en cours d'exécution et qu'aucun état CrashLoopBackOff n'existe. Exécutez à nouveau un test de charge pour voir la mise à l'échelle reprendre.

Liste de contrôle opérationnelle

Utilisez cette liste avant et après les modifications de sécurité du HPA pour éviter les oublis.

• [ ] Confirmer la version Kubernetes et la version d'API HPA prise en charge (kubectl version, kubectl api-versions).
• [ ] Inventorier tous les objets HPA et leurs métriques (kubectl get hpa --all-namespaces -o yaml).
• [ ] Examiner le RBAC du contrôleur HPA et de tous les comptes de service utilisés par les adaptateurs de métriques (kubectl describe clusterrole ...).
• [ ] S'assurer que les manifestes HPA ne contiennent pas de secrets ; utiliser des références Secret.
• [ ] Vérifier que le serveur de métriques est en cours d'exécution et joignable depuis le contrôleur (kubectl get pods -n kube-system | grep metrics-server, kubectl get --raw /apis/metrics.k8s.io/v1beta1).
• [ ] Tester l'accès au moindre privilège avec kubectl auth can-i --as=<test-account>.
• [ ] Appliquer les modifications d'abord dans un namespace de test et surveiller les événements de mise à l'échelle.
• [ ] Enregistrer les commandes et sorties exactes avant et après les modifications pour audit.
• [ ] Définir la procédure de rollback : sauvegarder les manifestes HPA et RBAC précédents dans le contrôle de version.
• [ ] Après le déploiement en production, vérifier que la mise à l'échelle fonctionne sous charge.
• [ ] Planifier une revue mensuelle de la posture de sécurité du HPA, y compris la dérive RBAC et l'intégrité de la source de métriques.

Pièges courants et comment les éviter

Plusieurs erreurs récurrentes compromettent la sécurité du HPA. Voici les plus courantes et comment les prévenir ou les récupérer.

Piège 1 : Utiliser des jokers dans le RBAC pour le HPA

Pourquoi cela arrive : les développeurs veulent des octrois de permissions rapides et utilisent verbs: [""] ou resources: [""] pour éviter de déboguer les erreurs de permission.

Comment l'éviter : définissez toujours des verbes et des ressources spécifiques. Utilisez kubectl auth can-i --list pour voir ce qu'un rôle accorde réellement, puis réduisez. Testez avec une simulation de la charge de travail.

Récupération : auditez les ClusterRoles et Roles existants pour les jokers liés à l'autoscaling. Remplacez-les par des règles explicites.

Piège 2 : Coder en dur les points de terminaison du serveur de métriques sans TLS

Pourquoi cela arrive : dans les clusters de développement, TLS est souvent ignoré par commodité, et la configuration est ensuite copiée en production.

Comment l'éviter : imposez TLS dès le départ. Pour le serveur de métriques, utilisez des certificats signés. Pour les adaptateurs de métriques personnalisées, exigez l'authentification et le chiffrement.

Récupération : mettez à jour le déploiement du serveur de métriques pour utiliser TLS, faites pivoter les clés exposées et testez la connectivité.

Piège 3 : Ignorer les événements et journaux du HPA

Pourquoi cela arrive : les équipes ne regardent le HPA que lorsque la mise à l'échelle cesse de fonctionner ; elles ne surveillent pas les événements pertinents pour la sécurité comme les refus de permission.

Comment l'éviter : configurez des alertes sur les événements liés au HPA dans le namespace. Utilisez des outils comme kubewatch ou des alertes Prometheus sur les métriques kube_hpa_status_condition.

Récupération : lorsqu'une alerte se déclenche, vérifiez immédiatement kubectl describe hpa et les journaux du contrôleur pour diagnostiquer. Documentez la correction.

Piège 4 : Autoriser le HPA à mettre à l'échelle sur la base de métriques non fiables

Pourquoi cela arrive : les métriques personnalisées peuvent provenir de points de terminaison contrôlés par l'utilisateur ; si ces points sont compromis, un attaquant peut forcer une mise à l'échelle massive, provoquant un déni de service ou un épuisement des ressources.

Comment l'éviter : validez les sources de métriques, limitez les métriques qu'un HPA peut utiliser via des politiques d'admission, et définissez maxReplicas à une limite supérieure raisonnable. Un pic soudain vers maxReplicas doit déclencher une alerte.

Récupération : supprimez temporairement le HPA ou définissez minReplicas et maxReplicas à une plage sûre. Enquêtez sur la source de métriques.

Piège 5 : Ne pas versionner les manifestes HPA et RBAC

Pourquoi cela arrive : les modifications sont effectuées ad hoc avec kubectl edit et perdues.

Comment l'éviter : stockez toutes les définitions HPA et RBAC dans Git. Utilisez des outils GitOps comme Argo CD ou Flux pour les gérer. Chaque modification est examinée.

Récupération : si une modification manuelle casse quelque chose, revenez au dernier manifeste connu bon depuis Git et redéployez.

Conclusion

Le durcissement du Horizontal Pod Autoscaler Kubernetes exige des étapes délibérées : connaître votre environnement, restreindre les permissions, valider la configuration, surveiller les défaillances et imposer une discipline opérationnelle. Chaque recommandation de ce guide est concrète et testable ; les commandes fournies vous montreront l'état actuel et vous aideront à vérifier que vos mesures de sécurité fonctionnent.

Commencez par une vérification à faible risque, comme la vérification des permissions RBAC avec kubectl auth can-i, et enregistrez le résultat. Passez ensuite à la sécurisation de vos manifestes HPA et à la surveillance des événements. En rendant les échecs visibles et en protégeant les valeurs sensibles, vous garantissez que votre autoscaling reste à la fois fonctionnel et sécurisé. Revisitez ces pratiques mensuellement, ou chaque fois que vous changez de version Kubernetes ou de fournisseur de métriques, pour garder votre cluster résilient face aux menaces évolutives.