This message was deleted.
s
This message was deleted.
c
We don’t have a doc with specific tips unfortunately. Though if you are enterprising, you might be able to auto generate the set of permissions by exporting your stack’s checkpoint file, grepping through the resources it has, and then figuring out what products are in-use… But even that isn’t great, because if you ever need to add a new component to your stack (e.g. adding a DNS record or Elastisearch cluster) then you’d need to first update that IAM role governing what you are allowing Pulumi to do.
s
Thanks @colossal-beach-47527. I have a good handle on what resources I need to create but the process of creating them is opaque to me. For instance, the need to grant
route53:GetChange
in order to work with route53 DNS records is not immediately obvious, Is there an area of the Pulumi source code I’d benefit from learning more about?
As a side note, something within AWS that makes an audit log of what permissions were actually used would be ideal because I could run
pulumi up
and then
pulumi refresh
and
pulumi destroy
with admin privs and then lock down the user according to what was logged. Unfortunately nothing like that exists AFAIK.
c
For instance, the need to grant 
route53:GetChange
 in order to work with route53 DNS records is not immediately obvious
A first approximation would be the
route53:Get*
and
route53:List*
. But every service has its own quirks, e.g. there used to be an
s3:HeadObject
action. There isn’t any place in the source code that would be especially helpful other than the underlying resource provider’s source code. (But even that is using CRUD APIs to create or update resources, and there isn’t always a clear mapping from API method and the IAM Action needed to call/use that API. … as for some sort of audit log of what actions were used during a
pulumi up
and
pulumi refresh
, etc. I don’t know of anything either. I know CloudTrail would give you a lot of the API calls used, but I don’t know off the top of my head if it also lists the specific IAM actions used, and Resource ARNs that were operated on. All of this to say is that it’s a known problem, but I don’t know of any good solutions to it. But I wouldn’t be surprised if our beloved cloud provider overlords would release some offering to help us in this regard. Since this problem isn’t unique to Pulumi or AWS. And certainly be a “big deal” if GCP or Azure were to provide this capability… 🤞🏽
s
Yeah I totally agree. It’s definitely one for the overlords to help solve. I’ll stick a ticket in with aws when I get a moment and see what they have to say.
I did find this after I raised the question here https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html and I noticed it links through to tables of actions and permissions needed for each service so maybe if they can provide (or I scrape) those mappings in a useful format then I could write something to cross reference it with the Cloudtrail logs