Support "AWS Systems Manager Parameter Store" as secret provider

[foxylion]

Many have AWS Systems Manager Parameter Store as a backend to store secret parameters.
This would be awesome if supported by secretspec.

[domenkozar]

@foxylion I opened draft PR #212 implementing the AWS Systems Manager Parameter Store provider: #212

Would you be able to test it against a real AWS account? The opt-in integration suite writes temporary SecureString parameters under /secretspec/:

AWS_REGION=us-east-1 \
SECRETSPEC_TEST_PROVIDERS=awsps \
devenv shell cargo test --package secretspec provider::tests::integration_tests -- --nocapture

The test identity needs ssm:GetParameter, ssm:GetParameters, and ssm:PutParameter on that hierarchy, plus KMS permissions if a customer-managed key is used. Feedback on the awsps://[profile@]region?prefix=...&kms_key_id=...&tier=... URI and /secretspec/{project}/{profile}/{key} layout would be especially helpful.

[james-heidi]

Tested against a real AWS account (Okta SSO via aws sso login, AWS_PROFILE, ap-southeast-2). Results:

• Integration suite: all passing
• e2e set/check/run from a real project manifest: works — SecureString created at /secretspec/{project}/{profile}/{key} as documented
• Profile defaults, require_reason/audit interplay: all behave correctly with this provider
• URI with profile@region: SSO-sourced credentials resolve fine

One piece of design feedback on the layout: ?prefix= prepends to the fixed /secretspec/{project}/{profile}/{key} skeleton, so there's no way to point the provider at a pre-existing parameter hierarchy (e.g. /myapp/dev/DB_URL). Teams with established SSM layouts must migrate every parameter into the secretspec tree before adopting — a read-only escape hatch (e.g. path_template= or per-secret path override) would make incremental adoption much easier. Happy to test a follow-up if you go that way.

[domenkozar]

Thanks for testing this against a real account! This incremental-adoption case should already be covered by SecretSpec ref support. A SecretSpec key can point directly at the complete name of an existing Parameter Store parameter:

[profiles.production]
DB_URL = { 
  description = "Database URL", 
  ref = { item = "/myapp/dev/DB_URL" }, 
  providers = ["awsps://production@ap-southeast-2"]
}

For an awsps ref, item is the full parameter name (or ARN), so it replaces the convention path entirely: neither ?prefix= nor /secretspec/{project}/{profile}/{key} is prepended. These refs are read-only, and an optional version coordinate can select a numeric version or label.

The limitation compared with path_template= is that this mapping is explicit per secret, but it should avoid any migration for the incremental-adoption case you described. Would you be able to verify that this works with your existing hierarchy?

[james-heidi]

Thanks for testing this against a real account! This incremental-adoption case should already be covered by SecretSpec ref support. A SecretSpec key can point directly at the complete name of an existing Parameter Store parameter:

[profiles.production]
DB_URL = {
description = "Database URL",
ref = { item = "/myapp/dev/DB_URL" },
providers = ["awsps://production@ap-southeast-2"]
}
For an awsps ref, item is the full parameter name (or ARN), so it replaces the convention path entirely: neither ?prefix= nor /secretspec/{project}/{profile}/{key} is prepended. These refs are read-only, and an optional version coordinate can select a numeric version or label.

The limitation compared with path_template= is that this mapping is explicit per secret, but it should avoid any migration for the incremental-adoption case you described. Would you be able to verify that this works with your existing hierarchy?

Verified ref against our real hierarchy — works exactly as described:

• ref = { item = "/xiang-ref-test/DB_URL" } with providers = ["awsps://dev@ap-southeast-2"] resolves the parameter directly; neither
  ?prefix= nor the /secretspec/{project}/{profile}/{key} skeleton is prepended
• Coexists cleanly with convention-path secrets in the same profile (check and run both resolve the mix)
• Read-only is enforced: set on a ref secret fails with "awsps parameter references are read-only and cannot be written"

(Auth: Okta SSO via aws sso login, AWS_PROFILE, ap-southeast-2. Didn't exercise the version coordinate.)

This fully covers the incremental-adoption case — no migration needed. Thanks!