Uso del secreto

Le recomendamos que utilice AWS Secrets Manager para almacenar sus credenciales o claves para conectarse a destinos de streaming como Amazon Redshift, punto de conexión HTTP, Snowflake, Splunk, Coralogix, Datadog, Dynatrace, Elastic, Honeycomb, LogicMonitor, Logz.io, MongoDB Cloud y New Relic.

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. Como alternativa, también puede usar las operaciones CreateDeliveryStream y UpdateDestination de la 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 quiere usar Secrets Manager para recuperar secretos, puede usar el nombre de usuario/contraseña o la clave de API.

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.

Concesión de acceso a Firehose para recuperar el secreto

Para que Firehose recupere un secreto de AWS Secrets Manager, debe proporcionarle 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 cuenta de AWS que el rol de IAM y está cifrado con la clave administrada por AWS predeterminada (aws/secretsmanager), el rol de IAM que Firehose asume solo necesita el permiso secretsmanager:GetSecretValue 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.

• Si el secreto se almacena en la misma cuenta que el rol, pero se cifra con una clave administrada por el cliente (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.

  {
      "Version": "2012-10-17",
      "Statement": [{
              "Effect": "Allow",
              "Action": "secretsmanager:GetSecretValue",
              "Resource": "Secret ARN"
          },
          {
              "Effect": "Allow",
              "Action": "kms:Decrypt",
              "Resource": "KMSKeyARN"
          }
      ]
  }

• Si el secreto se almacena en una cuenta de AWS diferente a la del rol y se cifra con la clave administrada por AWS 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 administrada por AWS.

• 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.