KK
05/24/2021, 11:43 AMError initializing service: initializing osquery logging: create firehose status logger: create Firehose writer: describe stream arn:aws:firehose:xx:xx:deliverystream/test_stream: NoCredentialProviders: no valid providers in chain. Deprecated.
My assumption is that the ECS task will first assume the role provided in FLEET_FIREHOSE_STS_ASSUME_ROLE_ARN
using its default credential, which would be the ECS task role that it was configured to run with. Once assumed, the task will then be able to call DescribeDeliveryStream
using the newly granted role. However, based on the code here, my guess is that the task could not find the default credentials(?). I'd like to avoid passing the access keys to the task, could anyone please take a look and see where I went wrong?
These are the environment variables/actions that I have configured so far:
• `FLEET_OSQUERY_RESULT_LOG_PLUGIN`: firehose
• `FLEET_OSQUERY_STATUS_LOG_PLUGIN`: firehose
• FLEET_FIREHOSE_REGION
: xx
• FLEET_FIREHOSE_RESULT_STREAM
: arn:aws:firehose:xx:xx:deliverystream/test_stream
• FLEET_FIREHOSE_STATUS_STREAM
: arn:aws:firehose:xx:xx:deliverystream/test_stream
• FLEET_FIREHOSE_STS_ASSUME_ROLE_ARN
: arn:aws:iam:xx:role/firehoseRole
• An ECS task role permission to assume the role arn:aws:iam:xx:role/firehoseRole
• A new IAM role arn:aws:iam:xx:role/firehoseRole
with permissions to call firehose:DescribeDeliveryStream
and firehose:PutRecordBatch
against arn:aws:firehose:xx:xx:deliverystream/test_stream
zwass
05/24/2021, 3:17 PMnyanshak
05/24/2021, 3:21 PMKK
05/24/2021, 3:46 PMCannotPullContainerError: ref pull has been retried 1 time(s): failed to copy: httpReaderSeeker: failed open: unexpected status code <https://registry-1.docker.io/v2/fleetdm/fleet/manifests/sha256:a6694d267a20c0f656304c6392efbec9f9bb88a2499f61c0e6f0dab2>...
and
CannotPullContainerError: inspect image has been retried 5 time(s): httpReaderSeeker: failed open: unexpected status code <https://registry-1.docker.io/v2/fleetdm/fleet/manifests/sha256:a6694d267a20c0f656304c6392efbec9f9bb88a2499f61c0e6f0dab25e993a20>: 4...
Has anyone encountered the issue before? My tasks run on a private subnet with a route to a NAT gateway. My execution role and role policy follow what was suggested by AWS:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"<http://ecs-tasks.amazonaws.com|ecs-tasks.amazonaws.com>"
]
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
Zach Zeid
05/24/2021, 4:46 PMKK
05/24/2021, 4:49 PMfirehose:DescribeDeliveryStream
and firehose:PutRecordBatch
permissions directly in the ECS task role. The task role still contains the permission to assume the firehoseRole
role that grants the same permission, which likely is redundant. I'm now looking into whether I can completely do without the firehoseRole and point FLEET_FIREHOSE_STS_ASSUME_ROLE_ARN
directly to the ECS task role.nyanshak
05/24/2021, 5:43 PMFLEET_FIREHOSE_STS_ASSUME_ROLE_ARN
entirely.KK
05/24/2021, 6:18 PM