Rotar las credenciales de la base de datos sin reiniciar los contenedores - Recomendaciones de AWS

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Rotar las credenciales de la base de datos sin reiniciar los contenedores

Creado por Josh Joy () AWS

Entorno: producción

Tecnologías: contenedores y microservicios; bases de datos DevOps; infraestructura; seguridad, identidad y cumplimiento; administración y gobierno

AWSservicios: AmazonECS; Amazon Aurora; AWS Fargate; AWS Secrets Manager; Amazon VPC

Resumen

En la nube de Amazon Web Services (AWS), puede utilizar AWS Secrets Manager para rotar, gestionar y recuperar las credenciales de las bases de datos a lo largo de su ciclo de vida. Los usuarios y las aplicaciones recuperan los secretos con una llamada al Secrets ManagerAPI, lo que elimina la necesidad de codificar la información confidencial en texto plano.

Si utilizas contenedores para cargas de trabajo de microservicios, puedes almacenar las credenciales de forma segura en AWS Secrets Manager. Para separar la configuración y el código, estas credenciales suelen insertarse en el contenedor. Sin embargo, es importante rotar sus credenciales de forma periódica y automática. También es importante respaldar la posibilidad de actualizar las credenciales después de revocarlas. Al mismo tiempo, las aplicaciones requieren la capacidad de rotar las credenciales y reducir a la vez cualquier posible impacto en las fases posteriores.

Este patrón describe cómo rotar los secretos que están protegidos con AWS Secrets Manager dentro de sus contenedores sin necesidad de que los contenedores se reinicien. Además, este patrón reduce el número de búsquedas de credenciales en Secrets Manager mediante el componente de almacenamiento en caché alojado en el cliente de Secrets Manager. Cuando se utiliza el componente de almacenamiento en caché alojado en el cliente para actualizar las credenciales de la aplicación, no es necesario reiniciar el contenedor para recuperar una credencial rotada.

Este enfoque funciona para Amazon Elastic Kubernetes Service (Amazon) y EKS Amazon Elastic Container Service (Amazon). ECS

Se describen dos escenarios. En el escenario de un solo usuario, la credencial de la base de datos se actualiza cuando se produce una rotación secreta al detectar la credencial caducada. La caché del credencial recibe instrucciones para actualizar el secreto y, a continuación, la aplicación restablece la conexión a la base de datos. El componente de almacenamiento en caché alojado en el cliente almacena en caché la credencial dentro de la aplicación y ayuda a evitar el uso de Secrets Manager para cada búsqueda de credenciales. La credencial se rota dentro de la aplicación sin necesidad de forzar la actualización de la credencial reiniciando el contenedor.

El segundo escenario rota el secreto alternando entre dos usuarios. Tener dos usuarios activos reduce la posibilidad de que se produzca un tiempo de inactividad, ya que las credenciales de un usuario están siempre activas. La rotación de credenciales de dos usuarios resulta útil cuando se tiene una implementación grande con clústeres en los que puede haber un pequeño retraso en la propagación de las actualizaciones de credenciales.

Requisitos previos y limitaciones

Requisitos previos 

  • Una cuenta de AWS activa.

  • Aplicación que se ejecuta en un contenedor de Amazon EKS o AmazonECS.

  • Las credenciales se almacenan en Secrets Manager, con la rotación habilitada.

  • Un segundo conjunto de credenciales almacenado en Secrets Manager, si se implementa la solución para dos usuarios. Puedes encontrar ejemplos de código en el GitHub repositorio aws-secrets-manager-rotation-lambdas.

  • Una base de datos de Amazon Aurora.

Limitaciones

Arquitectura

Arquitectura de destino

Escenario 1: rotación de una credencial para un solo usuario

Diagrama que muestra los procesos desde Secrets Manager hasta la aplicación y desde Fargate hasta Aurora.

En el primer escenario, Secrets Manager rota periódicamente una única credencial de base de datos. El contenedor de aplicaciones se ejecuta en Fargate. Cuando se establece la primera conexión a la base de datos, el contenedor de la aplicación obtiene la credencial de base de datos de Aurora. A continuación, el componente de almacenamiento en caché de Secrets Manager almacena en caché la credencial para el futuro establecimiento de la conexión. Una vez transcurrido el período de rotación, la credencial caduca y la base de datos devuelve un error de autenticación. A continuación, la aplicación recupera la credencial rotada, invalida la caché y actualiza la caché de credenciales mediante el componente de almacenamiento en caché alojado en el cliente de Secrets Manager.

En este escenario, es posible que se produzca una interrupción mínima mientras se está rotando la credencial y las conexiones obsoletas están utilizando la credencial obsoleta. Este problema se puede solucionar utilizando el escenario de dos usuarios.

Escenario 2: rotación de una credencial para dos usuarios

Diagrama que muestra el clúster de Fargate, Aurora y Secrets Manager, con las credenciales para Alice y Bob.

