Controllo dell'accesso con Amazon Data Firehose - Amazon Data Firehose

Amazon Data Firehose era precedentemente noto come Amazon Kinesis Data Firehose

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Controllo dell'accesso con Amazon Data Firehose

Le seguenti sezioni spiegano come controllare l'accesso da e verso le risorse Amazon Data Firehose. Le informazioni trattate includono come concedere l'accesso all'applicazione in modo che possa inviare dati allo stream Firehose. Descrivono inoltre come concedere ad Amazon Data Firehose l'accesso al tuo bucket Amazon Simple Storage Service (Amazon S3), al cluster Amazon Redshift OpenSearch o al cluster Amazon Service, nonché le autorizzazioni di accesso necessarie se utilizzi Datadog, LogicMonitor Dynatrace, MongoDB, New Relic, Splunk o Sumo Logic come destinazione. Infine, in questo argomento troverai indicazioni su come configurare Amazon Data Firehose in modo che possa fornire dati a una destinazione che appartiene a un account diverso AWS . La tecnologia per gestire tutte queste forme di accesso è AWS Identity and Access Management (IAM). Per ulteriori informazioni su IAM, consulta Che cos'è IAM?.

Concedi alla tua applicazione l'accesso alle tue risorse Amazon Data Firehose

Per consentire all'applicazione di accedere allo stream Firehose, utilizzate un criterio simile a questo esempio. Puoi regolare le singole operazioni API alle quali concedi l'accesso modificando la sezione Action; oppure puoi concedere l'accesso a tutte le operazioni con "firehose:*".

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "firehose:DeleteDeliveryStream", "firehose:PutRecord", "firehose:PutRecordBatch", "firehose:UpdateDestination" ], "Resource": [ "arn:aws:firehose:region:account-id:deliverystream/delivery-stream-name" ] } ] }

Concedi ad Amazon Data Firehose l'accesso al tuo cluster Amazon MSK privato

Se l'origine del tuo stream Firehose è un cluster Amazon MSK privato, utilizza una policy simile a questo esempio.

{ "Version": "2012-10-17", "Statement": [ { "Principal": { "Service": [ "firehose.amazonaws.com" ] }, "Effect": "Allow", "Action": [ "kafka:CreateVpcConnection" ], "Resource": "cluster-arn" } ] }

Consenti ad Amazon Data Firehose di assumere un ruolo IAM

Questa sezione descrive le autorizzazioni e le politiche che concedono ad Amazon Data Firehose l'accesso per l'acquisizione, l'elaborazione e la distribuzione dei dati dalla sorgente alla destinazione.

Nota

Se si utilizza la console per creare uno stream Firehose e si sceglie l'opzione per creare un nuovo ruolo, al ruolo AWS viene associata la policy di fiducia richiesta. Se desideri che Amazon Data Firehose utilizzi un ruolo IAM esistente o se ne crei uno personalizzato, collega le seguenti policy di trust a quel ruolo in modo che Amazon Data Firehose possa assumerlo. Modifica le politiche per sostituire account-id con l'ID del tuo account. AWS Per informazioni su come modificare la relazione di trust di un ruolo, consulta Modifica di un ruolo.

Amazon Data Firehose utilizza un ruolo IAM per tutte le autorizzazioni necessarie al flusso di distribuzione per elaborare e distribuire i dati. Assicurati che a quel ruolo siano associate le seguenti policy di fiducia in modo che Amazon Data Firehose possa assumerlo.

{ "Version": "2012-10-17", "Statement": [{ "Sid": "", "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "account-id" } } }] }

Questa policy utilizza la chiave di contesto delle sts:ExternalId condizioni per garantire che solo le attività di Amazon Data Firehose provenienti dal tuo AWS account possano assumere questo ruolo IAM. Per ulteriori informazioni su come evitare l'uso non autorizzato di ruoli IAM, consulta Problema del "confused deputy" nella Guida per l'utente IAM.

Se scegli Amazon MSK come origine per il tuo stream Firehose, devi specificare un altro ruolo IAM che conceda ad Amazon Data Firehose le autorizzazioni per importare dati di origine dal cluster Amazon MSK specificato. Assicurati che a quel ruolo siano associate le seguenti policy di fiducia in modo che Amazon Data Firehose possa assumerlo.

{ "Version": "2012-10-17", "Statement": [ { "Principal": { "Service": [ "firehose.amazonaws.com" ] }, "Effect": "Allow", "Action": "sts:AssumeRole" } ] }

Assicurati che questo ruolo che concede ad Amazon Data Firehose le autorizzazioni per importare dati di origine dal cluster Amazon MSK specificato conceda le seguenti autorizzazioni:

{ "Version": "2012-10-17", "Statement": [{ "Effect":"Allow", "Action": [ "kafka:GetBootstrapBrokers", "kafka:DescribeCluster", "kafka:DescribeClusterV2", "kafka-cluster:Connect" ], "Resource": "CLUSTER-ARN" }, { "Effect":"Allow", "Action": [ "kafka-cluster:DescribeTopic", "kafka-cluster:DescribeTopicDynamicConfiguration", "kafka-cluster:ReadData" ], "Resource": "TOPIC-ARN" }] }

Concedi ad Amazon Data Firehose l'accesso a AWS Glue per la conversione del formato dei dati

Se lo stream Firehose esegue una conversione in formato dati, Amazon Data Firehose fa riferimento alle definizioni delle tabelle memorizzate in. AWS Glue Per fornire ad Amazon Data Firehose l'accesso necessario a AWS Glue, aggiungi la seguente dichiarazione alla tua politica. Per informazioni su come trovare l'ARN della tabella, vedere Specificying AWS Glue Resource ARNs.

[{ "Effect": "Allow", "Action": [ "glue:GetTable", "glue:GetTableVersion", "glue:GetTableVersions" ], "Resource": "table-arn" }, { "Sid": "GetSchemaVersion", "Effect": "Allow", "Action": [ "glue:GetSchemaVersion" ], "Resource": ["*"] }]

La politica consigliata per recuperare gli schemi dal registro degli schemi non prevede restrizioni in termini di risorse. Per ulteriori informazioni, consulta gli esempi IAM per i deserializzatori nella Developer Guide. AWS Glue

Nota

Attualmente non AWS Glue è supportato nelle regioni di Israele (Tel Aviv), Asia Pacifico (Giacarta) o Medio Oriente (Emirati Arabi Uniti). Se lavori con Amazon Data Firehose nella regione Asia Pacifico (Giacarta) o Medio Oriente (Emirati Arabi Uniti), assicurati di consentire l'accesso ad Amazon Data Firehose AWS Glue in una delle regioni in cui è attualmente supportato. AWS Glue È supportata l'interoperabilità tra più regioni tra Data Firehose e. AWS Glue Per ulteriori informazioni sulle regioni in cui AWS Glue è supportato, consulta https://docs.aws.amazon.com/general/latest/gr/glue.html

Concedi ad Amazon Data Firehose l'accesso a una destinazione Amazon S3

Quando utilizzi una destinazione Amazon S3, Amazon Data Firehose invia i dati al tuo bucket S3 e può opzionalmente utilizzare una AWS KMS chiave di tua proprietà per la crittografia dei dati. Se la registrazione degli errori è abilitata, Amazon Data Firehose invia anche gli errori di consegna dei dati al gruppo di log e CloudWatch ai flussi. È necessario disporre di un ruolo IAM durante la creazione di uno stream Firehose. Amazon Data Firehose assume il ruolo IAM e ottiene l'accesso al bucket, alla chiave, al gruppo di log e CloudWatch ai flussi specificati.

Utilizza la seguente politica di accesso per consentire ad Amazon Data Firehose di accedere al tuo bucket e alla tua chiave S3. AWS KMS Se non sei proprietario del bucket S3, aggiungi s3:PutObjectAcl all'elenco delle operazioni Amazon S3. Ciò garantisce al proprietario del bucket l'accesso completo agli oggetti forniti da Amazon Data Firehose.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] }, { "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards" ], "Resource": "arn:aws:kinesis:region:account-id:stream/stream-name" }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:region:account-id:key/key-id" ], "Condition": { "StringEquals": { "kms:ViaService": "s3.region.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::bucket-name/prefix*" } } }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:region:account-id:log-group:log-group-name:log-stream:log-stream-name" ] }, { "Effect": "Allow", "Action": [ "lambda:InvokeFunction", "lambda:GetFunctionConfiguration" ], "Resource": [ "arn:aws:lambda:region:account-id:function:function-name:function-version" ] } ] }

