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
StackXwith two AWS integrations,IntRead, used for plans, with roleInfraReadandIntWrite, used for applies, with roleInfraWrite.Stack
StackXhas 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
Log in to comment and vote
Comments2
Jonah Kowall
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.