Closed izissise closed 1 year ago
This is a fantastic conversation to be having. Thank you for bringing this up. I see two options forward (feel free to make suggestions if there is an option I am not considering that you feel is viable!).
My first thought on 1 is that it is potentially a security hole for the project, but is probably a perfectly reasonable place to start.
I think my decision on the topic is just that, to start with an open and un-encrypted connection between the host daemon and the nested cell. We can make improvements on the connection in future PRs. Maybe it makes sense to do some sort of lower level access control that only allows connections from a given socket or something. Unsure at the moment.
If you have an opinion or suggestion on if we should generate TLS client material as described in 2. please open an issue on that topic specifically and we can introduce that change as we make a decision as a project.
Awesome!, thanks for the response! I'll do the following then:
Rebased on main
Because the daemon should not have access to the client key, it should not be able to reuse the client auth to communicate with the nested_auraed. Here we disable tls for proto message between the daemon and the cell.
This not really intended to be merged as is, but mostly to trigger the discussion on what are the security requirements for the communication between daemon and cells.
This pr is on top of https://github.com/aurae-runtime/aurae/pull/442