How to allow for runtime-customized security group and task role?

[pkaeding]

I am trying to build a platform that allows for arbitrary ad-hoc code execution, while ensuring that the arbitrary ad-hoc code is reviewed through a PR process. I realize this is a somewhat different use case than this project was probably created for, initially, but it feels like many of the pieces are pretty close to what I need.

The missing piece (in my mind) right now is how I could set the security groups and/or task role for fargate runner jobs at runtime. Ie, these values would be set (or derived) in the github action on the PR merge event, not hard-coded when the CDK stack is deployed.

Is this possible currently? I see that some variables are passed from the state machine to create the fargate task. Is this something that anyone has done before?

[kichik]

What would be the mapping here? Does every PR get its own infrastructure? Every GitHub environment? Is it separate AWS accounts?

Can you maybe use configure-aws-credentials-action to dynamically assume the right role? Those can be limited to specific environments or branches.

If you ever move away from the Fargate provider, you should turn off any Docker support. Those are usually implemented by giving access to the host Docker daemon.

[pkaeding]

I've pivoted my thinking a bit here. I'd like to at least be able to customize (ie, add policies) the execution role used by a FargateRunnerProvider.

My goal here is to build a 'data access platform', that allows for controlled, ad-hoc queries/code/etc to be run against sensitive datastores. So, people write the code that they want to run against the production DB, it is reviewed/approved using the PR process, and then it executes. So, I need to ensure that execution will happen with a role that has the appropriate access. In reality, I don't need to be gluing these policies together at runtime, since we don't have that many permutations of datastores.

[kichik]

If it's just about the role, then I would definitely go with onfigure-aws-credentials-action. You don't even need self-hosted runners for that one. You can even further restrict the role dynamically using inline-session-policy.

But if you want, you should be able to grant whatever policies you want to FargateRunnerProvider. It implements IGrantable and whatever policies you add should be assigned to the task role.

[pkaeding]

Okay, thanks. I definitely need hosted runners, since they need internal network access too. but I will try adding policies to the provider.