All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Reynolds <jrey@linux.ibm.com>
To: openbmc <openbmc@lists.ozlabs.org>
Subject: New Redfish roles for ServiceRep and OemRep
Date: Fri, 14 Feb 2020 14:21:30 -0600	[thread overview]
Message-ID: <a0c457af-88a5-08dd-91fa-357f47dfe93d@linux.ibm.com> (raw)

This is to propose two new Redfish roles:

The BMC Administrator should not have access to operations involving the 
manufacturing process or servicing the host because these operations can 
damage the system or cause unintended operation.

Examples of access needed:
1. ServiceRep - Needs to access BMC operations to service the system, 
such as re-enabling locked out field replaceable units (FRUs) after 
replacing a defective unit.
2. OemRep - Needs to access BMC operations to test the host system, such 
as how the system responds to overheating.

I believe these roles are clearly distinct from role=Administrator or 
any other role.

The roles should NOT have access to the BMC's configuration or user 
management.  For example, the BMC admin will be able to lock out any 
service agent or OemRep using the regular user management functions.

Does anyone else need for these roles?  If so, I will try to get them 
into Redfish.


- Joseph

This topic was discussed briefly in the OpenBMC security working group, 
2019-11-27: 
https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI

See also: https://github.com/ibm-openbmc/dev/issues/1529

             reply	other threads:[~2020-02-14 20:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14 20:21 Joseph Reynolds [this message]
2020-02-17  7:29 ` New Redfish roles for ServiceRep and OemRep Thomaiyar, Richard Marian
2020-02-18  0:48   ` Joseph Reynolds
2020-03-05  0:26     ` Joseph Reynolds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a0c457af-88a5-08dd-91fa-357f47dfe93d@linux.ibm.com \
    --to=jrey@linux.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.