All of lore.kernel.org
 help / color / mirror / Atom feed
* Use cases: what interface should admins be allowed to disable?
@ 2021-01-13 19:23 Joseph Reynolds
  2021-01-28 17:32 ` Joseph Reynolds
  0 siblings, 1 reply; 3+ messages in thread
From: Joseph Reynolds @ 2021-01-13 19:23 UTC (permalink / raw)
  To: openbmc

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.

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Use cases: what interface should admins be allowed to disable?
  2021-01-13 19:23 Use cases: what interface should admins be allowed to disable? Joseph Reynolds
@ 2021-01-28 17:32 ` Joseph Reynolds
  2021-01-28 17:40   ` Ed Tanous
  0 siblings, 1 reply; 3+ messages in thread
From: Joseph Reynolds @ 2021-01-28 17:32 UTC (permalink / raw)
  To: openbmc, Tom Joseph

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.
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
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Use cases: what interface should admins be allowed to disable?
  2021-01-28 17:32 ` Joseph Reynolds
@ 2021-01-28 17:40   ` Ed Tanous
  0 siblings, 0 replies; 3+ messages in thread
From: Ed Tanous @ 2021-01-28 17:40 UTC (permalink / raw)
  To: Joseph Reynolds; +Cc: openbmc

On Thu, Jan 28, 2021 at 9:34 AM Joseph Reynolds <jrey@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
> >
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-01-28 17:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-13 19:23 Use cases: what interface should admins be allowed to disable? Joseph Reynolds
2021-01-28 17:32 ` Joseph Reynolds
2021-01-28 17:40   ` Ed Tanous

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.