Hi everyone, We are migrating from one AWS account to another which is allowing us to evaluate our ...
b
Hi everyone, We are migrating from one AWS account to another which is allowing us to evaluate our current Serverless ECS Push setup from a security posture perspective. The documentation I have read seems to lean heavily on creating an IAM user with credentials which is used to push tasks into the AWS ECS service and this is our current setup in our old account. I am interested in whether this can be accomplished by assuming an AWS role instead. This would get us away from having to rotate keys and secrets and the management of a user account. Not to mention that it would make our security folks happy. 🙂 Has anyone implemented this pattern successfully? If so, do you have documentation you can point me towards or perhaps give me an example of what the IAM Role policy would look like and how it's used/implemented on the Prefect Cloud side? Thanks for the help in advance!
👀 2
@Nate, I noticed that you responded to another thread that is similar to this a week ago. I am wondering if you might be able to shed some light on this topic. I am assuming that since ECS Push approach uses an AWS Credential block that if the block was able to supply the appropriate Assumed Role information it would be able to push tasks via assumed role instead of using access_key's and secrets? I don't see any options in the existing AWS Credential Block that allows us to put Assumed Role information in it. Is this the case? If so, is there another way to do this? I would rather not run a Hybrid worker to get around this authentication situation if at all possible. Any thoughts or ideas you can shed would be extremely helpful. Thank you!
Hi @Nate, never mind on that last question. I believe I understand why even if the AWS Credential supported assumed roles why it wouldn't work. It makes sense why an OpenID (OIDC) would have to exist in the middle for this to work. We just went through this exercise with getting a GitHub OIDC setup in place.
n
hi @Bryan! sorry i missed that - glad things are making sense!