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.
# Autenticate con AWS Secrets Manager Amazon Data Firehose
Amazon Data Firehose se integra AWS Secrets Manager para proporcionar un acceso seguro a sus datos secretos y automatizar la rotación de credenciales. Esta integración permite a Firehose recuperar un secreto de Secrets Manager en tiempo de ejecución para conectarse a los destinos de streaming mencionados anteriormente y entregar sus flujos de datos. De este modo, sus secretos no están visibles en texto plano durante el flujo de trabajo de creación de transmisiones Consola de administración de AWS ni en los parámetros de la API. Es una práctica segura para administrar sus secretos y evita que tenga que implementar actividades complejas de administración de credenciales, como la configuración de funciones de Lambda personalizadas para administrar la rotación de contraseñas.
Para obtener más información, consulte la [Guía del usuario de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide).
**Topics**
+ [Comprensión de los secretos](secrets-manager-whats-secret.md)
+ [Creación de un secreto](secrets-manager-create.md)
+ [Uso del secreto](secrets-manager-how.md)
+ [Rotación del secreto](secrets-manager-rotate.md)
# Comprensión de los secretos
Un secreto puede ser una contraseña, un conjunto de credenciales, como un nombre de usuario y una contraseña, un OAuth token u otra información secreta que se almacene de forma cifrada en Secrets Manager.
Para cada destino, debe especificar el par clave-valor secreto en el formato JSON correcto, como se muestra en la siguiente sección. Amazon Data Firehose no podrá conectarse al destino si el secreto no tiene el formato JSON correcto según el destino.
**Formato de secreto para bases de datos como MySQL y PostgreSQL**
```
{
"username": "",
"password": ""
}
```
**Formato de secreto para el clúster aprovisionado Amazon Redshift y el grupo de trabajo Amazon Redshift sin servidor**
```
{
"username": "",
"password": ""
}
```
**Formato de secreto para Splunk**
```
{
"hec_token": ""
}
```
**Formato del secreto de Snowflake**
```
{
"user": "",
"private_key": "", // without the beginning and ending private key, remove all spaces and newlines
"key_passphrase": "" // optional
}
```
**Formato de secreto para el punto final HTTP, Coralogix, Datadog, Dynatrace, Elastic, Honeycomb, LogicMonitor Logz.io, MongoDB Cloud y New Relic**
```
{
"api_key": ""
}
```
# Creación de un secreto
Para crear un secreto, siga los pasos que se indican en la [sección Crear un AWS Secrets Manager secreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) de la *Guía del AWS Secrets Manager usuario*.
# Uso del secreto
Le recomendamos que las utilice AWS Secrets Manager para almacenar sus credenciales o claves para conectarse a destinos de streaming como Amazon Redshift, HTTP Endpoint, Snowflake, Splunk, Coralogix, Datadog, Dynatrace, Elastic, Honeycomb, Logz.io, MongoDB Cloud y New Relic. LogicMonitor
Puede configurar la autenticación con Secrets Manager para estos destinos a través de la Consola de administración de AWS en el momento de crear el flujo de Firehose. Para obtener más información, consulte [Configuración de los ajustes de destino](create-destination.md). Como alternativa, también puede usar las operaciones [CreateDeliveryStream](https://docs.aws.amazon.com/firehose/latest/APIReference/API_CreateDeliveryStream.html)y [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html)API para configurar la autenticación con Secrets Manager.
Firehose guarda en caché los secretos con un cifrado y los utiliza para cada conexión a destinos. Actualiza la memoria caché cada 10 minutos para asegurarse de que se utilizan las credenciales más recientes.
Puede optar por desactivar la capacidad de recuperar datos secretos de Secrets Manager en cualquier momento durante el ciclo de vida del flujo. Si no quieres usar Secrets Manager para recuperar secretos, puedes usar la clave username/password o API en su lugar.
**nota**
Aunque esta característica no conlleva ningún costo adicional en Firehose, se le cobrará el acceso y el mantenimiento de Secrets Manager. Para obtener más información, consulte la página de precios de [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/).
## Concesión de acceso a Firehose para recuperar el secreto
Para que Firehose recupere un secreto AWS Secrets Manager, debes proporcionar a Firehose los permisos necesarios para acceder al secreto y la clave que lo cifra.
Cuando se utiliza AWS Secrets Manager para almacenar y recuperar secretos, hay varias opciones de configuración diferentes en función de dónde esté almacenado el secreto y de cómo esté cifrado.
+ Si el secreto está almacenado en la misma AWS cuenta que tu función de IAM y está cifrado con la clave AWS gestionada predeterminada (`aws/secretsmanager`), la función de IAM que Firehose asume solo necesita `secretsmanager:GetSecretValue` permiso sobre el secreto.
```
// secret role policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "Secret ARN"
}
]
}
```
Para obtener más información acerca de las políticas de IAM, consulte [Ejemplos de políticas de permisos para AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html).
+ Si el secreto se almacena en la misma cuenta que el rol, pero se cifra con una [clave administrada por el cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK), el rol necesita ambos permisos `secretsmanager:GetSecretValue` y `kms:Decrypt`. La política de CMK también debe permitir que el rol de IAM implemente `kms:Decrypt`.
+ Si el secreto se almacena en una AWS cuenta diferente a la de su rol y se cifra con la clave AWS administrada predeterminada, esta configuración no es posible, ya que Secrets Manager no permite el acceso entre cuentas cuando el secreto está cifrado con la clave AWS administrada.
+ Si el secreto se almacena en una cuenta diferente y se cifra con una CMK, el rol de IAM necesita tener permiso `secretsmanager:GetSecretValue` sobre el secreto y `kms:Decrypt` sobre la CMK. La política de recursos del secreto y la política de CMK de la otra cuenta también deben concederle al rol de IAM los permisos necesarios. Para obtener más información, consulte [Acceso entre cuentas](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html).
# Rotación del secreto
La *rotación* consiste en actualizar periódicamente un secreto. Puede configurarlo AWS Secrets Manager para que rote automáticamente el secreto según el cronograma que especifique. Así, puede reemplazar los secretos a largo plazo por secretos a corto plazo. Esto ayuda a reducir el riesgo de que se comprometa la seguridad. Para obtener más información, consulte [Rotar AWS Secrets Manager los secretos](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) en la *Guía del AWS Secrets Manager usuario*.