En el segundo escenario, Secrets Manager rota periódicamente dos credenciales de usuario (la de Alice y la de Bob) de la base de datos. El contenedor de aplicaciones se ejecuta en el clúster de Fargate. Cuando se establece la primera conexión a la base de datos, el contenedor de la aplicación obtiene la credencial de la base de datos de Aurora para el primer usuario (Alice). A continuación, el componente de almacenamiento en caché de Secrets Manager almacena en caché la credencial para el futuro establecimiento de la conexión.

Aunque hay dos usuarios y credenciales, Secrets Manager solo administra una credencial activa. En este caso, el componente de almacenamiento en caché caduca periódicamente y obtiene la credencial más reciente. Si el período de rotación de Secrets Manager es superior al tiempo de espera de la caché, el componente de almacenamiento en caché recoge la credencial rotada del segundo usuario (Bob). Por ejemplo, si la caducidad de la caché se mide en minutos y el período de rotación se mide en días, el componente de almacenamiento en caché obtiene la nueva credencial como parte de la actualización periódica de la caché. De esta forma, se minimiza el tiempo de inactividad porque la credencial de cada usuario está activa durante una rotación de Secrets Manager.

Automatizar y escalar

Se puede utilizar AWS CloudFormationpara implementar este patrón mediante el uso de la infraestructura como código. Esto compila y crea el contenedor de aplicaciones, crea la tarea de Fargate, implementa el contenedor en Fargate y configura Secrets Manager con Aurora. Para obtener instrucciones de step-by-step implementación, consulte el archivo readme.

Herramientas

Herramientas

  • AWSSecrets Manager permite reemplazar las credenciales codificadas, incluidas las contraseñas, con una API llamada a Secrets Manager para recuperar el secreto. Dado que Secrets Manager puede rotar automáticamente el secreto según una programación, se pueden reemplazar los secretos a largo plazo por otros a corto plazo, lo que reduce el riesgo de que se filtren.

  • Docker: facilita a los desarrolladores empaquetar, enviar y ejecutar cualquier aplicación como un contenedor ligero, portátil y autosuficiente.

Código

Ejemplos de código Python

Este patrón utiliza el componente de almacenamiento en caché alojado en el cliente de Python para que Secrets Manager recupere las credenciales de autenticación al establecer la conexión a la base de datos. El componente de almacenamiento en caché alojado en el cliente ayuda a evitar tener que recurrir a Secrets Manager todas las veces.

Ahora, cuando finalice el período de rotación, la credencial almacenada en caché caducará y, al conectarse a la base de datos, se producirá un error de autenticación. En el caso de MySQL, el código de error de autenticación es 1045. En este ejemplo se utiliza Amazon Aurora for MySQL, aunque podría utilizar otro motor, como PostgreSQL. Cuando se produce un error de autenticación, el código de gestión de excepciones de conexión a la base de datos lo detecta. A continuación, informa al componente de almacenamiento en caché alojado en el cliente de Secrets Manager para que actualice el secreto y, a continuación, vuelve a autenticarse y restablecer la conexión con la base de datos. Si utiliza Postgre SQL u otro motor, debe buscar el código de error de autenticación correspondiente.

La aplicación del contenedor puede ahora actualizar la contraseña de la base de datos con la contraseña rotada sin necesidad de reiniciar el contenedor.

Colocar el siguiente código en su código de aplicación que gestiona las conexiones a la base de datos. Este ejemplo utiliza Django y subclasifica el backend de la base de datos con un encapsulador de bases de datos para las conexiones. Si está utilizando un lenguaje de programación o una biblioteca de conexiones de bases de datos diferentes, consulte la biblioteca de conexiones de base de datos para ver cómo subclasificar la recuperación de conexiones de bases de datos.

    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 y código Python

Epics

TareaDescripciónHabilidades requeridas

Instalar el componente de almacenamiento en caché.

Descargue e instale el componente de almacenamiento en caché alojado en el cliente de Secrets Manager para Python. Para ver el enlace de descarga, consulte la sección Recursos relacionados.

Desarrollador

Guarde en caché la credencial de trabajo.

Utilice el componente de almacenamiento en caché alojado en el cliente de Secrets Manager para almacenar en caché la credencial de trabajo de forma local.

Desarrollador

Actualice el código de la aplicación para actualizar la credencial en caso de que se produzca un error no autorizado en la conexión a la base de datos.

Actualice el código de la aplicación para utilizar Secrets Manager con el fin de obtener y actualizar las credenciales de la base de datos. Añada la lógica para gestionar los códigos de error no autorizados y, a continuación, obtenga la credencial recién rotada. Consulte la sección Ejemplo de código Python.

Desarrollador

Recursos relacionados

Crear un secreto en Secrets Manager

Crear un clúster de base de datos de Amazon Aurora

Crea los ECS componentes de Amazon

Descargar e instalar el componente de almacenamiento en caché alojado en el cliente de Secrets Manager

Conexiones

Para acceder al contenido adicional asociado a este documento, descomprima el archivo: attachment.zip