|
1 |
| -# broker |
2 |
| -FLUIDOS Broker |
| 1 | +<!-- markdownlint-disable first-line-h1 --> |
| 2 | +<p align="center"> |
| 3 | +<a href="https://www.fluidos.eu/"> <img src="./docs/images/fluidoslogo.png" width="150"/> </a> |
| 4 | +<h3 align="center">FLUIDOS Broker</h3> |
| 5 | +</p> |
| 6 | + |
| 7 | +# WAN Discovery – RabbitMQ Configuration Guide |
| 8 | + |
| 9 | +This repository provides an example of configuration to set up a RabbitMQ message broker for WAN-based discovery of FLUIDOS Nodes. |
| 10 | + |
| 11 | +## Prerequisites |
| 12 | + |
| 13 | +A vanilla RabbitMQ installation is required on your server. |
| 14 | +Refer to the official <a href="https://www.rabbitmq.com/docs/configure"> RabbitMQ Configuration </a> to determine the correct location of the rabbitmq.conf file based on your system. |
| 15 | + |
| 16 | +The provided `rabbitmq.conf` configuration enforces TLS peer authentication for both client and server communications. It configures RabbitMQ to use the default SSL port 5671 and disables the non-SSL TCP port 5672. The configuration also sets the Common Name (CN) of the SSL certificate as the authentication ID, additionally, it restricts access to the Management UI and `rabbitmqadmin` tools to localhost, enhancing the system’s security by limiting administrative access to the local machine only. |
| 17 | +To enable TLS-based authentication, activate the RabbitMQ TLS authentication plugin: |
| 18 | +`rabbitmq-plugins enable rabbitmq_auth_mechanism_ssl` |
| 19 | + |
| 20 | +## Certificate Issuance |
| 21 | + |
| 22 | +To enable TLS-based authentication, you must generate the self-signed root certificate and a server certificate issued by the root certificate. |
| 23 | +We use RSA 2048-bit encryption, and example configurations are provided below. |
| 24 | + |
| 25 | + openssl req -x509 -newkey rsa:2048 -keyout CA_privKey.pem -out CA_cert.pem -days 365 -config CA.conf |
| 26 | + |
| 27 | + openssl x509 -req -in serverCert/server.csr -CA CAcert/CA_cert.pem -CAkey CAcert/CA_privKey.pem -CAcreateserial -out serverCert/server_cert.pem -days 365 -sha256 -extfile serverCert/server.conf -extensions v3_req |
| 28 | + |
| 29 | + |
| 30 | +## User & Queue Configuration |
| 31 | + |
| 32 | +Some scripts rely on `rabbitmqadmin`, so ensure that an administrator user is properly configured and that the default "guest" user is restricted to localhost access only. |
| 33 | + |
| 34 | +From the `users.yaml` configuration, clients publish to the same exchange but use distinct routing keys, which correspond to their Common Name (CN) in their certificate. |
| 35 | +These routing keys determine message distribution across tiers (which act as exchanges). |
| 36 | +Each client is subscribed to its own private queue, which receives messages routed from the relevant tiers. |
| 37 | + |
| 38 | +The `setup.sh` script automates the setup of queues, permissions, exchanges, and bindings as defined in `users.yaml`. |
| 39 | +Client certificates and private keys, ensuring each client can authenticate securely. |
| 40 | + |
| 41 | +The `eraseRabbit.sh` script removes all queues, bindings, exchanges, and users, except for the default "guest" user, ensuring continued access via `rabbitmqadmin`. |
| 42 | + |
| 43 | +The `deleteUserBindings.sh` script removes all the bindings for the user passed as argument. |
| 44 | + |
| 45 | +Once the setup is over it it is possible to refine the configuration with specific `rabbitmqctl` and `rabbitmqadmin` commands to create more bindings. |
| 46 | +Previously issued certificates will continue to function as expected. |
| 47 | + |
| 48 | +## Message Routing & Permissions |
| 49 | + |
| 50 | +Each client can publish only using its assigned routing key to the defaultPeeringExchange and can subscribe only to its private queue. |
| 51 | +Clients are categorized into four arbitrary tiers for message routing. |
| 52 | + |
| 53 | +### A simple schema that illustrates a possible broker architecture |
| 54 | + |
| 55 | +<p align="center"> |
| 56 | +<img src="./docs/images/broker_server.jpg"/> |
| 57 | +</p> |
| 58 | + |
| 59 | +## Directory structure example compatible for setup.sh |
| 60 | + |
| 61 | + ~/ |
| 62 | + ├─ CAcert/ |
| 63 | + │ ├─ CA.conf |
| 64 | + │ ├─ CA_privKey.pem |
| 65 | + │ ├─ CA_cert.pem |
| 66 | + ├─ clientCert/ |
| 67 | + │ ├─ clientA_priv.pem |
| 68 | + │ ├─ clientA_cert.pem |
| 69 | + │ ├─ clientB_priv.pem |
| 70 | + │ ├─ clientB_cert.pem |
| 71 | + │ ├─ client.conf |
| 72 | + │ ├─ clientA_request.csr |
| 73 | + │ ├─ clientB_request.csr |
| 74 | + ├─ serverCert/ |
| 75 | + │ ├─ server_cert.pem |
| 76 | + │ ├─ server_privKey.pem |
| 77 | + │ ├─ server.conf |
| 78 | + │ ├─ server.csr |
| 79 | + ├─ users.yaml |
| 80 | + ├─ setup.sh |
| 81 | + ├─ cert_gen.sh |
| 82 | + ├─ eraseRabbit.sh |
0 commit comments