Use cases: what interface should admins be allowed to disable?

[Ed Tanous]

On Thu, Jan 28, 2021 at 9:34 AM Joseph Reynolds <jrey at linux.ibm.com> wrote:
>
> On 1/13/21 1:23 PM, Joseph Reynolds wrote:
> > What network interfaces does your BMC support?  Do you want to allow
> > the BMC admin to disable them?
> > Please help provide use cases and guidance.  This is for current work
> > in this area: https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39006
> >
> > Discussion:
> >
> > OpenBMC provides several network interfaces including:
> >  - HTTP - either as access to BMCWeb without transport layer security,
> > or as a redirect to HTTPS (pending review)
> >  - HTTPS - access to the BMCWeb server
> >  - SSH - access to both the BMC's command shell (port 22) and the
> > host's console (port 2200)
> >  - IPMI (RAKP)
> >  - NTP
> >
> > See detailed interface discussion here:
> > https://github.com/openbmc/docs/blob/master/architecture/interface-overview.md
> >
> >
> > BMCWeb currently implements a Redfish API (ManagerNetworkProtocol) for
> > the BMC admin to enable and disable network interfaces.  This
> > interface is being enhanced by the gerrit review linked above.  We are
> > trying to determine how this should work.
>
> We discussed a direction in the gerrit review.
> 1. Enhance BMCWeb to be able to enable & disable these interfaces.

nit: Not quite all the interfaces.  We discussed excluding disabling
HTTPS over an HTTPS interface, as it can easily lead to a user locking
themselves out.

> 2. Enhance the service config manager
> (https://github.com/openbmc/service-config-manager) with a block list,
> so distros can decide which services should remain always-enabled.  For
> example, the default could be that HTTPS is always enabled.
>
> Joseph
>
> >
> > I wrote down my preferences here:
> > https://github.com/ibm-openbmc/dev/issues/1763  and I understand
> > others will have different use cases.  So, the purpose of this email
> > is to understand how to move forward.  I also understand some use
> > cases will completely disable various interfaces.  For example, some
> > users may completely remove IPMI functions from the firmware image.
> >
> > For each interface, I see three possible configurations:
> > 1. The interface is not present in the image.  Naturally, the admin
> > shall have no way to enable this interface (because it is not
> > present).  For example, we want IPMI eventually to be configured out
> > of the image.
> > 2. The interface is present in the image but the admin shall have no
> > way to disable it.  For example, SSH is present and the admin has no
> > API to disable it.  Another example, disabling HTTPS would prevent
> > Redfish access, and then the admin may lock themselves out of the
> > BMC.  This is not a desirable situation.
> > 3. The interface is present in the image and the admin shall have a
> > way to enable and disable it.  For example, this capability already
> > exists in BMCWeb for IPMI and NTP.  The case for SSH is discussed in
> > issue 1763 linked above.
> >
> > How can these configurations be implemented?
> > 1. When the interface is not present in the image -- Write bitbake
> > recipes to configure/build the feature out of the image, and also
> > configure BMCWeb so it cannot enable/disable that interface.
> > 2. When the interface is present and should always remain enabled --
> > Configure BMCWeb so it cannot enable/disable the interface.
> > 3. When the interface is present and the admin shall have a way to
> > enable and disable it -- First, if needed, enhance the BMCWeb Redfish
> > API to allow the admin to enable and disable the interface. Then
> > configure BMCWeb to allow that.
> >
> > I propose project defaults as follows:
> >  - HTTP - interface present and redirects to HTTP / admin allowed to
> > enable and disable.
> >  - HTTPS - always enabled (the admin is not allowed to disable it)
> >  - SSH - present in the image & admin allowed to enable and disable
> >  - IPMI - present in the image & admin allowed to enable and disable
> >  - NTP - present in the image & admin allowed to enable and disable
> >
> > Oops, I wrote too much!  Feedback here or in the gerrit review is
> > appreciated.
> >
> > - Joseph
> >
>