fix: sync Forge AWS GitHub deploy with working 8.0.x

[jamesfredley]

Sync Forge AWS GitHub deploy with working 8.0.x

Copy forge-deploy-aws.yml (no --process, fail fast on EB errors) and
shared.yaml GitHubDeployRole managed policies from 8.0.x.

[Copilot]

Pull request overview

This PR syncs the Grails Forge AWS GitHub deployment workflow and its supporting IAM role permissions with the known-working configuration from the 8.0.x line, aiming to make Elastic Beanstalk deployments fail faster and behave consistently across branches.

Changes:

• Updated the Forge deploy GitHub Actions workflow to remove Elastic Beanstalk application-version “processing” logic and to fail fast based on EB ERROR events.
• Expanded the CloudFormation IAM role used by GitHub deploys by attaching Elastic Beanstalk managed policies and adjusting S3/EB-related permissions.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
grails-forge/infrastructure/shared.yaml	Adds EB-managed policies to the GitHub deploy role and expands IAM permissions used during deployment.
.github/workflows/forge-deploy-aws.yml	Updates the deployment script to fail fast on EB ERROR events and removes the explicit application version processing wait.

Suppressed comments (2)

grails-forge/infrastructure/shared.yaml:256

• GitHubDeployRole now allows s3:PutObjectAcl and s3:DeleteObject, but the deploy workflow only uploads an artifact via aws s3 cp and does not set ACLs or delete objects. Keeping these actions increases the blast radius if the OIDC role is misused; please remove them unless a concrete step requires them.

                  - s3:GetObjectAcl
                  - s3:PutObject
                  - s3:PutObjectAcl
                  - s3:DeleteObject

grails-forge/infrastructure/shared.yaml:307

• The added autoscaling:Describe* and ec2:Describe* permissions appear unused by the deploy workflow (which only calls CloudFormation, S3, and Elastic Beanstalk APIs). Please remove these permissions unless they are required by an explicit step, to avoid unnecessary account-wide read access.

              - Action:
                  - autoscaling:DescribeAutoScalingGroups
                  - autoscaling:DescribeAutoScalingInstances
                  - autoscaling:DescribeScalingActivities
                  - autoscaling:DescribeLaunchConfigurations

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[bito-code-review]

The concern regarding the use of broad AWS-managed policies like AdministratorAccess-AWSElasticBeanstalk is valid. Relying on managed policies often grants excessive permissions beyond what is required for specific CLI operations, which contradicts the principle of least privilege.

To improve the security posture of the GitHubDeployRole in grails-forge/infrastructure/shared.yaml, you should:

1. Remove the ManagedPolicyArns block entirely.
2. Explicitly define the necessary elasticbeanstalk actions (such as elasticbeanstalk:DescribeEvents, elasticbeanstalk:DescribeEnvironments, elasticbeanstalk:CreateApplicationVersion, and elasticbeanstalk:UpdateEnvironment) within the inline PolicyDocument.

This approach ensures the role only has the permissions strictly required for the deployment workflow.

grails-forge/infrastructure/shared.yaml

ManagedPolicyArns:
        - Fn::Sub: arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk
        - Fn::Sub: arn:${AWS::Partition}:iam::aws:policy/AWSElasticBeanstalkWebTier
        - Fn::Sub: arn:${AWS::Partition}:iam::aws:policy/AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy