Skip to content

feat(cloudformation): Use an ECS task role instead of AWS access keys when running in AWS #431

Open

Description

@credfeto

Requested by the repository owner in live chat:

buildbot should not demand aws credentials WHEN running in aws

The owner's findings and steps, verbatim:

The build-bot user only has one permission, cloudformation:DescribeStacks, and CloudTrail shows that's the only call it makes. BuildBot has no task role at all (taskRoleArn: None), which is why it was given access keys. A task role does the same job with no secret to store.

Create a role by hand, e.g. BuildBot-TaskRole, trusted by ecs-tasks.amazonaws.com, with an inline policy allowing just cloudformation:DescribeStacks on . The pipeline user can't do this itself: it can only create IAM roles named TreasuryScheduler-.
Let the pipeline pass that role. Add arn:aws:iam:::role/BuildBot-TaskRole to the iam:PassRole statement in Deploy-ECS. Right now that statement only allows ecsTaskExecutionRole, and leaving this out gives you this afternoon's PassRole failure again.
Update the template. Set TaskRoleArn to that role, and remove CLOUDFORMATION__AWS__ACCESSKEYID/SECRETKEY along with the Octopus pair. SNS_TOPIC_ARN isn't a secret, so it can move to a plain env var.
Change the code. If it builds credentials from config (new BasicAWSCredentials(accessKey, secretKey)), switch to new AmazonCloudFormationClient(RegionEndpoint.EUWest1) with no credentials so the SDK picks up the task role. Fargate sets AWS_REGION for you.
Clean up. Once it's deployed and the bot is posting, delete the build-bot user. Its single key dates from 2024-10-07, was last used at 17:51 today, and is also sitting in plaintext in old task def revisions. Deleting the user is better than rotating that key.

Pieces

Step Who Where
Create BuildBot-TaskRole (trust ecs-tasks.amazonaws.com, inline cloudformation:DescribeStacks on *) Owner (manual IAM) AWS
Add the role to the iam:PassRole statement in Deploy-ECS Owner (manual IAM) AWS
TaskRoleArn = the role (in the Settings mapping, per the mappings rule on #427); remove CLOUDFORMATION__AWS__ACCESSKEYID, CLOUDFORMATION__AWS__SECRETKEY, SERVEROCTOPUS__URL and SERVEROCTOPUS__APIKEY; move SNS_TOPIC_ARN to a plain Environment value Agent cloudformation.json
Drop BasicAWSCredentials. Build the client with no explicit credentials (default chain), using the region from AWS_REGION or the config. Remove the CloudFormation:Aws:AccessKeyId / SecretKey settings Agent src/BuildBot.CloudFormation/CloudformationSetup.cs, Configuration/SnsNotificationOptions.cs, src/BuildBot/Helpers/ServerStartup.cs, appsettings.json
Delete the build-bot IAM user once the deploy is confirmed working Owner (manual IAM) AWS

Notes

Activity

  1. added
    AI-WorkWork for an AI Agent
    SecuritySecurity issue, e.g. use of insecure packages, or security fix
    On HoldDo not work on this
    on Oct 15, 2026
  2. credfeto commented on Oct 15, 2026

    @credfeto
    MemberAuthor

    Repository owner in live chat: "priority security, label on hold". Applied Security and On Hold.

  3. credfeto commented on Oct 15, 2026

    @credfeto
    MemberAuthor

    Update from the repository owner: the Octopus secrets were already deleted from Secrets Manager (Octopus was decommissioned long ago), which is what broke the 17:39 deploy; the owner has removed SERVEROCTOPUS__URL/SERVEROCTOPUS__APIKEY from cloudformation.json on main. That part of this issue's scope is done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    AI-WorkWork for an AI AgentOn HoldDo not work on thisSecuritySecurity issue, e.g. use of insecure packages, or security fix

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions