https://pulumi.com logo
Join SlackCommunities
Powered by
This message was deleted.
# general
s
This message was deleted.
a
It's a bit hard to cater to everyone needs
I think this is why the default role is quite large on permissions. You should really use a role you defined with more restrictive perms in production environnements
Even thought I think that in a perfect world pulumi could detect everything your lambda access and update the role accordingly
t
Yes the fact that created a role itself made me thought it would tailor that role to exactly what that lambda needed. What would be a good workaround for now that can be done with pulumi itself so is still automated?
a
Copy code
new aws.serverless.Function('my-func', {
  policies: ['arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess']
}, () => {
  console.log('hello')
})
with 
aws.serverless.Function
you can quickly reference existing policies or you can even create a role with 
aws.iam.Role
and use the role reference with that function.
t
That means I can’t use the 
cloud.API
right? Is there a way to set policies or roles while creating a cloud.API?
a
From @white-balloon-205 16 days ago : If you are using this indirectly via 
@pulumi/cloud
though, you need to set it via global configuration of the 
cloud-aws
package currently - you can use this: https://github.com/pulumi/pulumi-cloud/blob/master/aws/config/index.ts#L52-L56
Meaning you can set policies in your stack config under the key 
computeIAMRolePolicyARNs
or maybe it needs to be prefixed with 
aws:
I'm not sure
t
Thanks! I think they key is 
cloud-aws:computeIAMRolePolicyARNs
as I found in https://github.com/pulumi/examples/tree/master/cloud-js-thumbnailer-machine-learning#running-the-app I’m now trying to come create a proper policy in the management console, I’m too noob with aws 😅
a
Cool, iam console is really straightforward no worries 😄
t
I was able to create one and set that config to use it, now the lambda is more restricted, nice 🙂 Now I will keep digging to see if I could automate this with pulumi somehow, because the policy needs the IDs of the resources, so when I move this to another account it will be a pain to create a new policy manually. I was thinking I could make the policy with this ( https://pulumi.io/aws/iam.html#create-an-aws-iam-resource-using-pulumiaws ) and then use the name in the config but looks like it will cause some weird reference cycle 😛 (pulumi up will check if the policy exist before it creates it), even if that works I don’t know how to get the proper IDs for the resources before pulumi creates them. Ideally I would like to be able to tell 
new cloud.API
that it can access a 
cloud.Table
created the line before and to some cloudwatch logs. (i’m just rumbling now… 😅)
a
I think you are going to get stuck really quick because I can't think of a way to dynamically set the pulumi config for the policies needed by the cloud api (but maybe it exists)
But you can just go a level of abstraction lower with 
serverless.apigateway.API
in the 
@pulumi/serverless
package and 
aws.serverless.Function
in the 
@pulumi/aws
package.
If you don't need the multi-cloud abstraction ofc
t
Yes I don’t have high hopes of that working. My idea of setting the config dynamically is because I saw https://github.com/pulumi/pulumi-cloud/blob/9c81b0be41447c7086e7c428a410df009c4a110f/aws/shared.ts#L97 but I’m still not sure on how to create policies that reference resources that are created in the same program. I will try these other abstractions. I don’t need the multi cloud abstraction, I’m just using the cloud.API to provide REST endpoints.
Copy code
const table = new cloud.Table("table", "id");
const endpoint = new cloud.API("api");
endpoint.get('/feed', (req, res) => {
    table.scan().then(posts => {
So if I can replicate that with those other classes it will be fine.
a
The problem with cloud.api is just that you cannot programmatically overide the policies.
Otherwise it's quite easy to reference a ressource inside a policy you just need to use .apply or pulumi.all if you want to reference multiple resources
t
“.apply or pulumi.all ” ok I didn’t know that. I will look into that then. How hard it is to replicate the “endpoint.get” behaviour with the lower level apis?
a
Copy code
const api = new serverless.apigateway.API('api', {
  routes: [
    {method: 'GET', path: '/events', handler: f.listEvents},
    {method: 'GET', path: '/videos', handler: f.listVideos},
    {method: 'GET', path: '/events/{date}', handler: f.listEventsSlots}
  ]
})
this is what a serverless.apigateway looks like
f.* is just a reference to a handler
Copy code
const getPolicy = (bucketArn: string) => {
  return JSON.stringify({
    Version: '2012-10-17',
    Statement: [{
      Action: ['s3:PutObject', 's3:GetObject', 's3:ListBucket'],
      Effect: 'Allow',
      Resource: `${bucketArn}/*`
    }]
  })
}

const rolePolicy = new aws.iam.RolePolicy('upload-unauth-policy', {
  role: uploadRole.id,
  policy: srcBucket.arn.apply(getPolicy)
})
t
Cool! Thanks for the help. I will give it a try tomorrow 😄
I wish it was easier tho 😛
a
and thats one example of how I you can reference a ressource inside a policy
👍 1
yep easier would be cool, but you'll need the pulumi team attention on that one
t
I didn’t get that far but sadly can’t spend more time on this (other priorities have come up). Thanks for your help Tirke, I feel like I’m close enough tho 😛 I created an issue on the repo https://github.com/pulumi/pulumi-cloud/issues/557 just so the pulumi team is aware ^^ cheers
Open in Slack
PreviousNext
Powered by