I’m realizing I’m using a mix of methods to add and manage permissions, from learning across various examples – • in CDK is the expectation is to create Roles that can be assumed by certain types of Service Principals (e.g.

<http://events.amazonaws.com|events.amazonaws.com>

) and then add/manage Policy Statement(s) on these? • if so, in SST does

.attachPermissions

automatically create the necessary Roles/Principal assignments in the background when you reference a permitted construct or explicitly add a Policy Statement? • on the SST Function construct it looks like there’s another method of

.addPermission

– I don’t see any notes for this in the docs; how or when should this be used, if at all?

Every function by default gets a role that can be assumed by lambda sp

Thanks @thdxr Does the same logic apply when you

.attachPermissions

on other constructs (outside of Functions)? And is the

.addPermission

method on Function ever applicable?

Yeah calling

.addPermission

is the same as specifying the

permissions: []

array when creating

Re

.attachPermissions

I thought that was the main method to utilize since it’s in the one listed on the Function and Permissions docs - https://docs.serverless-stack.com/constructs/Function#attachpermissions https://docs.serverless-stack.com/util/Permissions Maybe I’m not following what you mean about using `grantX`; isn’t that the property option used inside

permissions:

/

attachPermissions

array?

Just to chime in, @Clayton lemme add some context around permissions.

.addPermission

is a native CDK method. And since

sst.Function

extends CDK’s

lambda.Function

,

.addPermission

is there, but you shouldn’t need to use it.

.attachPermission

provides a much simpler way to give permissions to a function. It can take a

ALL

to grant administrator access; a string like

sns

to grant all permissions to all SNS topics; a string like

sns:PublishMessage

to grant publish permission to all SNS topics; a construct like

sst.Topic

to grant publish permission to the given SNS topic, etc as described in the doc https://docs.serverless-stack.com/util/Permissions

Yeah realized I was wrong about this today when working with permissions lol

Thanks @Frank. One question, can

.attachPermissions

be used the same way against all SST constructs (e.g. Api, EventBus, KinesisStream) or is it primarily intended to be used with Functions?

You are always attaching permissions to Functions. ie.

myFn.attachPermissions(["sns"])

allows u to make AWS SNS sdk calls

@Frank I may be conflating this idea and the ideas of Roles and Policies. In CDK it looks like you need to create and assume roles and then apply policies to these, right? I thought that was what

.attachPermissions

was doing under the hood making it applicable to things outside of Functions. So, for example, if I had an EventBridge event bus that I wanted to be able to put events to a Kinesis Stream I could replace something like this -

const bus = new sst.EventBus(this, 'Bus');
const stream = new sst.KinesisStream(this, 'Stream');
...plus rule that connects bus to stream

...roles & permissions to allow bus to access stream
const busRole = new iam.Role(this, 'BusRole', {
   assumedBy: new iam.ServicePrincipal('<http://events.amazonaws.com|events.amazonaws.com>'),
});
busRole.addToPolicy(
   new iam.PolicyStatement({
      effect: iam.Effect.ALLOW,
      actions: ['kinesis:PutRecord', 'kinesis:PutRecords'],
      resources: [stream.streamArn],
   })
);

with -

bus, stream and rule creation...

...roles & permissions for bus to access stream
bus.attachPermissions([
   [stream, 'grantWrite'],
]);

There’s a 100% chance I don’t understand the underlying pieces permissions yet — but trying to understand when / where I should use SST’s permissions conveniences vs doing something more explicitly via CDK.

Hey @Clayton, yeah,

.attachPermissions

on other construct grants the permission to the Functions we create within those constructs. For example,

bus.attachPermissions()

attach the permissions to the Function targets it has.

Thanks @Frank - I’m a bit unclear on where the functions come into play in those scenarios. For example in the stack below

.attachPermissions

seems to be working correctly but I don’t see any functions involved.

Hey @Clayton, an EventBus can have different type of targets, ie. Lambda functions, SQS queues, Kinesis Streams. And

.attachPermissions

is only meaningful if you were using function target.

Thanks @Frank. In a case like this then do you need to still create/assign roles and policy statements to provide the correct permissions for the bus to access the stream?

No you don’t have to. That’s handled automatically when you add the KinesisSstream as the target.

@Frank to make sure I’m thinking of this correctly, is there a rule of thumb for when SST is automatically adding permissions vs when you need to do this explicitly? For example, does SST always try to add the correct permissions when items are directly composed with or within one another?

Yup, permissions across constructs are always taken care of. This is actually done by CDK.