there really needs to be a way to scope out the IA...
# aws
i
there really needs to be a way to scope out the IAM policies needed to create resources via pulumi
1. Create an IAM user in the AWS console with programmatic access and ensure it has sufficient permissions to deploy and manage your Pulumi program’s resources.
how are people discovering what is meant by "sufficient permissions", especially when you start introducing new resources, or changing how you use existing resources
g
You need full admin rights usually for the Pulumi account in my experience. Unless you're under some really demanding security requirements, it's not worth the trouble trying to scope it down to specific resources
For example usually you need to create iam roles and policies for services, and that requires IAM access, and if you have IAM access you can give yourself any other access, so there's no point for most use cases. Happy to be educated otherwise but that's been my experience at my last 3 jobs
i
Does that mean you’re deploying admin access to your AWS account onto your CI server, eg GitHub actions?
g
That's what I did yes.
I was using Gitlab at the time though. With self hosted runners.
On the project I'm currently working on, we do plan to use Github actions, and plan to use Pulumi ESC with OIDC to provision access into the account. Have got ESC with OIDC working with local deployment. If you're on the Pulumi Teams plan though, like us, it creates a restriction around who can have access to the Pulumi org. I.e. only those who are authorised for admin access in the AWS account are given access to the Pulumi account/org. We're hoping they extend RBAC down to the Teams account soon to address this as the Enterprise account pricing is out of reach for most. May look at Pulumi Deployments at some point in the future too.