[CIS AWS] Multiple AssumeRole errors

[orouz]

Describe the bug

noticed these errors in 8.14 BC4 (see https://github.com/elastic/security-team/issues/9427#issuecomment-2112533090)

 Error fetching AWS Config recorders: operation error Config Service: DescribeConfigurationRecorders, get identity: get credentials: failed to refresh cached credentials, operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: f08d1b32-c6ff-41f1-8357-07819eefa3ab, api error AccessDenied: User: arn:aws:sts::378890115541:assumed-role/cloudbeat-root/aws-go-sdk-1715607180126994429 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::049528901747:role/cloudbeat-securityaudit  

failed to describe config recorders: fail to retrieve aws resources for region: us-east-1, error: operation error Config Service: DescribeConfigurationRecorders, get identity: get credentials: failed to refresh cached credentials, operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: f08d1b32-c6ff-41f1-8357-07819eefa3ab, api error AccessDenied: User: arn:aws:sts::378890115541:assumed-role/cloudbeat-root/aws-go-sdk-1715607180126994429 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::049528901747:role/cloudbeat-securityaudit 

Unable to fetch IAM users, error: operation error IAM: ListUsers, get identity: get credentials: failed to refresh cached credentials, operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: f08d1b32-c6ff-41f1-8357-07819eefa3ab, api error AccessDenied: User: arn:aws:sts::378890115541:assumed-role/cloudbeat-root/aws-go-sdk-1715607180126994429 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::049528901747:role/cloudbeat-securityaudit 

failed to describe security hub: fail to retrieve aws resources for region: us-east-1, error: operation error SecurityHub: DescribeHub, get identity: get credentials: failed to refresh cached credentials, operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: f08d1b32-c6ff-41f1-8357-07819eefa3ab, api error AccessDenied: User: arn:aws:sts::378890115541:assumed-role/cloudbeat-root/aws-go-sdk-1715607180126994429 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::049528901747:role/cloudbeat-securityaudit 

failed to load some DB instances from rds: fail to retrieve aws resources for region: us-east-1, error: operation error RDS: DescribeDBInstances, get identity: get credentials: failed to refresh cached credentials, operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: e0be65f1-5148-4bfb-8b09-d1a5a6c65fbd, api error AccessDenied: User: arn:aws:sts::378890115541:assumed-role/cloudbeat-root/aws-go-sdk-1715607180126994429 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::049528901747:role/cloudbeat-securityaudit,  

failed to describe trails: operation error CloudTrail: DescribeTrails, get identity: get credentials: failed to refresh cached credentials, operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: e0be65f1-5148-4bfb-8b09-d1a5a6c65fbd, api error AccessDenied: User: arn:aws:sts::378890115541:assumed-role/cloudbeat-root/aws-go-sdk-1715607180126994429 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::049528901747:role/cloudbeat-securityaudit 

Preconditions
Run CSPM AWS

To Reproduce
Write the exact actions one should perform in order to reproduce the bug.
Steps to reproduce the behavior:

Add CSPM AWS Integration
Search logs for AssumeRole

Expected behavior
No access denied errors

[kubasobon]

My 2 cents. The errors are baked into our assumption about how we perform the scan. We use StackSets to create cloudbeat-securityaudit roles in accounts/OUs selected by the user. Cloudbeat is not aware of the roles' existence and simply tries to assume the role in every sub-account and OU, naively and best effort style. If the role exists (because the account was chosen and CF SubStacks created it), great the account is scanned. Otherwise we see the 403 error mentioned in this ticket and move on.

We could take a couple of different approaches:

• simply silence the 403 errors, which I think is a bit risky
• make Cloudbeat aware of the chosen accounts/OUs somehow, so that it can scan only the ones users picked
• make Cloudbeat list all accounts, look-up roles, and then limit fetches only to the accounts where appropriate role exists

[kubasobon]

Related (possible duplicate): #2331