You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Core can send arbitrary (shell) commands to drones. Thus, it is very important to have a
well-designed security concept in place.
Therefore, I'd like to ask all of you:
How do you think security should be handled for:
core <-> drone communication?
core <-> client communication (the web front-end written in ember js)?
For people who haven't looked into the source code of core, drone and client yet, the communication
between those entities follows this pattern:
A drone polls core for new jobs via a HTTP GET request and communicates any generated output via primus (a web socket) to core. Client queries core via a REST API and displays information about jobs (current status, results, output etc.). Additionally it is planed that client gets live updates
from drones (trough core) via primus (job output / status etc.).
My random thoughts on securing all of this:
Some kind of transport layer security is needed (HTTPS). I am not sure whether we can delegate this to Nginx or something similar (see Core <-> drone authentication).
New jobs shouldn't be received by drones via polling the REST API of core. Instead they should be pushed from core to drones via primus (clients connect to core via primus; this channel is then used to push jobs from core to client)
Core needs to authenticate drones and drones need to know that they are really talking to core.
I thought web sockets + TLS would be a good solution for this (server + client-side certificates). This would also offer the added benefit of giving us drone blacklisting 'for free' via certificate revocation lists on the CA.
However, I am unsure on how to implement this with primus.
We need some kind of mechanisms which allows client to trigger some 'privileged' actions on core (stopping / restarting jobs etc.). I thought about using hapi-auth-jwt2 + some kind of OAUTH mechanism but the details on how to do this are still blurry (I've never done any oauth stuff).
Any recommendation on how to do this (or actual code contributions) would be more than welcome.
The text was updated successfully, but these errors were encountered:
I think doing token based authentication for everything would work nice, which would only require HTTPS for core, since core isn't sending anything to the drones (they are polling core). HTTPS can be handled in core via hapi, we would just have to have a config for the location of the certificates.
Users, drones, client, and third-party integrations could all use tokens which could be managed in core. Then as a user you can trigger a build against core through the curl/cli by just supplying the token and the payload (no username/password).
Your second point would require HTTPS for the drones as well as exposing them to the world, which is a hassle, since they are already polling core.
Core can send arbitrary (shell) commands to drones. Thus, it is very important to have a
well-designed security concept in place.
Therefore, I'd like to ask all of you:
How do you think security should be handled for:
For people who haven't looked into the source code of core, drone and client yet, the communication
between those entities follows this pattern:
A drone polls core for new jobs via a HTTP GET request and communicates any generated output via primus (a web socket) to core. Client queries core via a REST API and displays information about jobs (current status, results, output etc.). Additionally it is planed that client gets live updates
from drones (trough core) via primus (job output / status etc.).
My random thoughts on securing all of this:
I thought web sockets + TLS would be a good solution for this (server + client-side certificates). This would also offer the added benefit of giving us drone blacklisting 'for free' via certificate revocation lists on the CA.
However, I am unsure on how to implement this with primus.
Any recommendation on how to do this (or actual code contributions) would be more than welcome.
The text was updated successfully, but these errors were encountered: