fix(lwpreflight): add S3 tagging and inline-policy reads to AWS lists

[lokesh-vadlamudi]

Jira/Github ticket

https://lacework.atlassian.net/browse/CAD-2300

Summary

Two gaps in the AWS preflight required-permission lists, found while verifying that roles holding exactly these lists can deploy and destroy every AWS integration.

s3:TagResource and s3:ListTagsForResource. Newer aws provider versions pass bucket tags inside CreateBucket and read them back with ListTagsForResource. When the role lacks those actions the provider falls back to PutBucketTagging / GetBucketTagging, so onboarding still succeeds, but every EKS Audit Log deployment leaves AccessDenied entries in the customer's CloudTrail for a role we told them was sufficient. Added to every list that already tags buckets: Agentless, CloudTrail and EKS Audit Log, single-account and org. Config org creates its bucket untagged but the provider still reads tags on refresh, so it gets s3:ListTagsForResource only.

iam:GetRolePolicy and iam:GetUserPolicy for EKS Audit Log. Preflight reads the caller's own policies (policy.go): attached policies via GetPolicy/GetPolicyVersion, inline ones via GetRolePolicy (roles) or GetUserPolicy (users). The other three integrations require both; EKS never did, so a principal granted through an inline policy failed preflight before terraform ran. Added to both EKS lists.

Data-only change in lwpreflight/aws/constants.go.

How did you test this change?

QAN, CAD team account, one IAM role per integration with a single customer-managed policy equal to the go-sdk single-account list. Each role authorized, passed Discovery, deployed (deployments 500 Config, 501 CloudTrail, 502 Agentless, 503 EKS Audit Log) and then deleted the integration with resource destroy. CloudTrail for the four role sessions shows no terraform AccessDenied; the only denials were the two S3 tagging actions on the EKS run (tolerated by the provider) and the service's best-effort iam:ListAccountAliases, which is not part of this change.

go test ./lwpreflight/aws/ passes.

Org-level variants were not deployed in this pass; their lists received the same additions and the org Config list keeps every CloudFormation StackSet, Lambda, SNS and Secrets Manager action it had.