Update AWS upload action role setting

[brynpickering]

The recommended method to set up the aws upload action "role" is to set role-to-assume. I'm not sufficiently familiar with AWS to know if we should be following this recommendation. Can you comment @mfitz?

[mfitz]

So, the difference between our current approach and the recommended one is that for our current approach, we have created an IAM user (a user outside of the federated user management provided by the corporate Active Directory, so administered entirely by us) in our dev AWS account and given that user extremely limited permissions. It can only write to (no reading from or listing contents) a specific S3 bucket; this is the entire permission set:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::<name of the S3 bucket we use in our CI/CD pipelines>/*"
            ]
        }
    ]
}

We've then generated a set of creds for that user, which we add as secrets on each GitHub repo that needs to push to S3. The creds never expire.

With the recommended approach, we would define a role(s) in the AWS account rather than a user, and that role would have the same limited set of permissions as above. We would then configure our actions jobs to use GitHub's OIDC AWS identity provider.

The general benefits of switching to the recommended approach seem to be:

• It's more secure to use short-lived creds
• Fewer secrets need to be added to our GitHub repos
• It splits the authentication and authorisation responsibilities apart; authentication becomes the responsibility of the OIDC integration with AWS STS, and authorisation is determined by the permissions on the role. You can vary the role used on a workflow-by-workflow or even action-by-action basis, so the permissions control is more fine-grained than using a single IAM user for all actions/workflows (although under our current approach, there's nothing to stop us from creating a separate IAM user per project, I suppose).
• More fine-grained audit trail in the AWS account; we could go as far as defining a role per project if we wanted and could then trace each project's activity separately in AWS (although again, I guess we could already do that at the user level under our current approach if we thought it was important)

The benefits are fairly marginal, so I don't think there's any urgency around switching, but the recommended approach is better.

To switch, we'd need to figure out the OIDC bit - we've never done that before. From a quick scan of the docs, I'm not 100% sure whether we'd do that ourselves in the AWS account via IAM or if it would be a central IT thing. Both approaches seem possible. We'd need to speak to central IT first.

[brynpickering]

OK, so it sounds like something to do on a quiet day. I'll leave the issue open for now.