La policy in alto ha anche un'istruzione che permette l'accesso a flusso di dati Amazon Kinesis. Se non utilizzi Kinesis Data Firehose come origine dati, puoi rimuovere questa istruzione. Se utilizzi Amazon MSK come fonte, puoi sostituire tale dichiarazione con la seguente:

{ "Sid":"", "Effect":"Allow", "Action":[ "kafka:GetBootstrapBrokers", "kafka:DescribeCluster", "kafka:DescribeClusterV2", "kafka-cluster:Connect" ], "Resource":"arn:aws:kafka:{{mskClusterRegion}}:{{mskClusterAccount}}:cluster/{{mskClusterName}}/{{clusterUUID}}" }, { "Sid":"", "Effect":"Allow", "Action":[ "kafka-cluster:DescribeTopic", "kafka-cluster:DescribeTopicDynamicConfiguration", "kafka-cluster:ReadData" ], "Resource":"arn:aws:kafka:{{mskClusterRegion}}:{{mskClusterAccount}}:topic/{{mskClusterName}}/{{clusterUUID}}/{{mskTopicName}}" }, { "Sid":"", "Effect":"Allow", "Action":[ "kafka-cluster:DescribeGroup" ], "Resource":"arn:aws:kafka:{{mskClusterRegion}}:{{mskClusterAccount}}:group/{{mskClusterName}}/{{clusterUUID}}/*" }

Per ulteriori informazioni su come consentire ad altri AWS servizi di accedere alle tue AWS risorse, consulta Creating a Role to Delegate Permissions to an AWS Service nella IAM User Guide.

Per informazioni su come concedere ad Amazon Data Firehose l'accesso a una destinazione Amazon S3 in un altro account, consulta. Distribuzione multi-account su una destinazione Amazon S3

Concedi ad Amazon Data Firehose l'accesso a una destinazione Amazon Redshift

Fai riferimento a quanto segue quando concedi l'accesso ad Amazon Data Firehose quando utilizzi una destinazione Amazon Redshift.

Ruolo IAM e policy di accesso

Quando utilizzi una destinazione Amazon Redshift, Amazon Data Firehose invia i dati al tuo bucket S3 come posizione intermedia. Facoltativamente, può utilizzare qualsiasi AWS KMS chiave di tua proprietà per la crittografia dei dati. Amazon Data Firehose carica quindi i dati dal bucket S3 al cluster con provisioning di Amazon Redshift o al gruppo di lavoro Serverless Amazon Redshift. Se la registrazione degli errori è abilitata, Amazon Data Firehose invia anche gli errori di consegna dei dati al gruppo di log e CloudWatch ai flussi. Amazon Data Firehose utilizza il nome utente e la password Amazon Redshift specificati per accedere al cluster o al gruppo di lavoro Amazon Redshift Serverless forniti e utilizza un ruolo IAM per accedere al bucket, alla chiave, al gruppo di log e ai flussi specificati. CloudWatch È necessario disporre di un ruolo IAM durante la creazione di uno stream Firehose.

Utilizza la seguente politica di accesso per consentire ad Amazon Data Firehose di accedere al tuo bucket e alla tua chiave S3. AWS KMS Se non possiedi il bucket S3, aggiungilo s3:PutObjectAcl all'elenco delle azioni Amazon S3, che garantiscono al proprietario del bucket l'accesso completo agli oggetti forniti da Amazon Data Firehose. Questa policy ha anche un'istruzione che permette l'accesso a flusso di dati Amazon Kinesis. Se non utilizzi Kinesis Data Firehose come origine dati, puoi rimuovere questa istruzione.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:region:account-id:key/key-id" ], "Condition": { "StringEquals": { "kms:ViaService": "s3.region.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::bucket-name/prefix*" } } }, { "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards" ], "Resource": "arn:aws:kinesis:region:account-id:stream/stream-name" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:region:account-id:log-group:log-group-name:log-stream:log-stream-name" ] }, { "Effect": "Allow", "Action": [ "lambda:InvokeFunction", "lambda:GetFunctionConfiguration" ], "Resource": [ "arn:aws:lambda:region:account-id:function:function-name:function-version" ] } ] }

Per ulteriori informazioni su come consentire ad altri AWS servizi di accedere alle tue AWS risorse, consulta Creating a Role to Delegate Permissions to an Service nella IAM User Guide. AWS

