Do we have any plans ? or what is the direction from Redfish specification, in terms of limiting user roles based on Ethernet channels similar to IPMI. Whether we are planning to introduce the same, or it has been decided to abandon the same and implement single privilege / role to the user (instead of limiting it based on channel)?
Post by josephreynolds1 on Feb 11, 2020 17:25:20 GMT
I am trying to expand the question here...
Redfish's basic model is: an agent uses HTTPS to authenticate to a Redfish API server which then maps the identified username (aka account name) to a Role which then establishes which privileges are enforced.
I understand OpenBMC systems use Redfish and have multiple Ethernet ports (aka Ethernet jacks) which are connected to very-different places. Each of these ports can be wired to a different access channel. Typical examples: 1. Port connected to a private management network (the canonical setup). 2. Port connected only to the host system, for example. 3. Port normally unused available to a service agent who has the privilege of physical access (and a laptop to plug in).
Further, these access channels play a role in establishing security domains. For example: A. The BMC admin normally accesses the BMC via its management network. If needed, the admin can use their access the host platform to access to the BMC. B. The BMC admin normally accesses the BMC via its host platform. For example, the admin first gains root access to the host computer and then accesses the BMC. (This use case is typical for a standalone computer, but incompatible with rented bare-metal servers.)
A mechanism is desired to restrict access to the Redfish APIs based on the access channel. Questions:
I would like to see it properly described as well. The closest mechanism we have is roles assigned to accounts, so if you are looking to distinguish behavior, it should probably be based on account and not based on ingress method.
Thanks Joseph. Question is whether the same is earlier discussed and made any decision for it. I assume we might have discussed about the IPMI user roles, and limiting the same using channel roles (based on the network), so wondering, whether it was rejected for any reason, and we follow only user roles, or it has been postponed that time, to decide about it later.
Post by josephreynolds1 on May 4, 2020 15:15:04 GMT
The OpenBMC security working group discussed this on 2020-02-19 (minutes: docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI). There was not much active discussion, but one example was documented: > Idea: expose the list of channels within OpenBMC, and allow Account-Channel associations. For example, an interface to allow “admin2” to access the BMC only from “eth0” or “eth1” but not “eth2”.
I think we do have an understanding as to what you're asking. However, the issue we see is that we don't really understand why there needs to be semantics like that. To us, if a user can authenticate and has a given role, then that should be consistent on all interfaces. Why does the user's access need to behave differently based on the interface?
Different channels may have different exposure to possible threats an attacks. Also, with a channel-based access policy it is possible not to be afraid of several sorts of attacks from channels with limited access rights. E.g, allow administrative access only via a VPN tunnel or from a certain subnet.