Hi all,
I'm currently testing Cribl's AWS Cloud Connections feature to onboard AWS logging sources across multiple accounts within an AWS Organization.
I've followed the organization-wide deployment process:
-
Created an Organization Root connection in Cribl.
-
Deployed the generated CloudFormation template in the AWS Management account to establish organization-wide discovery.
-
Successfully discovered S3 logging buckets in member accounts.
-
Selected an existing S3 bucket and generated the integration CloudFormation template.
-
Deployed that template in the member account (Log Archive), which successfully created the IAM ingestion role, SQS queue and associated policies.
The issue:
Cribl automatically generates the S3 Source's AssumeRoleArn using the Management account ID, rather than the member account ID where the IAM role was deployed.
For example:
-
Management account:
111111111111 -
Log Archive account:
222222222222 -
Actual IAM role:
arn:aws:iam::222222222222:role/CriblInputRole-example -
Cribl-generated ARN:
arn:aws:iam::111111111111:role/CriblInputRole-example
This results in sts:AssumeRole failures when Cribl attempts to connect to the SQS queue.
I've reproduced the same behaviour across two separate AWS Organizations, using newly generated CloudFormation templates.
The IAM role's trust policy and permissions appear correct, and the generated External ID matches. The issue seems to be how Cribl determines the AWS account ID when generating the Source configuration.
Has anyone successfully deployed AWS Cloud Connections using the Organization Root approach across multiple AWS accounts?
If so, did the onboarding process correctly generate the AssumeRole ARNs for resources in member accounts, or did you have to manually correct them?
I'm trying to establish whether I've missed something in the deployment process or whether this is a limitation/bug in the organization-wide onboarding workflow.
Documentation: https://docs.cribl.io/stream/aws-cloud-connections/
Any insights would be appreciated!