Accesso VPC a un cluster con provisioning Amazon Redshift o a un gruppo di lavoro Amazon Redshift serverless

Se il cluster con provisioning Amazon Redshift o il gruppo di lavoro Amazon Redshift serverless si trova in un cloud virtuale privato (VPC), deve essere accessibile pubblicamente con un indirizzo IP pubblico. Inoltre, concedi ad Amazon Data Firehose l'accesso al tuo cluster fornito di Amazon Redshift o al gruppo di lavoro Amazon Redshift Serverless sbloccando gli indirizzi IP di Amazon Data Firehose. Amazon Data Firehose attualmente utilizza un blocco CIDR per ogni regione disponibile:

  • 13.58.135.96/27 per Stati Uniti orientali (Ohio)

  • 52.70.63.192/27 per Stati Uniti orientali (Virginia settentrionale)

  • 13.57.135.192/27 per Stati Uniti occidentali (California settentrionale)

  • 52.89.255.224/27 per Stati Uniti occidentali (Oregon)

  • 18.253.138.96/27per AWS GovCloud (Stati Uniti orientali)

  • 52.61.204.160/27per AWS GovCloud (Stati Uniti occidentali)

  • 35.183.92.128/27 per Canada (Centrale)

  • 40.176.98.192/27per il Canada occidentale (Calgary)

  • 18.162.221.32/27 per Asia Pacifico (Hong Kong)

  • 13.232.67.32/27 per Asia Pacifico (Mumbai)

  • 18.60.192.128/27 per Asia Pacifico (Hyderabad)

  • 13.209.1.64/27 per Asia Pacifico (Seoul)

  • 13.228.64.192/27 per Asia Pacifico (Singapore)

  • 13.210.67.224/27 per Asia Pacifico (Sydney)

  • 108.136.221.64/27 per Asia Pacifico (Giacarta)

  • 13.113.196.224/27 per Asia Pacifico (Tokyo)

  • 13.208.177.192/27 per Asia Pacifico (Osaka-Locale)

  • 52.81.151.32/27 per Cina (Pechino)

  • 161.189.23.64/27 per Cina (Ningxia)

  • 16.62.183.32/27 per Europa (Zurigo)

  • 35.158.127.160/27 per Europa (Francoforte)

  • 52.19.239.192/27 per Europa (Irlanda)

  • 18.130.1.96/27 per Europa (Londra)

  • 35.180.1.96/27 per Europa (Parigi)

  • 13.53.63.224/27 per Europa (Stoccolma)

  • 15.185.91.0/27 per Medio Oriente (Bahrein)

  • 18.228.1.128/27 per Sud America (San Paolo)

  • 15.161.135.128/27 per Europa (Milano)

  • 13.244.121.224/27 per Africa (Città del Capo)

  • 3.28.159.32/27 per Medio Oriente (Emirati Arabi Uniti)

  • 51.16.102.0/27 per Israele (Tel Aviv)

  • 16.50.161.128/27 per Asia Pacifico (Melbourne)

Per ulteriori informazioni su come sbloccare gli indirizzi IP, consulta la fase Autorizzare l'accesso al cluster nella guida Guida alle operazioni di base di Amazon Redshift.

Concedi ad Amazon Data Firehose l'accesso a una destinazione di servizio pubblico OpenSearch

Quando utilizzi una destinazione di OpenSearch servizio, Amazon Data Firehose invia i dati al tuo cluster di OpenSearch servizi e contemporaneamente esegue il backup di tutti i documenti non riusciti o di tutti i documenti nel tuo bucket S3. Se la registrazione degli errori è abilitata, Amazon Data Firehose invia anche gli errori di consegna dei dati al gruppo di log e CloudWatch ai flussi. Amazon Data Firehose utilizza un ruolo IAM per accedere al dominio di OpenSearch servizio, al bucket S3, alla AWS KMS chiave, al gruppo di CloudWatch log e ai flussi specificati. È necessario disporre di un ruolo IAM durante la creazione di uno stream Firehose.

Utilizza la seguente politica di accesso per consentire ad Amazon Data Firehose di accedere al tuo bucket S3, al dominio di OpenSearch servizio e alla chiave. AWS KMS Se non possiedi il bucket S3, aggiungilo s3:PutObjectAcl all'elenco delle azioni Amazon S3, che garantiscono al proprietario del bucket l'accesso completo agli oggetti forniti da Amazon Data Firehose. Questa policy ha anche un'istruzione che permette l'accesso a flusso di dati Amazon Kinesis. Se non utilizzi Kinesis Data Firehose come origine dati, puoi rimuovere questa istruzione.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:region:account-id:key/key-id" ], "Condition": { "StringEquals": { "kms:ViaService": "s3.region.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::bucket-name/prefix*" } } }, { "Effect": "Allow", "Action": [ "es:DescribeDomain", "es:DescribeDomains", "es:DescribeDomainConfig", "es:ESHttpPost", "es:ESHttpPut" ], "Resource": [ "arn:aws:es:region:account-id:domain/domain-name", "arn:aws:es:region:account-id:domain/domain-name/*" ] }, { "Effect": "Allow", "Action": [ "es:ESHttpGet" ], "Resource": [ "arn:aws:es:region:account-id:domain/domain-name/_all/_settings", "arn:aws:es:region:account-id:domain/domain-name/_cluster/stats", "arn:aws:es:region:account-id:domain/domain-name/index-name*/_mapping/type-name", "arn:aws:es:region:account-id:domain/domain-name/_nodes", "arn:aws:es:region:account-id:domain/domain-name/_nodes/stats", "arn:aws:es:region:account-id:domain/domain-name/_nodes/*/stats", "arn:aws:es:region:account-id:domain/domain-name/_stats", "arn:aws:es:region:account-id:domain/domain-name/index-name*/_stats", "arn:aws:es:region:account-id:domain/domain-name/" ] }, { "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards" ], "Resource": "arn:aws:kinesis:region:account-id:stream/stream-name" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:region:account-id:log-group:log-group-name:log-stream:log-stream-name" ] }, { "Effect": "Allow", "Action": [ "lambda:InvokeFunction", "lambda:GetFunctionConfiguration" ], "Resource": [ "arn:aws:lambda:region:account-id:function:function-name:function-version" ] } ] }

