Rotation des informations d'identification de base de données sans redémarrer les conteneurs

Créée par Josh Joy (AWS)

Récapitulatif

Sur le cloud Amazon Web Services (AWS), vous pouvez utiliser AWS Secrets Manager pour faire pivoter, gérer et récupérer les informations d'identification des bases de données tout au long de leur cycle de vie. Les utilisateurs et les applications récupèrent les secrets en appelant le Secrets ManagerAPI, ce qui évite de devoir coder en dur les informations sensibles en texte brut.

Si vous utilisez des conteneurs pour les charges de travail de microservices, vous pouvez stocker les informations d'identification en toute sécurité dans AWS Secrets Manager. Pour séparer la configuration du code, ces informations d'identification sont généralement injectées dans le conteneur. Cependant, il est important de changer régulièrement et automatiquement vos informations d'identification. Il est également important de soutenir la possibilité d'actualiser les informations d'identification après la révocation. Dans le même temps, les applications doivent pouvoir alterner les informations d'identification tout en réduisant tout impact potentiel sur la disponibilité en aval.

Ce modèle décrit comment alterner vos secrets sécurisés avec AWS Secrets Manager au sein de vos conteneurs sans avoir à redémarrer vos conteneurs. En outre, ce modèle réduit le nombre de recherches d'informations d'identification vers Secrets Manager en utilisant le composant de mise en cache côté client de Secrets Manager. Lorsque vous utilisez le composant de mise en cache côté client pour actualiser les informations d'identification dans l'application, le conteneur n'a pas besoin d'être redémarré pour récupérer les informations d'identification modifiées.

Cette approche fonctionne pour Amazon Elastic Kubernetes Service (Amazon) et EKS Amazon Elastic Container Service (Amazon). ECS

Deux scénarios sont couverts. Dans le scénario mono-utilisateur, les informations d'identification de base de données sont actualisées lors d'une rotation secrète en détectant les informations d'identification expirées. Le cache d'informations d'identification reçoit l'ordre d'actualiser le secret, puis l'application rétablit la connexion à la base de données. Le composant de mise en cache côté client met en cache les informations d'identification dans l'application et permet d'éviter de contacter Secrets Manager pour chaque recherche d'informations d'identification. Les informations d'identification font l'objet d'une rotation dans l'application sans qu'il soit nécessaire de forcer l'actualisation des informations d'identification en redémarrant le conteneur.

Le second scénario fait alterner le secret en alternant entre deux utilisateurs. Le fait d'avoir deux utilisateurs actifs réduit les risques d'indisponibilité, car les informations d'identification d'un utilisateur sont toujours actives. La rotation des informations d'identification entre deux utilisateurs est utile lorsque vous avez un déploiement de grande envergure avec des clusters dans lesquels le délai de propagation des mises à jour des informations d'identification peut être faible.

Conditions préalables et limitations

Prérequis

Limites

Architecture

Architecture cible

Scénario 1 — Rotation d'un identifiant pour un seul utilisateur

Dans le premier scénario, un seul identifiant de base de données est périodiquement modifié par Secrets Manager. Le conteneur d'applications s'exécute dans Fargate. Lorsque la première connexion à la base de données est établie, le conteneur de l'application récupère les informations d'identification de base de données pour Aurora. Le composant de mise en cache de Secrets Manager met ensuite en cache les informations d'identification pour l'établissement de futures connexions. Lorsque la période de rotation est écoulée, les informations d'identification expirent et la base de données renvoie une erreur d'authentification. L'application récupère ensuite les informations d'identification modifiées, invalide le cache et met à jour le cache des informations d'identification via le composant de mise en cache côté client de Secrets Manager.

Dans ce scénario, les perturbations peuvent être minimes lors de la rotation des informations d'identification et lorsque les connexions périmées utilisent des informations d'identification périmées. Ce problème peut être résolu en utilisant le scénario à deux utilisateurs.

Scénario 2 — Rotation des informations d'identification pour deux utilisateurs

