https://pulumi.com
Join Slack
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

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by