Per ulteriori informazioni su come consentire ad altri AWS servizi di accedere alle tue AWS risorse, consulta Creating a Role to Delegate Permissions to an Service nella IAM User Guide. AWS

Per informazioni su come concedere ad Amazon Data Firehose l'accesso a un cluster di OpenSearch servizi in un altro account, consulta. Distribuzione tra più account a una OpenSearch destinazione di servizio

Concedi ad Amazon Data Firehose l'accesso a una destinazione di OpenSearch servizio in un VPC

Se il tuo dominio di OpenSearch servizio si trova in un VPC, assicurati di concedere ad Amazon Data Firehose le autorizzazioni descritte nella sezione precedente. Inoltre, devi concedere ad Amazon Data Firehose le seguenti autorizzazioni per consentirgli di accedere al VPC del tuo dominio di OpenSearch servizio.

  • ec2:DescribeVpcs

  • ec2:DescribeVpcAttribute

  • ec2:DescribeSubnets

  • ec2:DescribeSecurityGroups

  • ec2:DescribeNetworkInterfaces

  • ec2:CreateNetworkInterface

  • ec2:CreateNetworkInterfacePermission

  • ec2:DeleteNetworkInterface

Importante

Non revocare queste autorizzazioni dopo aver creato il flusso di consegna. Se revochi queste autorizzazioni, il tuo stream Firehose verrà danneggiato o smetterà di fornire dati al tuo dominio di servizio ogni volta che il OpenSearch servizio tenta di interrogare o aggiornare gli ENI.

Importante

Quando specifichi delle sottoreti per la consegna dei dati alla destinazione in un VPC privato, assicurati di avere un numero sufficiente di indirizzi IP liberi nelle sottoreti scelte. Se non è disponibile un indirizzo IP gratuito in una sottorete specificata, Firehose non può creare o aggiungere ENI per la consegna dei dati nel VPC privato e la consegna verrà compromessa o avrà esito negativo.

Quando crei o aggiorni il tuo flusso di distribuzione, specifichi un gruppo di sicurezza che Firehose deve utilizzare per inviare dati al tuo dominio di OpenSearch servizio. È possibile utilizzare lo stesso gruppo di sicurezza utilizzato dal dominio del OpenSearch Servizio o uno diverso. Se specifichi un gruppo di sicurezza diverso, assicurati che consenta il traffico HTTPS in uscita al gruppo di sicurezza del dominio del OpenSearch servizio. Assicuratevi inoltre che il gruppo di sicurezza del dominio di OpenSearch servizio consenta il traffico HTTPS proveniente dal gruppo di sicurezza specificato al momento della configurazione dello stream Firehose. Se utilizzi lo stesso gruppo di sicurezza sia per lo stream Firehose che per il dominio di OpenSearch servizio, assicurati che la regola in entrata del gruppo di sicurezza consenta il traffico HTTPS. Per ulteriori informazioni sulle regole dei gruppi di sicurezza, consulta Regole del gruppo di sicurezza nella documentazione di Amazon VPC.

Concedi ad Amazon Data Firehose l'accesso a una destinazione pubblica senza server OpenSearch

Quando utilizzi una destinazione OpenSearch Serverless, Amazon Data Firehose invia i dati alla OpenSearch tua raccolta Serverless ed esegue contemporaneamente il backup di tutti i documenti non riusciti o di tutti i documenti nel tuo bucket S3. Se la registrazione degli errori è abilitata, Amazon Data Firehose invia anche gli errori di consegna dei dati al gruppo di log e CloudWatch ai flussi. Amazon Data Firehose utilizza un ruolo IAM per accedere alla raccolta OpenSearch Serverless, al bucket S3, alla AWS KMS chiave, al gruppo di log e CloudWatch ai flussi specificati. È necessario disporre di un ruolo IAM durante la creazione di uno stream Firehose.

Utilizza la seguente politica di accesso per consentire ad Amazon Data Firehose di accedere al tuo bucket S3, al dominio OpenSearch Serverless e alla chiave. AWS KMS Se non possiedi il bucket S3, aggiungilo s3:PutObjectAcl all'elenco delle azioni Amazon S3, che garantiscono al proprietario del bucket l'accesso completo agli oggetti forniti da Amazon Data Firehose. Questa policy ha anche un'istruzione che permette l'accesso a flusso di dati Amazon Kinesis. Se non utilizzi Kinesis Data Firehose come origine dati, puoi rimuovere questa istruzione.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:region:account-id:key/key-id" ], "Condition": { "StringEquals": { "kms:ViaService": "s3.region.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::bucket-name/prefix*" } } }, { "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards" ], "Resource": "arn:aws:kinesis:region:account-id:stream/stream-name" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:region:account-id:log-group:log-group-name:log-stream:log-stream-name" ] }, { "Effect": "Allow", "Action": [ "lambda:InvokeFunction", "lambda:GetFunctionConfiguration" ], "Resource": [ "arn:aws:lambda:region:account-id:function:function-name:function-version" ] }, { "Effect": "Allow", "Action": "aoss:APIAccessAll", "Resource": "arn:aws:aoss:region:account-id:collection/collection-id" } ] }

Oltre alla politica di cui sopra, devi anche configurare Amazon Data Firehose in modo che in una policy di accesso ai dati vengano assegnate le seguenti autorizzazioni minime:

[ { "Rules":[ { "ResourceType":"index", "Resource":[ "index/target-collection/target-index" ], "Permission":[ "aoss:WriteDocument", "aoss:UpdateIndex", "aoss:CreateIndex" ] } ], "Principal":[ "arn:aws:sts::account-id:assumed-role/firehose-delivery-role-name/*" ] } ]

Per ulteriori informazioni su come consentire ad altri AWS servizi di accedere alle tue AWS risorse, consulta Creating a Role to Delegate Permissions to an AWS Service nella IAM User Guide.

Concedi ad Amazon Data Firehose l'accesso a una destinazione OpenSearch serverless in un VPC

Se la tua raccolta OpenSearch Serverless è in un VPC, assicurati di concedere ad Amazon Data Firehose le autorizzazioni descritte nella sezione precedente. Inoltre, devi concedere ad Amazon Data Firehose le seguenti autorizzazioni per consentirgli di accedere al VPC della tua OpenSearch collezione Serverless.

  • ec2:DescribeVpcs

  • ec2:DescribeVpcAttribute

  • ec2:DescribeSubnets

  • ec2:DescribeSecurityGroups

  • ec2:DescribeNetworkInterfaces

  • ec2:CreateNetworkInterface

  • ec2:CreateNetworkInterfacePermission

  • ec2:DeleteNetworkInterface