Dans le second scénario, les informations d'identification de deux utilisateurs de base de données (celles d'Alice et de Bob) sont périodiquement modifiées par Secrets Manager. Le conteneur d'applications s'exécute dans un cluster Fargate. Lorsque la première connexion à la base de données est établie, le conteneur de l'application récupère les informations d'identification de la base de données Aurora pour le premier utilisateur (Alice). Le composant de mise en cache de Secrets Manager met ensuite en cache les informations d'identification pour l'établissement de futures connexions.

Bien qu'il y ait deux utilisateurs et deux identifiants, un seul identifiant actif est géré par Secrets Manager. Dans ce cas, le composant de mise en cache expire périodiquement et récupère les dernières informations d'identification. Si la période de rotation de Secrets Manager est plus longue que le délai d'expiration du cache, le composant de mise en cache récupère les informations d'identification modifiées pour le deuxième utilisateur (Bob). Par exemple, si l'expiration du cache est mesurée en minutes et que la période de rotation est mesurée en jours, le composant de mise en cache récupère les nouvelles informations d'identification dans le cadre de son actualisation périodique du cache. De cette façon, le temps d'arrêt est réduit au minimum car les informations d'identification de chaque utilisateur sont actives pendant une rotation de Secrets Manager.

Automatisation et mise à l'échelle

Vous pouvez l'utiliser AWS CloudFormationpour déployer ce modèle en utilisant l'infrastructure comme code. Cela construit et crée le conteneur d'applications, crée la tâche Fargate, déploie le conteneur dans Fargate, puis installe et configure Secrets Manager avec Aurora. Pour les instructions de step-by-step déploiement, consultez le fichier readme.

Outils

Outils

Code

Exemple de code Python

Ce modèle utilise le composant de mise en cache côté client Python pour que Secrets Manager récupère les informations d'authentification lors de l'établissement de la connexion à la base de données. Le composant de mise en cache côté client permet d'éviter de contacter Secrets Manager à chaque fois.

Désormais, à l'expiration de la période de rotation, les informations d'identification mises en cache expirent et la connexion à la base de données entraîne une erreur d'authentification. Pour MySQL, le code d'erreur d'authentification est 1045. Cet exemple utilise Amazon Aurora for MySQL, mais vous pouvez utiliser un autre moteur tel que PostgreSQL. En cas d'erreur d'authentification, le code de gestion des exceptions de connexion à la base de données détecte l'erreur. Il demande ensuite au composant de mise en cache côté client de Secrets Manager d'actualiser le secret, puis de réauthentifier et de rétablir la connexion à la base de données. Si vous utilisez Postgre SQL ou un autre moteur, vous devez rechercher le code d'erreur d'authentification correspondant.

L'application du conteneur peut désormais mettre à jour le mot de passe de la base de données avec le mot de passe modifié sans redémarrer le conteneur.

Placez le code suivant dans le code de votre application qui gère les connexions aux bases de données. Cet exemple utilise Django et sous-classe le backend de base de données avec un wrapper de base de données pour les connexions. Si vous utilisez un autre langage de programmation ou une autre bibliothèque de connexion à la base de données, consultez votre bibliothèque de connexions à la base de données pour savoir comment sous-classer la récupération des connexions à la base de données.

    def get_new_connection(self, conn_params):
        try:
            logger.info("get connection")
            databasecredentials.get_conn_params_from_secrets_manager(conn_params)
            conn =super(DatabaseWrapper,self).get_new_connection(conn_params)
            return conn
        except MySQLdb.OperationalError as e:
            error_code=e.args[0]
            if error_code!=1045:
                raise e
 
            logger.info("Authentication error. Going to refresh secret and try again.")
            databasecredentials.refresh_now()
            databasecredentials.get_conn_params_from_secrets_manager(conn_params)
            conn=super(DatabaseWrapper,self).get_new_connection(conn_params)
            logger.info("Successfully refreshed secret and established new database connection.")
            return conn

AWS CloudFormation et code Python

Épopées

Ressources connexes

Création d'un secret dans le Gestionnaire de Secrets

Création d'un cluster Amazon Aurora

Création des ECS composants Amazon

Téléchargez et installez le composant de mise en cache côté client de Secrets Manager

Pièces jointes

Pour accéder au contenu supplémentaire associé à ce document, décompressez le fichier suivant : attachment.zip