Gen2 shared secrets wrong path/permissions

[pjoe]

trafficstars

Environment information

System:
  OS: Windows 11 10.0.22631
  CPU: (16) x64 AMD Ryzen 7 6800H with Radeon Graphics
  Memory: 6.90 GB / 31.26 GB
Binaries:
  Node: 20.12.2 - C:\Program Files\nodejs\node.EXE
  Yarn: 1.22.22 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
  npm: 10.5.0 - C:\Program Files\nodejs\npm.CMD
  pnpm: 7.33.5 - ~\AppData\Local\pnpm\pnpm.EXE
NPM Packages:
  @aws-amplify/backend: 1.0.3
  @aws-amplify/backend-cli: 1.0.4
  aws-amplify: 6.3.6
  aws-cdk: Not Found
  aws-cdk-lib: Not Found
  typescript: 5.4.5
AWS environment variables:
  AWS_NODEJS_CONNECTION_REUSE_ENABLED = 1
  AWS_REGION = eu-central-1
  AWS_SDK_LOAD_CONFIG = 1
  AWS_STS_REGIONAL_ENDPOINTS = regional
No CDK environment variables

Description

When using a shared secret (defined for all branches but e.g. not in sandbox), from a function the lambda config ends up being wrong :S

The secret has a wrong sharedPath in AMPLIFY_SSM_ENV_CONFIG env var:

/amplify/shared/<npm package name>/SECRET_NAME

This should be:

/amplify/shared/<amplify app-id>/SECRET_NAME

At least that is the path where the secret is in SSM.

The wrong path is also specified in the IAM policy for the lambda.

End result is function fails with:

AccessDeniedException: User: arn:aws:sts::12345678:assumed-role/amplify-xxxx-functionlambdaService-5bAqBWD3Dym7/amplify-xxxxx-somelambda811610-epog9XEQtiAo is not authorized to perform: ssm:GetParameters on resource: arn:aws:ssm:eu-central-1:12345678:* because no identity-based policy allows the ssm:GetParameters action

Guessing this arises from here: https://github.com/aws-amplify/amplify-backend/blob/main/packages/backend-function/src/lambda-shims/resolve_ssm_params.ts#L60

[Jay2113]

Hi @pjoe 👋 , thanks for raising this with us. To test the configuration of secrets with functions, I followed these steps:

1. Created a new Gen 2 backend using npm create amplify@latest.
2. Added a function following the guide.
3. Configured a secret as per the guide.
4. Pushed the changes to the repository and created a new app in the Amplify console.
5. Added the secret in the console using the guide.
6. After deployment was completed, invoked the function and reviewed the response and environment variables.

Throughout the process, I observed that the AMPLIFY_SSM_ENV_CONFIG environment variable had the expected sharedPath key set to amplify/shared/<appid>/<secret-name>, which is the correct SSM secret path.

Can you share a screenshot of the path you observed? Additionally, it would be helpful if you could provide reproduction steps for us to investigate further.

[pjoe]

I can unfortunately not share code as this is on a proprietary project. One thing that might make a difference is that we are using a Nx monorepo. Will try to find time to make a reproducible demo.

[pjoe]

FWIW: here is a screenshot

NOTE: this is from a sandbox that itself does NOT have the secret configured (so it should fallback to the shared secret)

[Jay2113]

@pjoe thanks for sharing the screenshot. To ensure I understand correctly, I'd like to confirm that the sharedPath value shown is for a sandbox deployment, and not when using the pipeline-deploy command? If you have an environment deployed using the Amplify CI/CD pipeline, could you please verify the path for that environment to see if it follows the format amplify/shared/<appid>/<secret-name>?

It would be helpful to clarify this distinction between sandbox deployments and deployments made through the Amplify CI/CD pipeline, as the paths for shared resources may differ.

[Jay2113]

Closing the thread since we cannot reproduce the outlined issue and the sharedPath value for the secret is expected in case of a sandbox deployment.