Importante

Non revocare queste autorizzazioni dopo aver creato il flusso di distribuzione. Se revochi queste autorizzazioni, il tuo stream Firehose verrà danneggiato o smetterà di fornire dati al tuo dominio di servizio ogni volta che il OpenSearch servizio tenta di interrogare o aggiornare gli ENI.

Importante

Quando specifichi delle sottoreti per la consegna dei dati alla destinazione in un VPC privato, assicurati di avere un numero sufficiente di indirizzi IP liberi nelle sottoreti scelte. Se non è disponibile un indirizzo IP gratuito in una sottorete specificata, Firehose non può creare o aggiungere ENI per la consegna dei dati nel VPC privato e la consegna verrà compromessa o avrà esito negativo.

Quando si crea o si aggiorna il flusso di distribuzione, si specifica un gruppo di sicurezza da utilizzare per l'invio di dati alla raccolta Serverless da utilizzare per l'invio di dati alla raccolta OpenSearch Serverless. È possibile utilizzare lo stesso gruppo di sicurezza utilizzato dalla raccolta OpenSearch Serverless o uno diverso. Se specificate un gruppo di sicurezza diverso, assicuratevi che consenta il traffico HTTPS in uscita al gruppo di sicurezza della raccolta OpenSearch Serverless. Assicuratevi inoltre che il gruppo di sicurezza della collezione OpenSearch Serverless consenta il traffico HTTPS proveniente dal gruppo di sicurezza specificato al momento della configurazione dello stream Firehose. Se utilizzi lo stesso gruppo di sicurezza sia per lo stream Firehose che per la raccolta OpenSearch Serverless, assicurati che la regola in entrata del gruppo di sicurezza consenta il traffico HTTPS. Per ulteriori informazioni sulle regole dei gruppi di sicurezza, consulta Regole del gruppo di sicurezza nella documentazione di Amazon VPC.

Concedi ad Amazon Data Firehose l'accesso a una destinazione Splunk

Quando utilizzi una destinazione Splunk, Amazon Data Firehose fornisce dati all'endpoint Splunk HTTP Event Collector (HEC). Inoltre, esegue il backup di tali dati nel bucket Amazon S3 da te specificato e, facoltativamente, puoi utilizzare una AWS KMS chiave di tua proprietà per la crittografia lato server di Amazon S3. Se la registrazione degli errori è abilitata, Firehose invia gli errori di consegna dei CloudWatch dati ai flussi di log. È possibile utilizzarlo anche AWS Lambda per la trasformazione dei dati.

Se utilizzi un AWS load balancer, assicurati che sia un Classic Load Balancer o un Application Load Balancer. Inoltre, abilita sessioni permanenti basate sulla durata con la scadenza dei cookie disabilitata per Classic Load Balancer e la scadenza è impostata al massimo (7 giorni) per Application Load Balancer. Per informazioni su come eseguire questa operazione, consulta Duration-Based Session Stickiness for Classic Load Balancer o un Application Load Balancer.

Quando crei un flusso di distribuzione, devi avere un ruolo IAM. Firehose assume quel ruolo IAM e ottiene l'accesso al bucket, alla chiave, al gruppo di log e CloudWatch ai flussi specificati.

Utilizza la seguente politica di accesso per consentire ad Amazon Data Firehose di accedere al tuo bucket S3. Se non possiedi il bucket S3, aggiungilo s3:PutObjectAcl all'elenco delle azioni Amazon S3, che garantiscono al proprietario del bucket l'accesso completo agli oggetti forniti da Amazon Data Firehose. Questa policy concede inoltre ad Amazon Data Firehose l'accesso CloudWatch alla registrazione degli errori e AWS Lambda alla trasformazione dei dati. La policy ha anche un'istruzione che permette l'accesso a flusso di dati Amazon Kinesis. Se non utilizzi Kinesis Data Firehose come origine dati, puoi rimuovere questa istruzione. Amazon Data Firehose non utilizza IAM per accedere a Splunk. Per accedere a Splunk, utilizza il token HEC.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:region:account-id:key/key-id" ], "Condition": { "StringEquals": { "kms:ViaService": "s3.region.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::bucket-name/prefix*" } } }, { "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards" ], "Resource": "arn:aws:kinesis:region:account-id:stream/stream-name" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:region:account-id:log-group:log-group-name:log-stream:*" ] }, { "Effect": "Allow", "Action": [ "lambda:InvokeFunction", "lambda:GetFunctionConfiguration" ], "Resource": [ "arn:aws:lambda:region:account-id:function:function-name:function-version" ] } ] }

Per ulteriori informazioni su come consentire ad altri AWS servizi di accedere alle tue AWS risorse, consulta Creating a Role to Delegate Permissions to an AWS Service nella IAM User Guide.

Accesso a Splunk in un VPC

