This plugin is specifically for RabbitMQ features that integrate with AWS infrastructure services. If a feature doesn't require AWS services, it belongs in rabbitmq-server or other appropriate repositories instead.
While this project lives in the amazon-mq GitHub organization, it's designed
for anyone running RabbitMQ on AWS, not just Amazon MQ users. We welcome
contributions that help the community run RabbitMQ on AWS. The best features
are ones that solve problems many users face when deploying RabbitMQ on AWS
infrastructure.
This plugin is compatible with RabbitMQ version 4.2.0 or later.
This plugin enables AWS ARNs to be specified directly in RabbitMQ configuration instead of hardcoding sensitive values or values that require access to local filesystem. It automatically resolves ARNs at startup and replaces configuration values with actual content from AWS services. Resolved ARN content, such as X509 certificates, is not stored on disk - it's passed directly to RabbitMQ.
- AWS Secrets Manager (
GetSecretValue) - Recommended for passwords and private keys - Amazon S3 (
GetObject) - Recommended for public keys, certificate files and configuration files - ACM Private CA (
GetCertificateAuthorityCertificate) - Recommended for CA certificates - AWS STS (
AssumeRole) - Recommended for cross-account access
The plugin resolves AWS credentials using one of the following methods:
-
Assume Role - If
aws.arns.assume_role_arnis configured, assumes the specified IAM role before resolving ARNs -
Environment Credentials - If assume role is not configured, uses default AWS credential chain (EC2 IMDSv2, environment variables, credential files)
This plugin introduces new configuration keys that mirror existing RabbitMQ
configuration keys but with the aws.arns. prefix. These keys accept AWS ARNs
instead of literal values:
aws.arns.ssl_options.cacertfileaws.arns.ssl_options.certfileaws.arns.ssl_options.keyfileaws.arns.amqp_client.ssl_options.cacertfileaws.arns.amqp_client.ssl_options.certfileaws.arns.amqp_client.ssl_options.keyfileaws.arns.amqp10_client.ssl_options.cacertfileaws.arns.amqp10_client.ssl_options.certfileaws.arns.amqp10_client.ssl_options.keyfileaws.arns.management.ssl.cacertfileaws.arns.management.ssl.certfileaws.arns.management.ssl.keyfileaws.arns.management.oauth_client_secretaws.arns.auth_http.ssl_options.cacertfileaws.arns.auth_http.ssl_options.certfileaws.arns.auth_http.ssl_options.keyfileaws.arns.auth_ldap.ssl_options.cacertfileaws.arns.auth_ldap.ssl_options.certfileaws.arns.auth_ldap.ssl_options.keyfileaws.arns.auth_ldap.dn_lookup_bind.passwordaws.arns.auth_ldap.other_bind.passwordaws.arns.auth_oauth2.https.cacertfileaws.arns.auth_oauth2.oauth_providers.$name.https.cacertfile
Here is an example rabbitmq.conf that configures RabbitMQ's ssl_options via AWS ARNs:
aws.arns.ssl_options.cacertfile = arn:aws:s3:::private-ca-42/cacertfile.pem
aws.arns.ssl_options.certfile = arn:aws:s3:::private-ca-42/server_certficate.pem
aws.arns.ssl_options.keyfile = arn:aws:s3:::private-ca-42/server_key.pem
The above configuration will fetch the data from S3 and configure RabbitMQ as
though the X509 certificates were present on the local filesystem, without
writing any data to disk. The cacertfile setting will be translated to the
equivalent
cacerts
setting, and certfile / keyfile translated into the equivalent
certs_keys
setting.
NOTE: encrypted X509 certificates are not supported at this time.
Validating an authentication backend configuration on a running broker has
traditionally meant editing rabbitmq.conf, restarting the broker, observing
the result, and repeating -- an expensive guess-restart-guess loop. This plugin
adds a synchronous HTTP endpoint that answers whether a new auth config is viable
before it is applied:
PUT /api/aws/auth/validate/:method
Supported :method values are ldap, http, oauth, and tls. A viable
config returns 204 No Content; problems come back as a fixed set of
categorized error responses. The endpoint is admin-gated, opt-in, and disabled
by default. Secret material (bind passwords, certificates) is supplied by ARN
reference and resolved server-side rather than passed in the request body.
See AUTH_VALIDATION.md for the full reference: the per-method behaviour, request fields, response categories, security model, and the configuration keys needed to enable it.
A partially-degraded cluster node -- one whose host or uplink drops a large fraction of packets while the node still answers and participates -- is hard to spot with reachability-based health checks. This plugin turns the broker's existing node failure detector into per-node Prometheus metrics that attribute a degraded node so it can be replaced early:
rabbitmq_aws_node_health_peer_down_probability{peer="..."}
rabbitmq_aws_node_health_peer_down_suspected{peer="..."}
rabbitmq_aws_node_health_peer_down_confidence{peer="..."}
rabbitmq_aws_node_health_cluster_congested
Each node samples its per-peer reachability, gossips it to the others so every
node holds the full picture, and decides whether one node is degraded, or
whether the condition is cluster-wide (and so must not be blamed on a single
node). A dumb alarm can threshold rabbitmq_aws_node_health_peer_down_suspected to catch a
single degraded node, or watch the unlabelled rabbitmq_aws_node_health_cluster_congested
(1 when the condition is symmetric across the cluster) for uniform congestion.
The feature is admin-neutral, opt-in, and disabled by default.
See NODE_HEALTH.md for the full reference: the metrics, the detection logic, and the configuration keys needed to enable it.
Visit the GitHub Releases
page for this project to download the ez file for this plugin. Then, copy the
ez file to the correct location for your
RabbitMQ broker to find it. Finally, enable the plugin as described
in the official documentation.
See CONTRIBUTING for more information.
See CONTRIBUTING for more information.
See CONTRIBUTING for more information.
This project is licensed under the Apache-2.0 License.