#7889 fedora-messaging credentials and UUID secrets for openQA
Closed: Fixed by kevin. Opened by adamwill.

Hi infra folks!

I am in the process of moving openQA (and other roles run on the same hosts, like check-compose, relvalconsumer and autocloudreporter) from fedmsg to fedora-messaging. For now I have the staging openQA server using the public 'fedora' / 'fedora.stg' identity to subscribe to the production / staging brokers respectively, and I'm just using UUIDs that are stored in the public variables as queue names. But I think it'd be better long term to have a specific identity for these roles, and probably for the UUIDs to be secrets.

So, I guess we'd want an account called openqa, with I guess a key and a cert file. The key file I guess would need to be a secret. I don't know if we should have a separate openqa.stg account for the staging broker or if we can just configure both brokers to accept the same identity. Then we'd want some UUIDs generated with uuidgen and put in the secrets store under these variable names:

openqa_scheduler_prod_uuid
openqa_scheduler_stg_uuid
openqa_wiki_reporter_prod_uuid
openqa_wiki_reporter_stg_uuid
openqa_resultsdb_reporter_stg_uuid
openqa_resultsdb_reporter_prod_uuid
check_compose_prod_uuid
check_compose_stg_uuid
relvalconsumer_prod_uuid
relvalconsumer_stg_uuid
autocloudreporter_prod_uuid
autocloudreporter_stg_uuid

Thanks! @puiterwijk @kevin @jcline (please let me know if these requests don't line up with how you expect things to be done).


FYI if you have a dedicated identity you'll have access to the internal vhost and don't need a secret queue name. Your queue name does need to be prefixed by the username you have in rabbitmq, but that's the only restriction.

The staging broker has a separate CA so you'll need a separate client keys. The pattern has been the users have a .stg prefix (I don't think that really helps since the broker url is different, but that's the current pattern), so you can make yourself queues named "openqa" and "openqa.stg" in production and staging respectively. You can make the user and queues with Ansible by including these roles in your playbook:

  - role: rabbit/user
    username: "openqa{{ env_suffix }}"
  - role: rabbit/queue
    username: "openqa{{ env_suffix }}"
    queue_name: "openqa{{ env_suffix}}.whatever_queue_name_makes_sense"
    routing_keys:
        - "routing.key1"
        - "routing.key2"

Where would I then get the keys from?

x509 certificates and keys still do need to be generated with the CN set to the name you create in RabbitMQ.

is there any point to creating the queues in ansible as opposed to just having them in the config file? I'm assuming that if you have them in the config file they get created on connection if they don't already exist, right?

Ordinarily yes, but at the moment the broker is configured to not allow AMQP clients (or anyone other than an admin) to make queues. Given that queues are namespaced I think this is a restriction we can probably relax. If someone messes up their client configuration we'll know who did it. I'd want @puiterwijk to okay that kind of change, though (plus I really don't want to be involved in the day-to-day operation of the production broker as I am a truly awful system administrator).

From IRC, just so I remember:

(jcline) There's going to be one more gotcha which is when you switch to the internal vhost, because you don't have permission to create objects, you need to set https://fedora-messaging.readthedocs.io/en/stable/configuration.html#passive-declares to true

so, to be clear, I'd like someone from releng to create the certs and keys needed for users openqa and openqa.stg, then I'll go ahead and do what @jcline suggested to create the user and queues...

I created the openqa and openqa.stg certs/keys.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Thanks! How can I use them in plays? What variable names or whatever should I use?

OK, got it mostly figured out. I think I have everything I need.

Metadata Update from @kevin:
- Issue status updated to: Open (was: Closed)

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata