https://serverless-stack.com/ logo
#help
Title
# help
c

Clayton

11/08/2021, 8:51 PM
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?
t

thdxr

11/08/2021, 9:02 PM
Every function by default gets a role that can be assumed by lambda sp
And any permissions added gets added to this role
c

Clayton

11/08/2021, 9:41 PM
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?
t

thdxr

11/08/2021, 9:52 PM
Yeah calling
.addPermission
is the same as specifying the
permissions: []
array when creating
I'm not sure about the
.attachPermissions
function - can you give me an example? I typically use the
grantX
to attach to a function
c

Clayton

11/08/2021, 9:59 PM
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?
f

Frank

11/11/2021, 2:57 AM
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
I will stop here and see if you want clarification on any part.
t

thdxr

11/11/2021, 3:06 AM
Yeah realized I was wrong about this today when working with permissions lol
c

Clayton

11/11/2021, 4:06 PM
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?
f

Frank

11/11/2021, 6:59 PM
You are always attaching permissions to Functions. ie.
myFn.attachPermissions(["sns"])
allows u to make AWS SNS sdk calls
The
.attachPermissions
idea doesn’t apply to other constructs.
Can you elaborate what you have in mind for other SST constructs?
c

Clayton

11/11/2021, 8:51 PM
@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 -
Copy code
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 -
Copy code
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.
Looking over my code I’m realizing part of what may have gotten me down this path of thinking was seeing
.attachPermissions
as an available method on other SST constructs, e.(g. EventBus, KinesisStream, etc). Is it meant to do something different in those contexts?
f

Frank

11/12/2021, 12:42 AM
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.
c

Clayton

11/12/2021, 4:08 PM
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.
f

Frank

11/12/2021, 8:33 PM
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.
In your case, since you are only using Kinesis stream targets, you don’t need the
.attachPermissions
line.
c

Clayton

11/12/2021, 8:38 PM
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?
f

Frank

11/12/2021, 8:55 PM
No you don’t have to. That’s handled automatically when you add the KinesisSstream as the target.
c

Clayton

11/12/2021, 9:51 PM
@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?
f

Frank

11/12/2021, 11:16 PM
Yup, permissions across constructs are always taken care of. This is actually done by CDK.
5 Views