Uso do segredo - Amazon Data Firehose
Concessão de acesso ao Firehose para recuperar o segredo

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Uso do segredo

Recomendamos que você use AWS Secrets Manager para armazenar suas credenciais ou chaves para se conectar a destinos de streaming, como Amazon RedshiftHTTP, endpoint, Snowflake, Splunk, Coralogix, Datadog, Dynatrace, Elastic, Honeycomb, Logz.io, MongoDB Cloud e New Relic. LogicMonitor

É possível configurar a autenticação com o Secrets Manager para esses destinos por meio do Console de Gerenciamento da AWS no momento da criação do fluxo do Firehose. Para obter mais informações, consulte Definição de configurações do destino. Como alternativa, você também pode usar as UpdateDestinationAPIoperações CreateDeliveryStreame para configurar a autenticação com o Secrets Manager.

O Firehose armazena os segredos em cache com uma criptografia e os usa em todas as conexões com os destinos. Ele atualiza o cache a cada 10 minutos para garantir que as credenciais mais recentes sejam usadas.

É possível optar por desativar a capacidade de recuperar segredos do Secrets Manager a qualquer momento durante o ciclo de vida do fluxo. Se você não quiser usar o Secrets Manager para recuperar segredos, você pode usar o nome de usuário/senha ou a chave. API

nota

Embora não haja custo adicional para esse atributo no Firehose, você será cobrado pelo acesso e pela manutenção do Secrets Manager. Para obter mais informações, consulte a página de definição de preços do AWS Secrets Manager.

Concessão de acesso ao Firehose para recuperar o segredo

Para que o Firehose recupere um segredo AWS Secrets Manager, você deve fornecer ao Firehose as permissões necessárias para acessar o segredo e a chave que criptografa seu segredo.

Ao usar AWS Secrets Manager para armazenar e recuperar segredos, há algumas opções de configuração diferentes, dependendo de onde o segredo está armazenado e de como é criptografado.

  • Se o segredo estiver armazenado na mesma AWS conta da sua IAM função e estiver criptografado com a chave AWS gerenciada padrão (aws/secretsmanager), a IAM função assumida pelo Firehose só precisará de secretsmanager:GetSecretValue permissão sobre o segredo. 

    // secret role policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "Secret ARN"
        }
    ]
}

    Para obter mais informações sobre IAM políticas, consulte exemplos de políticas de permissões para AWS Secrets Manager.

  • Se o segredo estiver armazenado na mesma conta da função, mas criptografado com uma chave gerenciada pelo cliente (CMK), a função precisará de ambas secretsmanager:GetSecretValue e de kms:Decrypt permissões. A CMK política também precisa permitir que a IAM função seja desempenhadakms:Decrypt. 

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

  • Se o segredo estiver armazenado em uma AWS conta diferente da sua função e for criptografado com a chave AWS gerenciada padrão, essa configuração não será possível, pois o Secrets Manager não permite acesso entre contas quando o segredo é criptografado com a chave AWS gerenciada.

  • Se o segredo estiver armazenado em uma conta diferente e criptografado com umaCMK, a IAM função precisará de secretsmanager:GetSecretValue permissão sobre o segredo e kms:Decrypt permissão sobre CMK o. A política de recursos do segredo e a CMK política da outra conta também precisam conceder à IAM função as permissões necessárias. Para obter mais informações, consulte Acesso entre contas.