Refactor IAM permissions in CDO CloudFormation template

[wjordan]

This PR refactors various existing admin-managed IAM-permissions resources (AWS::IAM::Role and AWS::IAM::InstanceProfile) to stack-specific IAM resources, constrained to more fine-grained resources specific to the stack where they are located.

Previously, AWS::IAM resources could not exist in application stacks because permissions to iam:* APIs were restricted to the root account and 'admin' role (to prevent privilege-escalation from non-admin logins). This PR creates a CloudFormation Service Role granting CloudFormation just enough iam permissions to manage a few key IAM resources (AWS::IAM::Role, AWS::IAM::ManagedPolicy, AWS::IAM::InstanceProfile) within stacks. Additionally, a Condition requires all AWS::IAM::Roles to include a PermissionsBoundary, which prevents privilege-escalation through creating/assuming Role resources. (See blog post for more details on how the permissions-boundary feature works.)

This will provide better security (more restricted IAM permissions on frontend and daemon EC2 instance profiles), and simplifies permissions management moving forward (since we can create AWS::IAM resources alongside the service resources in application-stack templates).

Allowing for these fine-grained permissions within each application stack is also a prerequisite to integrating Secrets Manager service into our application.

[wjordan]

I might add an erb-macro for the standard AssumeRolePolicyDocument boilerplate here, something like <%=service_role 'ec2' %> could replace these five lines for most aws-service-role cases.

[wjordan]

done

[wjordan]

The current PR only adds resources to the IAM and application-environment (staging, autoscale-prod, etc) stacks:

$ bundle exec rake stack:iam:validate
IAM layer including global/shared roles and access permissions for Code.org infrastructure. Note: Admin permissions are required to manage some admin-only resources in this stack.
Listing changes to existing stack `IAM`:
Add CloudFormationAdmin [AWS::IAM::Role] 
Add CloudFormationService [AWS::IAM::Role] 
Add DevPermissions [AWS::IAM::ManagedPolicy] 

$ RAILS_ENV=staging bundle exec rake stack:validate
AWS CloudFormation Template for Code.org application
Listing changes to existing stack `staging`:
Add CDOPolicy [AWS::IAM::ManagedPolicy] 
Add DaemonInstanceProfile [AWS::IAM::InstanceProfile] 
Add DaemonRole [AWS::IAM::Role] 

$ RAILS_ENV=production bundle exec rake stack:validate
AWS CloudFormation Template for Code.org application
Listing changes to existing stack `autoscale-prod`:
Add CDOPolicy [AWS::IAM::ManagedPolicy] 
Add DaemonInstanceProfile [AWS::IAM::InstanceProfile] 
Add DaemonRole [AWS::IAM::Role] 
Add FrontendInstanceProfile [AWS::IAM::InstanceProfile] 
Add FrontendRole [AWS::IAM::Role] 
Add WebServerHookRole [AWS::IAM::Role] 

Migration plan:

• Manually update the IAM stack with the new shared IAM resources.
• Merge this PR, which will create the new IAM resources in each application environment and associate the new CloudFormation Service Role with each stack.
  • Some risk of stack-update failing here, so I will monitor the updates.
• Once the PR is fully deployed, manually test out the new Frontend and daemon Instance Profiles on EC2 instances through the Console.
  • Some risk of 'access denied' errors cropping up here due to the more restricted fine-grained permissions. In case errors appear, we can quickly switch back to the original role(s).
• Once the new roles appear stable, merge a final PR that will update the stack-template references to use the new IAM resources. (Update EC2 instance-profile roles to use fine-grained permissions #27481)
• Finally, remove the old no-longer-used IAM resources in the IAM stack.

[wjordan]

This is working well in my manual tests at this point, so I'm going to start rolling out the added resources to the application stacks now.