Skip to main content

Worker pool controller can use different service accounts for plans and applies

This is a request regarding the Kubernetes Worker Pool controller.

Scenario

  • A Stack StackX with two AWS integrations, IntRead , used for plans, with role InfraRead and IntWrite , used for applies, with role InfraWrite.

  • Stack StackX has a worker pool with "Assume role on Worker" enabled.


Feature request
The idea here is that e.g. ServiceAccountA has permissions to assume InfraRead and ServiceAccountB has permissions to assume InfraWrite . It would be great if the controller could manage giving a different service account depending whether the run will be using the Read or the Write cloud integration.

This would allow for better separation of permissions. After all the pod using read does not need to have a Service account that could be granting it access to the write role.

Workaround
Status: ❌ Rejected2 comments

Log in to comment and vote

Comments2

  • Jonah Kowall

    Team•

    Jul 12

    Thanks for the suggestion. Splitting credentials between plan and apply phases at the worker level is architecturally significant, and this hasn’t attracted other interest since filing, so I’m closing it. Depending on the goal (least privilege for plans), approval policies plus cloud integrations with role assumption may get you close today. If least-privilege planning is a compliance requirement for you, please share the requirement and we’ll look at it again.

    • Lime Fork

      •

      Jul 13

      Thanks for the transparency about this. Eventually we decided to go for Cloud integrations to get more control over who could do what.