Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Authentifiez-vous AWS Secrets Manager dans Amazon Data Firehose
Amazon Data Firehose s'intègre AWS Secrets Manager pour fournir un accès sécurisé à vos secrets et automatiser la rotation des identifiants. Cette intégration permet à Firehose de récupérer un secret depuis Secrets Manager au moment de l'exécution pour se connecter aux destinations de streaming mentionnées précédemment et diffuser vos flux de données. Ainsi, vos secrets ne sont pas visibles en texte brut pendant le flux de travail de création de flux, que ce soit dans les paramètres de l'API AWS Management Console ou dans les paramètres de l'API. Il fournit une pratique sécurisée pour gérer vos secrets et vous soulage des activités complexes de gestion des informations d'identification, telles que la configuration de fonctions Lambda personnalisées pour gérer les rotations de mots de passe.
Pour plus d’informations, consultez le [Guide de l’utilisateur AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide).
**Topics**
+ [Comprenez les secrets](secrets-manager-whats-secret.md)
+ [Créer un secret](secrets-manager-create.md)
+ [Utilisez le secret](secrets-manager-how.md)
+ [Faites pivoter le secret](secrets-manager-rotate.md)
# Comprenez les secrets
Un secret peut être un mot de passe, un ensemble d'informations d'identification telles qu'un nom d'utilisateur et un mot de passe, un OAuth jeton ou toute autre information secrète que vous stockez sous forme cryptée dans Secrets Manager.
Pour chaque destination, vous devez spécifier la paire clé-valeur secrète au format JSON correct, comme indiqué dans la section suivante. Amazon Data Firehose ne parviendra pas à se connecter à votre destination si le format JSON de votre secret ne correspond pas à la destination.
**Format du secret pour les bases de données telles que MySQL et PostgreSQL**
```
{
"username": "",
"password": ""
}
```
**Format du secret pour le cluster Amazon Redshift Provisioned et le groupe de travail Amazon Redshift Serverless**
```
{
"username": "",
"password": ""
}
```
**Format du secret pour Splunk**
```
{
"hec_token": ""
}
```
**Format du secret pour Snowflake**
```
{
"user": "",
"private_key": "", // without the beginning and ending private key, remove all spaces and newlines
"key_passphrase": "" // optional
}
```
**Format du secret pour le point de terminaison HTTP, Coralogix, Datadog, Dynatrace, Elastic, Honeycomb, Logz.io, MongoDB Cloud et New Relic LogicMonitor**
```
{
"api_key": ""
}
```
# Créer un secret
Pour créer un secret, suivez les étapes décrites dans [Créer un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *Guide de AWS Secrets Manager l'utilisateur*.
# Utilisez le secret
Nous vous recommandons de stocker vos informations d'identification ou vos clés AWS Secrets Manager pour vous connecter à des destinations de streaming telles qu'Amazon Redshift, le point de terminaison HTTP, Snowflake, Splunk, Coralogix, Datadog, Dynatrace, Elastic, Honeycomb, Logz.io, MongoDB Cloud et New Relic. LogicMonitor
Vous pouvez configurer l'authentification avec Secrets Manager pour ces destinations via la console AWS de gestion au moment de la création du stream Firehose. Pour de plus amples informations, veuillez consulter [Configuration des paramètres de destination](create-destination.md). Vous pouvez également utiliser les opérations [CreateDeliveryStream](https://docs.aws.amazon.com/firehose/latest/APIReference/API_CreateDeliveryStream.html)et [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html)API pour configurer l'authentification avec Secrets Manager.
Firehose met en cache les secrets avec un cryptage et les utilise pour chaque connexion aux destinations. Il actualise le cache toutes les 10 minutes pour s'assurer que les dernières informations d'identification sont utilisées.
Vous pouvez choisir de désactiver la fonctionnalité de récupération des secrets depuis Secrets Manager à tout moment pendant le cycle de vie du flux. Si vous ne souhaitez pas utiliser Secrets Manager pour récupérer des secrets, vous pouvez utiliser la clé API username/password or à la place.
**Note**
Bien que cette fonctionnalité soit gratuite dans Firehose, l'accès et la maintenance de Secrets Manager vous sont facturés. Pour plus d’informations, consultez la page de tarification d’[AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/).
## Accordez l'accès à Firehose pour récupérer le secret
Pour que Firehose puisse récupérer un secret AWS Secrets Manager, vous devez fournir à Firehose les autorisations requises pour accéder au secret et à la clé qui chiffre votre secret.
Lors AWS Secrets Manager de l'utilisation pour stocker et récupérer des secrets, il existe différentes options de configuration en fonction de l'endroit où le secret est stocké et de la manière dont il est crypté.
+ Si le secret est stocké dans le même AWS compte que votre rôle IAM et qu'il est chiffré avec la clé AWS gérée par défaut (`aws/secretsmanager`), le rôle IAM assumé par Firehose n'a besoin que d'une `secretsmanager:GetSecretValue` autorisation sur le secret.
```
// secret role policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "Secret ARN"
}
]
}
```
Pour plus d'informations sur les politiques IAM, consultez les [exemples de politiques d'autorisation pour AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html).
+ Si le secret est stocké dans le même compte que le rôle mais chiffré à l'aide d'une [clé gérée par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK), le rôle a besoin à la fois d'`kms:Decrypt`autorisations `secretsmanager:GetSecretValue` et d'autorisations. La politique CMK doit également permettre au rôle IAM de fonctionner. `kms:Decrypt`
+ Si le secret est stocké dans un AWS compte différent de votre rôle et qu'il est chiffré avec la clé AWS gérée par défaut, cette configuration n'est pas possible car Secrets Manager n'autorise pas l'accès entre comptes lorsque le secret est chiffré avec une clé AWS gérée.
+ Si le secret est stocké dans un autre compte et crypté avec une clé CMK, le rôle IAM a besoin d'une `secretsmanager:GetSecretValue` autorisation sur le secret et d'une `kms:Decrypt` autorisation sur la clé CMK. La politique de ressources du secret et la politique CMK de l'autre compte doivent également accorder au rôle IAM les autorisations nécessaires. Pour plus d'informations, consultez la section [Accès entre comptes](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html).
# Faites pivoter le secret
*La rotation* se produit lorsque vous mettez régulièrement à jour un secret. Vous pouvez le configurer AWS Secrets Manager pour faire automatiquement pivoter le secret selon un calendrier que vous spécifiez. De cette façon, vous pouvez remplacer les secrets à long terme par des secrets à court terme. Cela permet de réduire le risque de compromission. Pour plus d'informations, voir [Rotation AWS Secrets Manager des secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) dans le *guide de AWS Secrets Manager l'utilisateur*.