L’article explique comment sécuriser les secrets Kubernetes en utilisant OVHcloud Secret Manager (un service managé compatible HashiCorp Vault KV v2) couplé à External Secrets Operator (ESO), une solution automatisée pour synchroniser les secrets entre le gestionnaire externe et le cluster. L’auteur souligne les avantages de cette approche, notamment la simplicité de déploiement et la réduction des coûts (environ 0,03 € par secret/mois), tout en évitant les pratiques risquées comme le stockage direct dans Git ou les Secrets Kubernetes non protégés.
Le tutoriel détaille les étapes techniques : installation de la CLI OVHcloud, configuration d’un compte de service IAM avec des droits minimaux, puis déploiement d’ESO via Helm. L’opérateur permet de synchroniser automatiquement les secrets depuis OVHcloud Secret Manager vers Kubernetes, avec un chiffrement au repos et une gestion centralisée des accès via des tokens IAM. L’auteur compare cette solution à des alternatives comme OpenBao, jugées plus complexes à maintenir pour des clusters légers.
Enfin, l’article aborde la question budgétaire, précisant que le coût reste très faible pour un usage modéré, et propose une méthode pour regrouper plusieurs valeurs sous un même secret afin d’optimiser la facturation. La démarche est présentée comme une alternative efficace aux solutions auto-hébergées, idéale pour les environnements éphémères ou les équipes cherchant à simplifier leur gestion des secrets.
Ce guide explique comment configurer un SSO SAML entre HelloID et Amazon Connect, un processus qui ne se fait pas directement dans Amazon Connect mais via AWS IAM et l'IdP. L'idée principale est que l'authentification est gérée par HelloID (source de vérité), tandis qu'Amazon Connect se contente d'autoriser les utilisateurs déjà authentifiés via un flux IdP-initiated. L'instance Amazon Connect doit être créée en mode SAML dès le départ, car ce paramètre est irréversible.
La configuration implique trois étapes clés : déclarer HelloID comme fournisseur d'identité dans IAM, créer un rôle de fédération avec les droits nécessaires (notamment connect:GetFederationToken), et configurer une application SAML dans HelloID en utilisant des attributs spécifiques (comme Role et RoleSessionName) pour éviter les erreurs de mapping. Deux pièges majeurs sont à éviter : l'absence du certificat de signature dans les métadonnées SAML de HelloID et l'utilisation d'un mapping SAML générique qui nettoie les caractères spéciaux nécessaires aux noms d'attributs AWS.
Enfin, le rôle créé dans IAM doit être configuré pour autoriser l'assomption de rôle via SAML avec une audience spécifique, et l'application HelloID doit être correctement paramétrée pour émettre les attributs requis par AWS. Une fois ces étapes validées, les utilisateurs peuvent accéder à Amazon Connect via HelloID sans saisie de credentials supplémentaires.
Un retour d'expérience plutôt positif
L'auteur présente la solution d'IAM (Identity and Access Management) de Scaleway, notamment vis à vis de son intégration à Terraform.