AWS -Kinesis-Agent в пользовательском AMI и локально: маркер безопасности, включенный в запрос, недействителен - PullRequest
Новая
       11

AWS -Kinesis-Agent в пользовательском AMI и локально: маркер безопасности, включенный в запрос, недействителен

0 голосов
/ 27 марта 2020

Я надеюсь, что кто-то может помочь мне в этом, поскольку я довольно плохо знаком с Kinesis Firehose и агентом Firehose.

Я скомпилировал kinesis-agent для локального сервера Debian и экземпляра ec2 (в тестовой учетной записи aws). В отдельной учетной записи aws я создал Kinesis Stream и указал его на домен AWSasticsearch (Monitoring AWS ACCOUNT).

Я создал пользователя (kinesistestagent) в AWS Monitoring добавлена ​​учетная запись, у которой есть доступ к потоку пожарных шлангов Kinesis, и добавлена ​​правильная роль STS (я застрял на ней несколько дней, поскольку она даже не могла бы аутентифицироваться), чтобы агент Kinesis мог проходить аутентификацию в потоке пожарного шланга и отправлять свои данные.

Мой агент. json Файл для Kinesis выглядит следующим образом. Я попытался сократить его, чтобы просто попытаться передать данные в firehose иasticsearch ... 

{
        "checkpointFile": "/opt/aws-kinesis-agent/run/checkpoints",
        "cloudwatch.endpoint": "https://monitoring.eu-west-2.amazonaws.com",
        "cloudwatch.emitMetrics": "false",
        "firehose.endpoint": "https://firehose.eu-west-2.amazonaws.com",
        "assumeRoleExternalId" :"arn:aws:firehose:eu-west-2:117215238277453:deliverystream/TEST-Firehose-EKK",
        "awsAccessKeyId": "AKIRADXQWUX45KCM2IKB",
        "awsSecretAccessKey": "bpq7KdidkfkeodmadeuppaccessZg4BL",
                "flows": [
                        {
                        "filePattern": "/data/log/server.log",
                        "initialPosition": "END_OF_FILE",
                        "deliveryStream": "TEST-Firehose-EKK"
                        }
               ]
}

Поскольку мои linux экземпляры не являются Amazon AMI, я явно использовал значения авторизации "awsAccessKeyId" и "awsSecretAccessKey".

Точная ошибка, которую я получаю из журналов, состоит в том, что аутентификация работает, но маркер безопасности в запросе недействителен? 

2020-03-26 23:00:00.088+0000  (sender-2318) com.amazon.kinesis.streaming.agent.tailing.AsyncPublisher [ERROR] AsyncPublisher[fh:TEST-Firehose-EKK:/data/log/server.log]:RecordBuffer(id=2,records=179,bytes=36161) Retriable send error (com.amazonaws.services.kinesisfirehose.model.AmazonKinesisFirehoseException: The security token included in the request is invalid. (Service: AmazonKinesisFirehose; Status Code: 400; Error Code: UnrecognizedClientException; Request ID: db4f7c53-e4a0-17e0-8db8-4a638f74b5fb)). Will retry.

Вот так выглядит вся транзакция в журнале кинезиса. 

