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

Zack McKenna

02/15/2022, 8:46 PM
My role policy is unable to create new roles. Is there a way to set default function props / stack synthesizer for the debug stack, so I can provide it the necessary roles and doesn’t try to create them?
f

Frank

02/15/2022, 9:25 PM
Hi @Zack McKenna, currently there isn’t a way.. but let me pull in @thdxr and @Jay to see how best we can do this.
Currently , the only customization for the debug stack that’s exposed to user is AFTER the debug stack is created, ie.
Copy code
// index.js

export function debugStack(app, stack, props) {
  ... stack is already created ...
}
z

Zack McKenna

02/15/2022, 9:28 PM
Oh man, I appreciate it! It’s a real pain. I’m working with our cloud team to maybe allow us to within a permission boundary, but until then …
f

Frank

02/15/2022, 9:28 PM
Yeah, setting permission boundary for the debug stack is straight forward, here’s an example https://docs.serverless-stack.com/constructs/RDS#migrations
z

Zack McKenna

02/15/2022, 9:29 PM
Yeah, I’m relatively new to cdk, but it seems like you can’t set default props or change the default synthesizer after they’ve been created
f

Frank

02/15/2022, 9:30 PM
hmm… wait.. there might be a way…
So all resources in a stack is like a tree, the root node being the
Stack
object.
I ahven’t tried this, but I wonder if u can traverse through the `Stack`’s children and remove the roles that were created and replace them w/ your own roles
z

Zack McKenna

02/15/2022, 9:34 PM
that’s definitely worth a shot! I’ll look into it
f

Frank

02/15/2022, 9:34 PM
It’d look something like:
Copy code
// index.js

export function debugStack(app, stack, props) {
  stack.node.children.forEach((resource) => {
    // check resource instanceof iam.Role
  });
}
We actually do this pattern in quite a few places in our code. Here we recursively loop through each child and update them (ie. apply removal policy) https://github.com/serverless-stack/serverless-stack/blob/master/packages/resources/src/App.ts#L316
The part I haven’t tried is removing a child from the tree. But yeah worth a shot.
z

Zack McKenna

02/15/2022, 9:38 PM
Oh woah, that’s rad
yeah, I’ll give it a shot and let you know how it goes!
thanks so much
f

Frank

02/15/2022, 9:47 PM
Hey @Zack McKenna just checking in and see if you had any luck w/ this.
z

Zack McKenna

02/17/2022, 7:49 PM
Hey @Frank, thanks for checking in! I got sidelined by some other tasks so I haven’t been able to dedicate more time to it yet, but I should be able to spend some good time on it tomorrow.
f

Frank

02/17/2022, 10:56 PM
I just talked to the team and we spec’ed out a way to make the DebugStack more customizable.
I will try to put something together today.
Just to make sure it cover ur use case. The debug stack creates a couple of IAM roles: • 1 for each of WebSocket API routes: $connect, $disconnect, and $default • 1 for auto removing objects in the s3 bucket on delete debug stack • 1 for setting Lambda log retention Do you want to pass in a role for each of these? Or are you looking for a way to name these roles that follow a certain rule?
z

Zack McKenna

02/18/2022, 6:02 PM
Oh, that’s awesome! Yeah, exactly. It’s real silly, but because of how our roles are created/set up (via a third party), any role that needs to be created needs to be done manually beforehand. As long as I can provide a previously created role/arn, that would be perfect. Since Tuesday, I’m still waiting to hear back from our cloud team in regards to letting us use create role within a permission boundary, buuut I have no idea when I might get an answer.
Actually, I realized there are a few more roles missing that need to be passed for my use case: the deployArn and cloudFunctionExecutionArn set in the synthesizer, unless there is a way to remove/replace/edit the synthesizer after the stack has been created instead. I’m looking into it.
f

Frank

02/18/2022, 10:03 PM
Yeah, you will be able to edit the synthesizer.
Thinking ahead, do you also need a way to override all the other IAM roles in your app?
ie. if you were to use
sst.Api
, you’d need to override the roles for all the routes?
Hey @Zack McKenna, I pushed out a change in v0.65.3 that lets you edit synthesizer for the DebugStack like this;
Copy code
export function debugApp(app) {
  new sst.DebugStack(app, "debug-stack", {
    synthesizer: new cdk.DefaultStackSynthesizer({
      ...
    }),
  });
}
This will let you pass in the
deployRoleArn
and
cloudFormationExecutionRoleArn
I can make another release to support passing in the iam roles like this:
Copy code
export function debugApp(app) {
  new sst.DebugStack(app, "debug-stack", {
    synthesizer: ...,
    websocketHandlerRoleArn: "arn:...",
    lambdaLogRetentionRoleArn: "arn:...",
    ...,
  });
}
But before I proceed, I’d wanted to hear your thoughts on the above:
Thinking ahead, do you also need a way to override all the other IAM roles in your app?
ie. if you were to use 
sst.Api
, you’d need to override the roles for all the routes?
Let me know.
z

Zack McKenna

