Container to Host Communications using D-Bus #541
Conversation
Signed-off-by: Mike Lazar <mihai_lazar@dell.com>
Add extra D-Bus security info
There was a problem hiding this comment.
Replying to previous comments from "dev-aziz"
- why D-Bus used specific listed services/activities alone, why can't it use for all the services? Can you add some guidelines to the document?
We have listed some possible examples. As mentioned in the community meeting, I will remove ZTD from this list. We can have a separate discussion about ZTD.
I'll also add guidelines about when to use the D-Bus mechanism.
- How to secure the users shouldn't misuse the critical host access to commands like reboot? Can you provide some guidelines around it?
This is already mentioned in the security section ("Security of D-Bus Communications"). Access to all DBus commands is protected through ACL rules in the DBus configuration file - only certain user or groups can access specific set of command. However, I want to make it very clear that RBAC is implemented in the SONiC Mgmt Framework and not DBus, thus RBAC is completely outside the scope of this document.
- How does host communicate to ex: reboot/warm reboot execution status to clients (containers issued commands to host)? How does D-Bus helps here?
DBus allows us to return the output of any command executed on the host in the DBus method reply. Since DBus methods are remote procedure calls, they return values , e.g. the string value returned by the reboot command. Same for all the other commands implemented using DBus (config save/restore, image upgrade etc.).
Reboot case: Note that as long as the device does not stop the SONiC mgmt framework before the latter had the chance to display the string returned by the reboot command (e.g. "COLD reboot initiated"), via DBus, that command will be displayed to the user. The behavior is exactly the same if we used another communication mechanism vs. DBus.
This is already described in section 3.1.
"D-Bus provides a reliable communication channel between client (SONiC management container) and service (native host OS) – all actions are acknowledged and can provide return values. It should be noted that acknowledgements are important for operations such as “image upgrade” or “config-save”. In addition, D-Bus methods can return values of many types – not just ACKs. For instance, they can return strings, useful to return the output of a command."
- Will the design provide some D-Bus service infrastructure level audit mechanism who does what w.r.t host commands like reboot/warm reboot etc
We can log the user name and group of the application which makes the request. However, in the case of SONiC management, a full command audit (for all commands, not just those requested via DBus) will be implemented by the REST server, in future releases.
Provided usage recommendations, clarified logs and security approach.
This document describes the high level design of container to host OS communications using D-Bus, and describes the infrastructure provided by the feature, with usage examples
|
@mikelazar does these guidelines apply when a process running on the host wants to initiate communication with a docker. I am working on a process and considering running it on the host and having it directly communicate with the redis container to access db. |
@toravir |
|
@mikelazar what is the another means to access Redis DB ? I am considering running PTP on Sonic and the recommendation is to run it on the host - https://github.com/sonic-net/SONiC/blob/master/doc/ptp/ptp.md |
@toravir In general, please ask this type of questions using the SONiC mailing lists. If I recall correctly, Redis DB/SONiC is configured to use a Unix domain socket for client (application) to server communications. That socket is available for all containers, and for the host as well. So you can just use the Redis DB client library (Python or Hiredis). There might be a SONiC Redis DB wrapper - but I do not recall exactly. However, please use that for SONiC you need to define a DB schema using YANG. Also, not sure who made the recommendation to run PTP on the host. This might be needed ONLY if you need to communicate with a non-standard Linux kernel module/driver directly (and even that's debatable in the case of SONiC). However, I do not see that dependency in the design document (the PHC driver seems to be standard in kernels >= 5.8). The only thing required for the host OS is to load the PHC driver, when PTP is enabled. Anyway, this is something to discuss in the SONiC community meetings (and possibly using the SONiC mailing lists). |
No description provided.