2020-03-26 22:59:59.574+0000  (FileTailer[fh:TEST-Firehose-EKK:/data/log/server.log].MetricsEmitter RUNNING) com.amazon.kinesis.streaming.agent.tailing.FileTailer [INFO] FileTailer[fh:TEST-Firehose-EKK:/data/log/server.log]: Tailer Progress: Tailer has parsed 179 records (997399 bytes), transformed 0 records, skipped 0 records, and has successfully sent 0 records to destination.
2020-03-26 22:59:59.581+0000  (Agent.MetricsEmitter RUNNING) com.amazon.kinesis.streaming.agent.Agent [INFO] Agent: Progress: 179 records parsed (997399 bytes), and 0 records sent successfully to destinations. Uptime: 23790134ms
2020-03-26 23:00:00.058+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG] connecting to firehose.eu-west-2.amazonaws.com/52.94.49.83:443
2020-03-26 23:00:00.059+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG] Connecting socket to firehose.eu-west-2.amazonaws.com/52.94.49.83:443 with timeout 10000
2020-03-26 23:00:00.060+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG] Enabled protocols: [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1]
2020-03-26 23:00:00.060+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG] Enabled cipher suites:[TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
2020-03-26 23:00:00.061+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG] socket.getSupportedProtocols(): [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3, SSLv2Hello], socket.getEnabledProtocols(): [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1]
2020-03-26 23:00:00.061+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG] TLS protocol enabled for SSL handshake: [TLSv1.2, TLSv1.1, TLSv1, TLSv1.3]
2020-03-26 23:00:00.061+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG] Starting handshake
2020-03-26 23:00:00.070+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG] Secure session established
2020-03-26 23:00:00.070+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG]  negotiated protocol: TLSv1.2
2020-03-26 23:00:00.070+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG]  negotiated cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
2020-03-26 23:00:00.070+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG]  peer principal: CN=firehose.eu-west-2.amazonaws.com
2020-03-26 23:00:00.070+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG]  peer alternative names: [*.firehose.eu-west-2.vpce.amazonaws.com, firehose.eu-west-2.amazonaws.com]
2020-03-26 23:00:00.070+0000  (sender-2318) com.amazonaws.http.conn.ssl.SdkTLSSocketFactory [DEBUG]  issuer principal: CN=Amazon, OU=Server CA 1B, O=Amazon, C=US
2020-03-26 23:00:00.088+0000  (sender-2318) com.amazon.kinesis.streaming.agent.tailing.AsyncPublisher [ERROR] AsyncPublisher[fh:TEST-Firehose-fEKK:/data/log/server.log]:RecordBuffer(id=2,records=179,bytes=36161) Retriable send error (com.amazonaws.services.kinesisfirehose.model.AmazonKinesisFirehoseException: The security token included in the request is invalid. (Service: AmazonKinesisFirehose; Status Code: 400; Error Code: UnrecognizedClientException; Request ID: db4f7c53-e4a0-17e0-8db8-4a638f74b5fb)). Will retry.

Кто-нибудь сталкивался с этой ошибкой раньше, или кому-то удалось заставить AWS Kinesis Agent работать на Prem Server?

Заранее большое спасибо за то, что прочитали мою проблему, и любая помощь или совет будут с благодарностью приняты.

ура

1 Ответ

0 голосов
/ 26 апреля 2020

Наконец-то решена моя проблема ..

Когда я создал пользователя Kinesis, который может получить доступ к потоку с помощью AWSAccessKeyID и AWSSECRET, я фактически не принимаю на себя никаких ролей. Принимая эту строку, все работает.

Мне пришлось использовать один или другой, а не оба.

Я надеюсь, что кто-то может помочь мне в этом, так как я довольно новичок в Kinesis FireHose и агенте FireHose.

Я скомпилировал Kinesis-Agent для своего локального сервера Debian и экземпляра Debian EC2. (в тестовом aws аккаунте). В отдельной учетной записи aws я создал Kinesis Stream и указал его на домен AWSasticsearch (Monitoring AWS ACCOUNT).

Я создал пользователя (kinesistestagent) в AWS Monitoring добавлена ​​учетная запись, у которой есть доступ к потоку пожарных шлангов kinesis и правильная роль STS (я застрял на ней несколько дней, поскольку она даже не могла бы аутентифицироваться), чтобы агент kinesis мог проходить аутентификацию с потоком пожарного шланга и отправлять свои данные.

Мой агент. json Файл для кинезиса выглядит следующим образом. Я пытался раздеть это, чтобы просто попытаться получить данные в firehose иasticsearch ... 

{
        "checkpointFile": "/opt/aws-kinesis-agent/run/checkpoints",
        "cloudwatch.endpoint": "https://monitoring.eu-west-2.amazonaws.com",
        "cloudwatch.emitMetrics": "false",
        "firehose.endpoint": "https://firehose.eu-west-2.amazonaws.com",
        "awsAccessKeyId": "AKIRADXQWUSX45KCM2IKB",
        "awsSecretAccessKey": "bpq7KdidfkfkemadeuppaccessZg4BL",
                "flows": [
                        {
                        "filePattern": "/data/log/server.log",
                        "initialPosition": "END_OF_FILE",
                        "deliveryStream": "TEST-Firehose-EKK"
                        }
               ]
}
...