Se la piattaforma Splunk si trova in un VPC, deve essere accessibile pubblicamente con un indirizzo IP pubblico. Inoltre, concedi ad Amazon Data Firehose l'accesso alla tua piattaforma Splunk sbloccando gli indirizzi IP di Amazon Data Firehose. Amazon Data Firehose attualmente utilizza i seguenti blocchi CIDR.

  • 18.216.68.160/27, 18.216.170.64/27, 18.216.170.96/27 per Stati Uniti orientali (Ohio)

  • 34.238.188.128/26, 34.238.188.192/26, 34.238.195.0/26 per Stati Uniti orientali (Virginia settentrionale)

  • 13.57.180.0/26 per Stati Uniti occidentali (California settentrionale)

  • 34.216.24.32/27, 34.216.24.192/27, 34.216.24.224/27 per Stati Uniti occidentali (Oregon)

  • 18.253.138.192/26per AWS GovCloud (Stati Uniti orientali)

  • 52.61.204.192/26per AWS GovCloud (Stati Uniti occidentali)

  • 18.162.221.64/26 per Asia Pacifico (Hong Kong)

  • 13.232.67.64/26 per Asia Pacifico (Mumbai)

  • 13.209.71.0/26 per Asia Pacifico (Seoul)

  • 13.229.187.128/26 per Asia Pacifico (Singapore)

  • 13.211.12.0/26 per Asia Pacifico (Sydney)

  • 13.230.21.0/27, 13.230.21.32/27 per Asia Pacifico (Tokyo)

  • 51.16.102.64/26 per Israele (Tel Aviv)

  • 35.183.92.64/26 per Canada (Centrale)

  • 40.176.98.128/26per il Canada occidentale (Calgary)

  • 18.194.95.192/27, 18.194.95.224/27, 18.195.48.0/27 per Europa (Francoforte)

  • 34.241.197.32/27, 34.241.197.64/27, 34.241.197.96/27 per Europa (Irlanda)

  • 18.130.91.0/26 per Europa (Londra)

  • 35.180.112.0/26 per Europa (Parigi)

  • 13.53.191.0/26 per Europa (Stoccolma)

  • 15.185.91.64/26 per Medio Oriente (Bahrein)

  • 18.228.1.192/26 per Sud America (San Paolo)

  • 15.161.135.192/26 per Europa (Milano)

  • 13.244.165.128/26 per Africa (Città del Capo)

  • 13.208.217.0/26 per Asia Pacifico (Osaka-Locale)

  • 52.81.151.64/26 per Cina (Pechino)

  • 161.189.23.128/26 per Cina (Ningxia)

  • 108.136.221.128/26 per Asia Pacifico (Giacarta)

  • 3.28.159.64/26 per Medio Oriente (Emirati Arabi Uniti)

  • 51.16.102.64/26 per Israele (Tel Aviv)

  • 16.62.183.64/26 per Europa (Zurigo)

  • 18.60.192.192/26 per Asia Pacifico (Hyderabad)

  • 16.50.161.192/26 per Asia Pacifico (Melbourne)

Accesso a Snowflake o all'endpoint HTTP

Non esiste un sottoinsieme di intervalli di indirizzi AWS IP specifici per Amazon Data Firehose quando la destinazione è un endpoint HTTP o Snowflake.

Per aggiungere Amazon Data Firehose a un elenco di indirizzi consentiti nella policy di rete Snowflake o ai tuoi endpoint HTTP o HTTPS pubblici, aggiungi tutti gli intervalli di indirizzi AWS IP correnti alle tue regole di ingresso.

Nota

Le notifiche non provengono sempre da indirizzi IP nella stessa AWS regione dell'argomento associato. È necessario includere l'intervallo di indirizzi AWS IP per tutte le regioni.

Concedi a Firehose l'accesso a una destinazione Snowflake

Quando utilizzi Snowflake come destinazione, Firehose invia i dati a un account Snowflake utilizzando l'URL del tuo account Snowflake. Inoltre, esegue il backup dei dati di errore nel bucket Amazon Simple Storage Service da te specificato e, facoltativamente, puoi utilizzare una AWS Key Management Service chiave di tua proprietà per la crittografia lato server di Amazon S3. Se la registrazione degli errori è abilitata, Firehose invia gli errori di consegna dei CloudWatch dati ai flussi di log.

Quando crei un flusso di distribuzione, devi avere un ruolo IAM. Firehose assume quel ruolo IAM e ottiene l'accesso al bucket, alla chiave, al gruppo e CloudWatch agli stream Logs specificati. Utilizza la seguente politica di accesso per consentire a Firehose di accedere al tuo bucket S3. Se non possiedi il bucket S3, aggiungilo s3:PutObjectAcl all'elenco delle azioni di Amazon Simple Storage Service, che garantiscono al proprietario del bucket l'accesso completo agli oggetti forniti da Firehose. Questa politica concede inoltre a Firehose l'accesso CloudWatch per la registrazione degli errori. La policy ha anche un'istruzione che permette l'accesso a flusso di dati Amazon Kinesis. Se non utilizzi Kinesis Data Firehose come origine dati, puoi rimuovere questa istruzione. Firehose non utilizza IAM per accedere a Snowflake. Per accedere a Snowflake, utilizza l'URL dell'account Snowflake e l'ID PrivateLink Vpce nel caso di un cluster privato.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:region:account-id:key/key-id" ], "Condition": { "StringEquals": { "kms:ViaService": "s3.region.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::bucket-name/prefix*" } } }, { "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards" ], "Resource": "arn:aws:kinesis:region:account-id:stream/stream-name" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:region:account-id:log-group:log-group-name:log-stream:*" ] } ] }

Per ulteriori informazioni su come consentire ad altri AWS servizi di accedere alle tue AWS risorse, consulta Creating a Role to Delegate Permissions to an Service nella IAM User Guide. AWS

Concedi ad Amazon Data Firehose l'accesso a una destinazione endpoint HTTP

Puoi utilizzare Amazon Data Firehose per fornire dati a qualsiasi destinazione di endpoint HTTP. Amazon Data Firehose esegue inoltre il backup di tali dati nel bucket Amazon S3 da te specificato e, facoltativamente, puoi utilizzare AWS KMS una chiave di tua proprietà per la crittografia lato server di Amazon S3. Se la registrazione degli errori è abilitata, Amazon Data Firehose invia gli errori di consegna dei dati ai CloudWatch tuoi flussi di log. Puoi utilizzarlo anche AWS Lambda per la trasformazione dei dati.

È necessario disporre di un ruolo IAM durante la creazione di uno stream Firehose. Amazon Data Firehose assume il ruolo IAM e ottiene l'accesso al bucket, alla chiave, al gruppo di log e CloudWatch ai flussi specificati.

Utilizza la seguente politica di accesso per consentire ad Amazon Data Firehose di accedere al bucket S3 che hai specificato per il backup dei dati. Se non possiedi il bucket S3, aggiungilo s3:PutObjectAcl all'elenco delle azioni Amazon S3, che garantiscono al proprietario del bucket l'accesso completo agli oggetti forniti da Amazon Data Firehose. Questa policy concede inoltre ad Amazon Data Firehose l'accesso CloudWatch alla registrazione degli errori e AWS Lambda alla trasformazione dei dati. La policy ha anche un'istruzione che permette l'accesso a flusso di dati Amazon Kinesis. Se non utilizzi Kinesis Data Firehose come origine dati, puoi rimuovere questa istruzione.

Importante

