External secrets

[sisygoboom]

Environment information

System:
  OS: Linux 5.15 Ubuntu 24.04.1 LTS 24.04.1 LTS (Noble Numbat)
  CPU: (16) x64 12th Gen Intel(R) Core(TM) i7-1270P
  Memory: 12.05 GB / 15.34 GB
  Shell: /usr/bin/zsh
Binaries:
  Node: 20.11.1 - ~/.n/bin/node
  Yarn: 1.22.22 - ~/.yarn/bin/yarn
  npm: 9.7.1 - ~/.npm-global/bin/npm
  pnpm: undefined - undefined
NPM Packages:
  @aws-amplify/auth-construct: 1.5.1
  @aws-amplify/backend: 1.12.0
  @aws-amplify/backend-auth: 1.4.2
  @aws-amplify/backend-cli: 1.4.6
  @aws-amplify/backend-data: 1.4.0
  @aws-amplify/backend-deployer: 1.1.13
  @aws-amplify/backend-function: 1.11.0
  @aws-amplify/backend-output-schemas: 1.4.0
  @aws-amplify/backend-output-storage: 1.1.4
  @aws-amplify/backend-secret: 1.1.5
  @aws-amplify/backend-storage: 1.2.4
  @aws-amplify/cli-core: 1.2.1
  @aws-amplify/client-config: 1.5.5
  @aws-amplify/deployed-backend-client: 1.5.0
  @aws-amplify/form-generator: 1.0.3
  @aws-amplify/model-generator: 1.0.12
  @aws-amplify/platform-core: 1.5.0
  @aws-amplify/plugin-types: 1.7.0
  @aws-amplify/sandbox: 1.2.9
  @aws-amplify/schema-generator: 1.2.6
  aws-amplify: 6.12.0
  aws-cdk: 2.174.1
  aws-cdk-lib: 2.174.1
  typescript: 5.7.2
No AWS environment variables
No CDK environment variables

Describe the feature

We need to be able to fetch secrets that are not managed by amplify. We would like the secret() function to be able to receive arns and/or logical ids from the wider AWS account or have an externalSecret() function.

This is because of some corporate rules, amplify is flexible enough to meet all other needs but this would require a significant amount of tinkering on our behalf so would be good to avoid.

Use case

Meeting corporate rules, using backend as a standalone cdk framework without the need for amplify managed service.

[ykethan]

Hey @sisygoboom, thank you for reaching out. Marking this as feature request to support fetching existing secrets in the account.

[ykethan]

@sisygoboom could you also provide us any additional details on the constraints and use case.

[sisygoboom]

Yep, we want the flexibility to use non amplify secrets because:

• We might not get permission to use amplify as a managed service and therefore wouldn't have console access, but still want to use amplify as a cdk framework and operate it via the command line
• We might have secrets that are used by multiple stacks on the same account, and we'd need a central place for them which can be accessed by cdk/sam/serverless provisioned stacks.
• DBAs control the changing of secrets in higher environments, and this would present a change in their usual workflow
• This requirement may come up in the future even if we do get approval to use amplify console
• Prevent the need for each sandbox user to manage their secrets individually