AWS Secrets Manager Configuration Extensions 2.0 is now generally available

AWS Secrets Manager Configuration Extensions 2.0 is now generally available

Version 2.0.0 of Kralizek.Extensions.Configuration.AWSSecretsManager is now generally available.

This release is a major refresh of the library, with a more explicit provider model, AWS SDK v4 support, improved diagnostics, OpenTelemetry support, batch retrieval, duplicate-key handling, and clearer behavior around secret identifiers and provider modes.

Install

dotnet add package Kralizek.Extensions.Configuration.AWSSecretsManager --version 2.0.0

NuGet: https://www.nuget.org/packages/Kralizek.Extensions.Configuration.AWSSecretsManager/2.0.0

Provider modes

Version 2.0 introduces a clearer split between the supported provider modes:

• AddSecretsManagerDiscovery(...) discovers secrets through ListSecrets.
• AddSecretsManagerKnownSecret(...) loads one explicitly configured secret.
• AddSecretsManagerKnownSecrets(...) loads a configured set of secrets.

Use discovery when the application should enumerate secrets. Use a known-secret provider when the application already knows exactly which secrets it needs.

Highlights

• AWS SDK for .NET v4 support
• BatchGetSecretValue support where appropriate
• duplicate-key behavior through DuplicateKeyHandling
• structured diagnostic events through SecretsManagerLogEvent
• OpenTelemetry tracing and metrics
• support for secret names, full ARNs, and partial ARNs where supported by AWS
• clearer handling of deleted or scheduled-for-deletion secrets
• updated guidance for migrating from the 1.x provider model

Compatibility

Version 2.0 is a major release and contains breaking changes from 1.x. In particular, the provider APIs are now intentionally explicit about whether secrets are discovered or configured in advance.

A dedicated migration document may follow. In the meantime, please open an issue for migration blockers, unexpected behavior, or documentation gaps.

The earlier beta and stabilization discussion is preserved in #116 for historical context.

This issue is a 2.0.0 release announcement rather than a defined implementation task. Start by reviewing the provider-mode and compatibility sections, then use the referenced 1.x context in #116 to identify migration gaps. Done would require a specific migration document or another clearly scoped documentation change, which the issue does not yet define.