KubeMQ
ConnectorsAWS (SQS & SNS)How-to guides

Authentication

How the AWS connector authenticates SQS and SNS requests — SigV4 verification, the accept-any local-dev default, static credentials, and Casbin authorization.

The AWS connector authenticates every request with a hand-rolled AWS Signature V4 (SigV4) verifier (standard-library crypto only — no AWS SDK at runtime). It supports two postures: accept-any (the zero-friction local-dev default) and configured static credentials (a secured connector). Exactly one action — SNS ConfirmSubscription — is SigV4-exempt.

SigV4 verification

The verifier accepts both signature styles your SDK can produce:

  • header-styleAuthorization: AWS4-HMAC-SHA256 Credential=…, SignedHeaders=…, Signature=…;
  • query-style / presignedX-Amz-Algorithm=AWS4-HMAC-SHA256 plus the X-Amz-* query params.

The verification rules are the same in both styles:

RuleBehavior
Signature compareconstant-time (hmac.Equal).
Clock skew±15 minutes on X-Amz-Date.
Credential scope servicemust be sqs or sns.
Credential scope regionNOT enforced — any region signs successfully.
X-Amz-Content-Sha256: UNSIGNED-PAYLOADhonored verbatim.
X-Amz-Security-Tokenaccepted and ignored (no STS / session-token semantics).

Region is not enforced. Any AWS_REGION your SDK signs with is accepted; the connector's default ARN region segment is kubemq. The examples use us-east-1 purely for familiarity. See Migration from AWS.

Accept-any mode (the default)

When no credentials are configured, the credential store is empty: the verifier only parses the AccessKeyId and uses it as the ClientID. The middleware logs once on startup — aws connector running without credential verification. This is the default, intended for zero-friction local development.

Dummy credentials are still required. Even in accept-any mode the request must carry a syntactically valid SigV4 signature whose credential-scope service is sqs or sns. An unsigned request is rejected with IncompleteSignature — the only SigV4-exempt action is SNS ConfirmSubscription. The signature is not cryptographically checked, but its presence and shape are. So your SDK must be given an access key and secret (any value) to form the signature. Omitting them yields a "missing credentials" SDK error, not a connector error.

export AWS_ACCESS_KEY_ID="x"       # any value — used as the ClientID in accept-any mode
export AWS_SECRET_ACCESS_KEY="x"   # any value — the SDK needs it to sign
export AWS_REGION="us-east-1"      # not enforced

Configured static credentials

When Credentials / CredentialsData are set, SigV4 is fully verified:

  • the presented access key must match a configured AwsCredential.AccessKeyId;
  • the secret must match (a constant-time compare of the signature);
  • the authenticated ClientID becomes AwsCredential.ClientID (defaults to the AccessKeyId).

CredentialsData is a JSON (optionally base64-encoded) credential array — the env / operator path. See Configuration for the JSON shape. This is a getting-started / auth-banner toggle, not a separate example program.

The ConfirmSubscription exemption

A request with Action=ConfirmSubscription, no Authorization header, and no X-Amz-Algorithm query param bypasses SigV4 entirely (its ClientID becomes sns-confirmation). This is the only SigV4-exempt action — it exists so the SubscribeURL confirmation GET embedded in an SNS SubscriptionConfirmation envelope is usable as-is. A signed ConfirmSubscription is still verified normally. See SNS fan-out.

Casbin authorization

On top of SigV4, the connector applies per-channel Casbin checks:

  • SQS data-plane operations authorize write / read on sqs.{queue};
  • SNS topic management authorizes write on the pseudo-resource sns.{topic};
  • SNS fan-out applies a per-target write check on each sqs.{queue} it delivers to.

A denied SQS data-plane operation (for example SendMessage) returns AccessDeniedException (403).

Failure mapping

TriggerAWS error codeHTTP
Malformed SigV4 (including an unsigned non-ConfirmSubscription request)IncompleteSignature400
Unknown access key (configured-credentials mode)InvalidClientTokenId403
Bad signature / clock skew / tampered bodySignatureDoesNotMatch403
Casbin deny on a data-plane operationAccessDeniedException403

All authentication failures are audited as aws.auth.failure. See Error codes.

SigV4 over plain HTTP transmits the request unencrypted. Accept-any mode is for local development only. For production, terminate over the server's HTTPS listener — there is no AWS-specific TLS option; TLS comes from the shared server Security block. See Connectivity and security.

Was this page helpful?

On this page