QA (public) » openQA Project (public)

I've just been talking about this with @szarate in the office. I'll update this ticket tomorrow as there actually is a clear use case behind this and also a few technical challenges we shouldn't overlook when coming up with a concept.

The use case as I understood it (G1)¶

I had a chat about the topic with @szarate. This use case is actually also CC-related.

So far we rely on a Wireguard tunnel for openQA workers outside the CC-zone to still be able to reach openQA and potentially embargoed content. We can make our lives easier and improve security even further by preventing unauthorized access to openQA assets (see #170380) because then we could allow access to openQA from outside the CC-zone and wouldn't need the Wireguard tunnel anymore. Then all assets (including repos) would be served by openQA and test code must not try to reach any other services within the CC-zone (like SMELT).

To support this approach the idea is to introduce "roles" which would be associated with "users" in openQA (where "users" can be openQA workers; in fact user accounts used by the workers are the most relevant here). It would work like this:

1. no role: The user can access everything according to their general authorization level (none, operator, admin) as before.
2. the user has role X: The user's access is restricted and/or extended further. The general authorization level is still used as a base.

As a start, the role "worker" would be interesting. It would forbid access to the web UI and many APIs leaving only APIs the worker actually needs. It would only allow downloading assets that are associated with the job the worker is working on.

Further remarks from my side¶

• I'm wondering whether we would really need to introduce roles for this use case, though. Maybe "worker" can just be another access level besides "none", "operator" and "admin".
• The fact that assets are served by NGINX and not by the Mojolicious web application complicates things. We also need to take that into account when working on #170380.
• openQA is currently not "zero-trust" (which is another buzzword which came up). Restricting the access to openQA assets (and job tokens and potentially other problematic information) would be a step towards that and also a relevant one. If we wanted openQA to be truly "zero-trust" we would probably have to restrict even read-only access on many pages for unauthenticated users. I'm not sure how relevant that would be for the use case.

@mkittler please do an architecture design before writting code, I would be fine with a paper solution, despite what G1 says, beyond what is needed for #170380