Amazon Data Firehose non utilizza IAM per accedere alle destinazioni degli endpoint HTTP di proprietà di fornitori di servizi terzi supportati, tra cui Datadog, Dynatrace, LogicMonitor MongoDB, New Relic, Splunk o Sumo Logic. Per accedere a una destinazione endpoint HTTP specificata di proprietà di un fornitore di servizi terzo supportato, contatta tale fornitore di servizi per ottenere la chiave API o la chiave di accesso necessaria per abilitare la consegna dei dati a quel servizio da Amazon Data Firehose.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:region:account-id:key/key-id" ], "Condition": { "StringEquals": { "kms:ViaService": "s3.region.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::bucket-name/prefix*" } } }, { "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards" ], "Resource": "arn:aws:kinesis:region:account-id:stream/stream-name" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:region:account-id:log-group:log-group-name:log-stream:*" ] }, { "Effect": "Allow", "Action": [ "lambda:InvokeFunction", "lambda:GetFunctionConfiguration" ], "Resource": [ "arn:aws:lambda:region:account-id:function:function-name:function-version" ] } ] }

Per ulteriori informazioni su come consentire ad altri AWS servizi di accedere alle tue AWS risorse, consulta Creating a Role to Delegate Permissions to an AWS Service nella IAM User Guide.

Importante

Attualmente Amazon Data Firehose NON supporta la consegna di dati agli endpoint HTTP in un VPC.

Consegna su più account da Amazon MSK

Se il tuo è uno scenario tra più account in cui stai creando un flusso di distribuzione dal tuo account Firehose (ad esempio, Account B) e la tua origine è un cluster MSK in un AWS altro account (Account A), devi avere le seguenti configurazioni:

Account A:

  1. Nella console Amazon MSK scegli il cluster con provisioning, quindi scegli Proprietà.

  2. In Impostazioni di rete, scegli Modifica e attiva Connettività multi-VPC.

  3. In Impostazioni di sicurezza scegli Modifica policy del cluster.

    1. Se il cluster non ha già configurato una policy, seleziona Includi il principale del servizio Firehose e Abilita la distribuzione S3 multi-account Firehose. AWS Management Console Genererà automaticamente una policy con le autorizzazioni appropriate.

    2. Se il cluster ha già una policy configurata, aggiungi le seguenti autorizzazioni alla policy esistente:

      { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::arn:role/mskaasTestDeliveryRole" }, "Action": [ "kafka:GetBootstrapBrokers", "kafka:DescribeCluster", "kafka:DescribeClusterV2", "kafka-cluster:Connect" ], "Resource": "arn:aws:kafka:us-east-1:arn:cluster/DO-NOT-TOUCH-mskaas-provisioned-privateLink/xxxxxxxxx-2f3a-462a-ba09-xxxxxxxxxx-20" // ARN of the cluster }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::arn:role/mskaasTestDeliveryRole" }, "Action": [ "kafka-cluster:DescribeTopic", "kafka-cluster:DescribeTopicDynamicConfiguration", "kafka-cluster:ReadData" ], "Resource": "arn:aws:kafka:us-east-1:arn:topic/DO-NOT-TOUCH-mskaas-provisioned-privateLink/xxxxxxxxx-2f3a-462a-ba09-xxxxxxxxxx-20/*"//topic of the cluster }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::233450236687:role/mskaasTestDeliveryRole" }, "Action": "kafka-cluster:DescribeGroup", "Resource": "arn:aws:kafka:us-east-1:arn:group/DO-NOT-TOUCH-mskaas-provisioned-privateLink/xxxxxxxxx-2f3a-462a-ba09-xxxxxxxxxx-20/*" //topic of the cluster }, }
  4. In Principale AWS , inserisci l'ID principale dell'Account B.

  5. In Argomento, specifica l'argomento di Apache Kafka da cui desideri che il flusso di distribuzione inserisca i dati. Una volta creato il flusso di distribuzione, non è possibile aggiornare questo argomento.

  6. Scegli Salva modifiche.

Account B:

  1. Nella console Firehose, scegliete Crea flusso di distribuzione utilizzando l'account B.

  2. In Origine, scegli Amazon Managed Streaming for Apache Kafka.

  3. In Impostazioni di origine, per il cluster Amazon Managed Streaming for Apache Kafka, inserisci l'ARN del cluster Amazon MSK nell'Account A.

  4. In Argomento, specifica l'argomento di Apache Kafka da cui desideri che il flusso di distribuzione inserisca i dati. Una volta creato il flusso di distribuzione, non è possibile aggiornare questo argomento.

  5. In Nome flusso di distribuzione, specifica il nome per il flusso di distribuzione.

Nell'Account B, quando crei il flusso di distribuzione, devi disporre di un ruolo IAM (creato di default quando utilizzi il AWS Management Console) che conceda al flusso di distribuzione l'accesso in «lettura» al cluster Amazon MSK multiaccount per l'argomento configurato.

Di seguito è riportato ciò che viene configurato dalla AWS Management Console:

{ "Sid": "", "Effect": "Allow", "Action": [ "kafka:GetBootstrapBrokers", "kafka:DescribeCluster", "kafka:DescribeClusterV2", "kafka-cluster:Connect" ], "Resource": "arn:aws:kafka:us-east-1:arn:cluster/DO-NOT-TOUCH-mskaas-provisioned-privateLink/xxxxxxxxx-2f3a-462a-ba09-xxxxxxxxxx-20/*" //topic of the cluster }, { "Sid": "", "Effect": "Allow", "Action": [ "kafka-cluster:DescribeTopic", "kafka-cluster:DescribeTopicDynamicConfiguration", "kafka-cluster:ReadData" ], "Resource": "arn:aws:kafka:us-east-1:arn:topic/DO-NOT-TOUCH-mskaas-provisioned-privateLink/xxxxxxxxx-2f3a-462a-ba09-xxxxxxxxxx-20/mskaas_test_topic" //topic of the cluster }, { "Sid": "", "Effect": "Allow", "Action": [ "kafka-cluster:DescribeGroup" ], "Resource": "arn:aws:kafka:us-east-1:arn:group/DO-NOT-TOUCH-mskaas-provisioned-privateLink/xxxxxxxxx-2f3a-462a-ba09-xxxxxxxxxx-20/*" //topic of the cluster }, }

Successivamente, puoi completare la fase facoltativa di configurazione della trasformazione del record e della conversione del formato del record. Per ulteriori informazioni, consulta Trasformazione dei record e conversione del formato.

Distribuzione multi-account su una destinazione Amazon S3

Puoi utilizzare le AWS CLI API di Amazon Data Firehose per creare uno stream Firehose in un account con una destinazione Amazon S3 in AWS un account diverso. La procedura seguente mostra un esempio di configurazione di uno stream Firehose di proprietà dell'account A per fornire dati a un bucket Amazon S3 di proprietà dell'account B.

  1. Crea un ruolo IAM nell'account A utilizzando i passaggi descritti in Concedere l'accesso a Firehose a una destinazione Amazon S3.

    Nota

    In questo caso il bucket Amazon S3 specificato nella policy di accesso è di proprietà dell'account B. Assicurati di aggiungere s3:PutObjectAcl all'elenco delle azioni di Amazon S3 nella policy di accesso, che garantisce all'account B l'accesso completo agli oggetti forniti da Amazon Data Firehose. Questa autorizzazione è necessaria per la distribuzione multi-account. Amazon Data Firehose imposta l'intestazione x-amz-acl "" della richiesta su "». bucket-owner-full-control

  2. Per consentire l'accesso dal ruolo IAM creato in precedenza, crea una policy del bucket S3 nell'account B. Il codice seguente è un esempio di policy del bucket. Per ulteriori informazioni, consulta Utilizzo delle policy di bucket e delle policy utente.

    { "Version": "2012-10-17", "Id": "PolicyID", "Statement": [ { "Sid": "StmtID", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::accountA-id:role/iam-role-name" }, "Action": [ "s3:AbortMultipartUpload", "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] } ] }
  3. Crea uno stream Firehose nell'account A utilizzando il ruolo IAM creato nel passaggio 1.