02/21/2022, 4:09 PM
Yeah, I believe that’s the case. Though, by setting a the role within function props, it seems to use that instead of attempting to create new roles for the api routes. So I guess the ability to override that is currently there?
Fortunately, I’ve been able to make some headway with our cloud team in regards to setting up the roles which can actually use create role. Though, this requires some certifications on our team’s end and will take some time, so being able to use the debug stack while I work on a POC is invaluable.
f

Frank

02/22/2022, 12:14 AM
Sounds good. I will put something together for the debug stack for now.
Hey @Zack McKenna, I just released v0.66.0. You can now pass in a role to the DebugStack like this https://docs.serverless-stack.com/constructs/DebugStack#configuring-the-debug-stack
Give it a quick try. And let me know whatelse u need to get it to work.
z

Zack McKenna

02/28/2022, 7:13 PM
awesome! thanks so much. I’ll give it a go
Copy code
zmcken282-serverless-my-debug-stack | CREATE_FAILED | AWS::IAM::Role | CustomS3AutoDeleteObjectsCustomResourceProviderRole3B1BD092 | API: iam:CreateRole User: arn:aws:sts::311732959032:assumed-role/IhatLambdaRole/AWSCloudFormation is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::311732959032:role/zmcken282-serverless-my-d-CustomS3AutoDeleteObject-1EIO9SKO5VTEY
hmm, looks like it’s still trying to create a role for the S3 autodelete.
f

Frank

03/02/2022, 2:30 AM
Can you try passing in an existing bucket, like this:
Copy code
export function debugApp(app) {
  new DebugStack(app, "debug-stack", {
    payloadBucketArn: "arn:aws:s3:::my-bucket",
    websocketHandlerRoleArn: "...",
  });
}
This way, the debug stack won’t try to create a bucket.
Let me know if that works for you.
z

Zack McKenna

03/15/2022, 2:48 PM
I had to put this down for a bit but I’ve finally been able to jump back into it. Thanks again for all your help. I was finally able to get the debug stack to work with those changes, and I was able to set things up with our governance team so roles could be generated dynamically, in the end applying an aspect to the debugStack to set a specific path and attach a required policy to each role created in order to satisfy their policy requirements. Similar what you suggested a little while ago before I had the right accounts to do so:
Copy code
class CustomRoleAspect {
  constructor(permissionBoundaryArn, path) {
    this.permissionsBoundaryArn = permissionBoundaryArn
    this.path = path
  }

  visit(node) {
    if (CfnResource.isCfnResource(node) && node.cfnResourceType === 'AWS::IAM::Role') {
      node.addPropertyOverride('PermissionsBoundary', this.permissionsBoundaryArn)
      node.addPropertyOverride('Path', this.path)
    }
  }
}
Now although the debug stack is deployed, I am getting a 403 error in the stub lambda:
Copy code
type: 'error',
  message: 'Unexpected server response: 403',
  error: Error: Unexpected server response: 403
      at ClientRequest.<anonymous> (/var/task/node_modules/ws/lib/websocket.js:604:7)
      at ClientRequest.emit (events.js:400:28)
      at ClientRequest.emit (domain.js:475:12)
      at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:647:27)
      at HTTPParser.parserOnHeadersComplete (_http_common.js:127:17)
      at TLSSocket.socketOnData (_http_client.js:515:22)
      at TLSSocket.emit (events.js:400:28)
      at TLSSocket.emit (domain.js:475:12)
      at addChunk (internal/streams/readable.js:293:12)
      at readableAddChunk (internal/streams/readable.js:267:9)
and a 503 from within the api gateway.
Copy code
{
  "requestTime": "15/Mar/2022:14:54:58 +0000",
  "requestId": "PB9OYjYdIAMESOg=",
  "httpMethod": "GET",
  "path": "/",
  "routeKey": "ANY /",
  "status": 503,
  "responseLatency": 30005,
  "integrationRequestId": "-",
  "integrationStatus": "-",
  "integrationLatency": "30000",
  "integrationServiceStatus": "200",
  "ip": "198.178.12.68",
  "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36",
  "cognitoIdentityId": "-"
}
I assume this might have something to do with permissions/policies, unless there might be something else I should look into before diving into it?
Although I believe it is reaching my client, since if I don’t have
sst start
running, I see
Client not connected. Make sure "sst start" is running.
Ah due to problems with VPC/Public WebSockets. Removing the vpc for IS_LOCAL seemed to do the trick.
f

Frank

03/22/2022, 6:19 AM
@Zack McKenna oh wow glad u got it to work!
problems with VPC/Public WebSockets
Was the issue that Lambda in VPC wasn’t able to talk to the public WS?
z

Zack McKenna

03/22/2022, 6:46 PM
Yup!
But now it’s working great, by just making sure the debug lambdas aren’t within the VPC. Thanks so so much for all the help, I can’t tell you how psyched I am to share it with the team once I translate our app to SST, the live lambda development is truly INCREDIBLE. I’ll try to compile what I can in a blog post about it since I’m sure other people might run into similar issues int he future working within larger corps.
j

Jay

03/22/2022, 7:32 PM
That would be super helpful Zack! And glad you are liking it!
5 Views