Encontré algunos casos de uso específicos que estoy un poco confundido para usar:
Para almacenar cualquier credencial, tiene tres opciones administradas por AWS:
Variables de entorno Lambda
Estos se pasarán a la función Lambda directamente a través del servicio Lambda. Puede evitar que otros accedan a los valores de cadena controlando sus permisos para KMS a través de IAM . Esto proporcionará el mejor rendimiento de todas las opciones (no hay búsqueda adicional en el tiempo de ejecución del código).
Al utilizar esta opción, tenga en cuenta los siguientes peligros:
Almacén de parámetros del administrador de sistemas
Con esta opción, usaría el SDK para recuperar cualquier clave/valor que desee. Puede almacenar tanto valores de texto sin formato como cadenas cifradas (el tipo SecureString ). Proporciona una funcionalidad básica, pero si eso es todo lo que necesita, funcionará muy bien. No cuesta nada almacenar los valores, pero el precio es $0.05 per 10,000 Parameter Store API interactions . A diferencia de las variables de entorno, puede utilizar el valor en varias funciones de Lambda.
Al usar esta opción, debe tener en cuenta lo siguiente:
Administrador de secretos
Con esta opción, gran parte de la administración está integrada en el servicio, un secreto puede contener una cadena o un objeto JSON de una sola línea. El SDK manejará la recuperación de estos valores, pero debe tener en cuenta que, al igual que SSM, sufrirá un impacto en el rendimiento, por lo que querrá ver una solución similar a la del almacén de parámetros. La mayor ventaja del administrador de secretos sobre el almacén de parámetros de SSM es su integración con otros servicios de AWS que permiten funciones como la rotación de secretos.
Sin embargo, si no necesita las funciones del administrador de secretos, es posible que esté pagando más de lo que realmente necesita, esta es la opción más cara de las tres.
Una gran cantidad de claves de API públicas y gratuitas. Usando la variable de entorno lambda con cifrado, otro desarrollador/administrador aún puede exponer su valor de texto sin formato directamente en la consola de lambds.
Para el problema de que los desarrolladores puedan ver las variables de entorno en la consola, puede usar una CMK de KMS no predeterminada y configurar permisos en esa clave para que los otros desarrolladores no puedan usarla ( doc ). Todavía podrán ver el resto de la configuración de Lambda.
Un problema mayor es cómo configurará estas variables de entorno. Si usa Terraform, por ejemplo, la configuración se escribe en el archivo de estado y necesitará usar un estado externo (almacenado en S3 o en los servidores de HashiCorp) para asegurarlo. Si usa CloudFormation, puede configurarlos usando una referencia dinámica a un secreto de Secrets Manager, pero no a una cadena segura de almacén de parámetros.
Otra opción es usar las variables de entorno para hacer referencia a las claves del almacén de parámetros y luego recuperar los valores mediante programación. Por ejemplo, tiene una variable de entorno denominada DATABASE_PASSWORD y su valor es /dev/database/password ; la contraseña real de la base de datos es una SecureString en el almacén de parámetros, a la que se accede a través de esa ruta.
Credenciales de inicio de sesión en una plataforma de terceros. ¿Supongo que Secrets Manager es la única opción?
El almacén de parámetros también proporciona un SecureString.
Cadenas de conexión de base de datos. ¿Administrador de secretos? A $0.40/secreto/mes, la factura ascendería a cientos de bases de datos simplemente por almacenar credenciales.
¿Su aplicación realmente se conecta a cientos de bases de datos? En caso afirmativo, ¿son $40/mes (por 100 conexiones) realmente una dificultad financiera para su empresa?
En caso afirmativo, entonces el almacén de parámetros podría ser la mejor opción, pero tenga en cuenta que hay un número limitado de parámetros "gratuitos" por cuenta.