i thought about maybe setting `aws:defaultTags` in...
# aws
i
i thought about maybe setting
aws:defaultTags
in the config, and then trying to write a policy for the deployment user that allows it to work with any resources that have the
user:Project=myproject
tag
l
Assuming that you're talking about running Pulumi from an EC2 instance, and you want it to have all the required privileges, then I don't think either of these will be a good way to put a boundary on the permissions. New resources won't have any existing tags, so you can't say "create resource X if resource X has tag Y".
Also: why do you need a user? A role should be enough. A role has the advantage that it can be applied to an EC2 instance profile, or used by anything else that should have the same permissions.
You may want to deploy Pulumi using an SSO-authenticated user, and you wouldn't be able to use your IAM user in that case.
A simpler idea would be to give your Pulumi creds full admin privileges for accounts that Pulumi can manage, and don't allow Pulumi any access to sensitive accounts (e.g. billing). Use the account as the boundary.
i
New resources won't have any existing tags, so you can't say "create resource X if resource X has tag Y".
I think I might have got this working, just need to use
aws:RequestTag
instead of
aws:ResourceTag
I'm also working solo so deployments run from my local machine for now, and I want to avoid creating an access key for my root account so I needed another user for local laptop deploys
Here's the pulumi YAML config and then two IAM inline policies I have on the user, and it seems to be working well. 1. pulumi config:
Copy code
config:
  aws:defaultTags:
    tags:
      user:Project: my_pulumi_project
2. tagging policy
Copy code
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "tag:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/user:Project": "my_pulumi_project"
        }
      }
    }
  ]
}
3. manage resources
Copy code
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:*",
        "s3:*",
        "lambda:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/user:Project": "my_pulumi_project"
        }
      }
    }
  ]
}
it's probably not as secure as it could be, and I may run into other issues as I haven't tested a deploy or teardown of my full stack - but I guess it's a step up from what I was doing previously, which was using root account access key
l
If you're using your root account at all, for anything, then you're not really compromising yourself any further by using IAM user with admin access for Pulumi. Anything you do that's better than that, is good :)