Select this backend at runtime¶

Let a command-line tool turn --backend aws-kms into a working key service, without importing this package directly.

Activate it¶

Blank-import the module once, wherever your binary assembles itself:

import _ "gitlab.com/phpboyscout/go/encryption-aws-kms"

That is the whole interface. The package registers itself from init(), so the import is the activation — there is nothing to call.

Use it¶

service, err := encryption.LookupKeyService("aws-kms")
if err != nil {
    return err
}

deriver, err := service.Deriver(ctx, "alias/security-contact-v1-encrypt")
signer, err := service.Signer(ctx, "alias/security-contact-v1-certify")

encryption.KeyServiceNames() lists what a binary actually has, which is what to put in an error message when a user names one that is not there.

Why a registry rather than an import¶

A tool that supports several key services would otherwise depend on all of them — and on the cloud SDKs of the ones its user does not use. Registration inverts that: the consumer's build decides which providers exist, and the code that calls them names none.

It is the same arrangement go/signing uses for its backends, so a binary that does both signing and decryption follows one pattern rather than two.

Where the client comes from¶

The registry hands a service nothing but a key identifier, so this one builds a KMS client from the ambient AWS configuration chain — profile, SSO session, or instance role.

There is deliberately no default region. A default would mean calling a key in whatever account the ambient credentials happen to point at, so a missing region is ErrNotConfigured rather than a guess.

If you need to supply your own client — a custom endpoint, an assumed role, a client you share — construct NewDeriverForKey or NewSigner directly and skip the registry. It exists for the runtime-selection case, not to hide the constructors.