[nataliafit]

Summary

A little less anonymous pulling, a lot less wrestling with ECR limits! 🙂 I've added ECR Public login to the image build, the test runners, and the security-analysis job, with a dedicated read-only OIDC role rather than borrowing the publishing role.

Each job gets its own login—including the runners that build images inside the salt-ssh tests. Fork and Dependabot PRs keep using anonymous public pulls and never attempt to assume the AWS role.

I've also moved the publishing role ARN out of the workflow and into its own repository variable. Same publishing role and permissions, just a cleaner place for its identifier. The read-only and publishing roles stay separate. 🙂

A small stdlib-only regression check runs in the build workflow's metadata job to keep the CI login guards, ordering, and repository-variable lookup covered.

Configuration

Both ARNs come from repository Actions variables, not secrets:

• AWS_ECR_READ_ONLY_ROLE_ARN: build, tests, and security analysis use ${{ vars.AWS_ECR_READ_ONLY_ROLE_ARN }}.
• AWS_ECR_PUBLISH_ROLE_ARN: publication uses ${{ vars.AWS_ECR_PUBLISH_ROLE_ARN }} instead of its previous hardcoded ARN.

They're resource identifiers, not credentials; GitHub obtains the actual short-lived AWS credentials through OIDC. Both variables are configured, and the publishing variable matches the previous publishing role exactly. This change does not alter IAM policies or publishing triggers.

The read-only role needs only these permissions for authenticated public pulls—no push permissions:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["ecr-public:GetAuthorizationToken", "sts:GetServiceBearerToken"],
    "Resource": "*"
  }]
}

Its OIDC trust must match this repository's pull-request context and its main branch context for scheduled security runs, with audience sts.amazonaws.com. Authentication uses us-east-1, as required for ECR Public.