Repository navigation
Description
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
- Both IAM steps must be done before the template change deploys, otherwise the deploy fails on
iam:PassRole. - Removing the access-key settings also resolves the earlier
SnsNotificationOptions.ToString()exposure of the secret key. - Sequencing: Move to the internal load balancer behind an API Gateway #421 (now including refactor(cloudformation): Restore the shared parameter-based template format #427's template restructure) also edits
cloudformation.json. This issue should go after Move to the internal load balancer behind an API Gateway #421, or be folded into it. - Related: feat(aws): Use an ECS task role instead of static IAM access keys funfair-server-template#1035 (task roles for the template generally).
- An implementation plan will be posted for approval before any work starts.
Activity
credfeto commentedon Oct 15, 2026
Repository owner in live chat: "priority security, label on hold". Applied
SecurityandOn Hold.credfeto commentedon Oct 15, 2026
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__APIKEYfromcloudformation.jsononmain. That part of this issue's scope is done.