Distribuzione tra più account a una OpenSearch destinazione di servizio

Puoi utilizzare le AWS CLI API di Amazon Data Firehose per creare uno stream Firehose in un AWS account con una destinazione del OpenSearch servizio in un account diverso. La procedura seguente mostra un esempio di come è possibile creare uno stream Firehose con l'account A e configurarlo per fornire dati a una destinazione del OpenSearch servizio di proprietà dell'account B.

  1. Crea un ruolo IAM nell'account A utilizzando le fasi descritte in Concedi ad Amazon Data Firehose l'accesso a una destinazione di servizio pubblico OpenSearch .

  2. Per consentire l'accesso dal ruolo IAM creato nel passaggio precedente, crea una policy di OpenSearch servizio nell'account B. Il seguente JSON è un esempio.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::Account-A-ID:role/firehose_delivery_role " }, "Action": "es:ESHttpGet", "Resource": [ "arn:aws:es:us-east-1:Account-B-ID:domain/cross-account-cluster/_all/_settings", "arn:aws:es:us-east-1:Account-B-ID:domain/cross-account-cluster/_cluster/stats", "arn:aws:es:us-east-1:Account-B-ID:domain/cross-account-cluster/roletest*/_mapping/roletest", "arn:aws:es:us-east-1:Account-B-ID:domain/cross-account-cluster/_nodes", "arn:aws:es:us-east-1:Account-B-ID:domain/cross-account-cluster/_nodes/stats", "arn:aws:es:us-east-1:Account-B-ID:domain/cross-account-cluster/_nodes/*/stats", "arn:aws:es:us-east-1:Account-B-ID:domain/cross-account-cluster/_stats", "arn:aws:es:us-east-1:Account-B-ID:domain/cross-account-cluster/roletest*/_stats", "arn:aws:es:us-east-1:Account-B-ID:domain/cross-account-cluster/" ] } ] }
  3. Crea uno stream Firehose nell'account A utilizzando il ruolo IAM creato nel passaggio 1. Quando crei lo stream Firehose, usa AWS CLI o le API di Amazon Data Firehose e specifica il ClusterEndpoint campo anziché Service. DomainARN OpenSearch

Nota

Per creare uno stream Firehose in un AWS account con una destinazione del OpenSearch servizio in un account diverso, devi utilizzare le API AWS CLI o le API di Amazon Data Firehose. Non è possibile utilizzare il AWS Management Console per creare questo tipo di configurazione tra account.

Utilizzo dei tag per controllare l'accesso

Puoi utilizzare l'Conditionelemento (o Condition blocco) opzionale in una policy IAM per ottimizzare l'accesso alle operazioni di Amazon Data Firehose in base a chiavi e valori dei tag. Le seguenti sottosezioni descrivono come eseguire questa operazione per le diverse operazioni di Amazon Data Firehose. Per ulteriori informazioni sull'utilizzo dell'elemento Condition e degli operatori che puoi utilizzare al suo interno, consulta Elementi della policy JSON di IAM: condizione.

CreateDeliveryStream

Per l'operazione CreateDeliveryStream, utilizza la chiave di condizione aws:RequestTag. Nel seguente esempio, MyKey e MyValue rappresentano la chiave e il valore corrispondente del tag. Per ulteriori informazioni, consultare Nozioni di base sui tag

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "firehose:CreateDeliveryStream", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/MyKey": "MyValue" } } } ] }

TagDeliveryStream

Per l'operazione TagDeliveryStream, utilizza la chiave di condizione aws:TagKeys. Nel seguente esempio, MyKey è un esempio di chiave di tag.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "firehose:TagDeliveryStream", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:TagKeys": "MyKey" } } } ] }

UntagDeliveryStream

Per l'operazione UntagDeliveryStream, utilizza la chiave di condizione aws:TagKeys. Nel seguente esempio, MyKey è un esempio di chiave di tag.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "firehose:UntagDeliveryStream", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:TagKeys": "MyKey" } } } ] }

ListDeliveryStreams

Non puoi utilizzare il controllo degli accessi basato su tag con ListDeliveryStreams.

Altre operazioni di Amazon Data Firehose

Per tutte le operazioni di Amazon Data Firehose diverse daCreateDeliveryStream,TagDeliveryStream, e UntagDeliveryStreamListDeliveryStreams, usa la chiave di aws:RequestTag condizione. Nel seguente esempio, MyKey e MyValue rappresentano la chiave e il valore corrispondente del tag.

ListDeliveryStreams, utilizzate il tasto firehose:ResourceTag condition per controllare l'accesso in base ai tag di quel flusso Firehose.

Nel seguente esempio, MyKey e MyValue rappresentano la chiave e il valore corrispondente del tag. La policy si applicherebbe solo ai flussi Data Firehose con un tag denominato MyKey con un valore di. MyValue Per ulteriori informazioni sul controllo dell'accesso in base ai tag delle risorse, consulta Controlling access to AWS resources using tags nella IAM User Guide.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "firehose:DescribeDeliveryStream", "Resource": "*", "Condition": { "StringEquals": { "firehose:ResourceTag/MyKey": "MyValue" } } } ] }