Update service role policy to include additional ecs, es and sqs permissions

[robnewman]

Description

TODO

• [n/a] Unit tests
• [n/a] Automated tests (e.g. Preflight)
• Confirm that this change meets security best practices and does not violate the security model
• [n/a] Documentation
  • [n/a] Python: Run build.py for new docstrings
  • [n/a] JavaScript: basic explanation and screenshot of new features
  • [n/a] Markdown somewhere in docs/**/*.md that explains the feature to end users (said .md files should be linked from SUMMARY.md so they appear on https://docs.quiltdata.com)
  • [n/a] Markdown docs for developers
• [n/a] Changelog entry (skip if change is not significant to end users, e.g. docs only)

[codecov]

Codecov Report

Merging #3423 (0651fc9) into master (fb6f238) will increase coverage by 1.19%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3423      +/-   ##
==========================================
+ Coverage   35.04%   36.24%   +1.19%     
==========================================
  Files         673      683      +10     
  Lines       29419    29855     +436     
  Branches     4394     4394              
==========================================
+ Hits        10311    10821     +510     
+ Misses      17948    17874      -74     
  Partials     1160     1160              

Flag	Coverage Δ
api-python	91.35% <ø> (ø)
catalog	10.23% <ø> (ø)
lambda	86.03% <ø> (+3.74%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 14 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[sir-sigurd]

Permission changes look sane, other ones are controversial:

1. I don't think we should set RoleName. CloudFormation generates the sane one, but deals with possible conflicts.
2. I don't think we should set tags. Users can set tags for CloudFormation stack by themselves and they will are propagated to the role.

(if these changes come as separate focused PRs, I'd have already approved one related to permission)

[dimaryaz]

Unfortunately, there are many many more permissions that we're missing. For example:

• iam:CreatePolicyVersion
• s3:GetBucketOwnershipControls
• s3:PutBucketOwnershipControls
• s3:PutBucketPublicAccessBlock
• sns:CreateTopic
• sns:DeleteTopic
• sns:GetTopicAttributes
• sns:SetTopicAttributes
• synthetics:*
• kms:*

I don't know of a good way to even find out all necessary permissions - I tried updating my stack over and over, and then looking at the error messages. I never figured out the specific permissions for synthetics:* or kms:* - and even then, that wasn't enough, and I ended up just adding *:*.

And finally, once you attach a role to a stack, there does not appear to be a way to remove it, short of deleting the stack.

So I think we should not recommend service roles at all.

[akarve]

This needs more thought and we can pull service roles from the docs until we have a working service role but at the same time we can’t ask for admin permissions as security and devops teams rightfully frown upon that. Maybe we backlog this but a starting place to make this tractable is to parse our own CFT and ask for * for every referenced service except IAM and then scope resources to things tagged “quilt”.