Hi all, when working locally I notice that the permissions assumed by utilities like the AWS-SDK are those of the local system user, and not the ServiceRole that has been assigned to the AWS resource when the stack is constructed. I think the potential here is that local debug works, and the full deploy doesn't, purely due to a permissions issue. I opened an issue for this here: https://github.com/serverless-stack/serverless-stack/issues/363. Is this something of interest?

Hey @Simon Reilly, it shouldn’t happen.

sst start

should use the IAM credentials of the Lambda function.

Thanks Frank, I am using the aws-sdk for js V3 if that has anything to do with it?

Hi @Simon Reilly, I tried your code with both aws-sdk v2 and v3, and I got the

is not authorized to perform: dynamodb:PutItem

error in both cases.

Alright, was this when running

npx sst start

. Perhaps I was just doing it wrong?

Yeah, inside

npx sst start

Awesome, sorry for the trouble, this looks like it must be user error. I am, on day 2 of using sst. One more thing is that I run

AWS_PROFILE=cgu npx sst start

to use a local profile. Is this potentially what is causing my issue?

Hmm it shouldn’t.. b/c when the lambda function is invoked locally, it inherits the IAM credentials from the environment

Hey Frank, I am on debugging this. I am looking into whether the dynamo db client created outside the handler at require time has the same credentials as the process.env and will get back to you 👍

Hey Simon, had a chance to try ur repo… and I got the expected

AccessDenied

error.

Thanks for this Frank, I have been able to identify that the IAM credentials are my local credentials. Looking in detail 1. There is a set of temporary credentials provided locally by the SST framework 2. The clients constructed are not using them, because the

AWS_PROFILE

env var is present inside the lambdas, and they are preferentially using the credentials attached to that profile I have updated my bug report with my operating system, a PR that shows using

delete(process.env.AWS_PROFILE)

fixes this issue, and also a GIF of the issue happening when I deploy with

AWS_PROFILE=cgu npx sst start

It is worth mentioning now that I would usually deploy the cdk like so:

npx cdk deploy --profile cgu

this does not set the env var I believe. I do not think the sst supports this yet:

$ npx sst start --profile cgu

=======================
 Deploying debug stack
=======================

 ✅  dev-sst-tester-debug-stack (no changes)

Stack dev-sst-tester-debug-stack
  Status: no changes
  Outputs:
    BucketArn: arn:aws:s3:::dev-sst-tester-debug-stack-bucket83908e77-8oy8jd2stedi
    BucketName: dev-sst-tester-debug-stack-bucket83908e77-8oy8jd2stedi
    Endpoint: <wss://e4y2ztj41b.execute-api.eu-west-1.amazonaws.com/dev>


===============
 Deploying app
===============

Preparing your SST app
Detected tsconfig.json
Transpiling source
Linting source
Running type checker
Deploying stacks
AccessDenied: User: arn:aws:iam::347250048819:user/simon.reilly is not authorized to perform: cloudformation:DescribeStacks on resource: arn:aws:cloudformation:eu-west-1:347250048819:stack/dev-sst-tester-my-stack/*
    at Request.extractError (/home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/protocol/query.js:50:29)
    at Request.callListeners (/home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
    at Request.emit (/home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
    at Request.emit (/home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/request.js:688:14)
    at Request.transition (/home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/request.js:690:12)
    at Request.callListeners (/home/simon/code/projects/sst-tester/node_modules/aws-sdk/lib/sequential_executor.js:116:18) {
  code: 'AccessDenied',
  time: 2021-05-14T06:33:12.517Z,
  requestId: '281d9599-badf-4202-bf0e-5c843564c744',
  statusCode: 403,
  retryable: false,
  retryDelay: 16.820242262488392
}

 ❌  dev-sst-tester-my-stack failed: AccessDenied: User: arn:aws:iam::347250048819:user/simon.reilly is not authorized to perform: cloudformation:DescribeStacks on resource: arn:aws:cloudformation:eu-west-1:347250048819:stack/dev-sst-tester-my-stack/*


Stack dev-sst-tester-my-stack
  Status: failed
  Error: User: arn:aws:iam::347250048819:user/simon.reilly is not authorized to perform: cloudformation:DescribeStacks on resource: arn:aws:cloudformation:eu-west-1:347250048819:stack/dev-sst-tester-my-stack/*

Failed to deploy the app

Thanks Simon. I think

AWS_PROFILE

might be the culprit. I removed it from the npm scripts when I cloned ur repo, which in the hindsight was dumb. I should’ve tried ur EXACT setup.

Cheers Frank 👍

I can confirm this issue! In aws sdk v3, AWS_PROFILE takes precedence over AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY - https://github.com/aws/aws-sdk-js-v3/pull/103

Great, thanks Frank 👍