Open Stack

On Sun, Oct 18, 2020 at 11:57 PM Dan Sneddon <dsneddon at redhat.com> wrote:

> Steve, Lars,
>
> I just wanted to throw an idea out there:
>
> Redfish requires user accounts. Is there a way to stretch this idea into a
> more general Redfish proxy? Ironic would have to create a temporary user
> account for Redfish in the BMC, and then provide the tenant an IP:port of a
> TCP proxy for the tenant to connect to.
>
> The TCP proxy would be deactivated when the node was deleted. When the
> node was cleaned, the user account would be removed. When nodes were
> scheduled, the Ironic-generated user accounts would be removed and
> recreated as needed based on the scheduling request. Ironic settings could
> be provided to control the access rights/group of the user accounts.
>
> A variant of this would create and manage the user account, but not
> provide a TCP proxy. Instead, perhaps the BMC location could be returned.
> This would not meet the criteria of not providing direct access to the
> hardware. We would have to remove accounts from the BMC when the node was
> deleted or require cleaning, but it could still potentially be less secure.
>
> A downside of the role-based user scheduling approach is that Ironic then
> requires credentials for the BMC that include user account management,
> which could run counter to security policy.
>
> On Sun, Oct 18, 2020 at 6:08 PM Steve Baker <sbaker at redhat.com> wrote:
>
>>
>>
>> On 17/10/20 7:29 am, Lars Kellogg-Stedman wrote:
>>
>> > In the work that we're doing with the Mass Open Cloud [1], we're
>>
>> > looking at using Ironic (and the multi-tenant support we contributed)
>>
>> > to manage access to a shared pool of hardware while still permitting
>>
>> > people to use their own provisioning tools.
>>
>> >
>>
>> > We don't want to expose the hardware BMC directly to consumers; we
>>
>> > want Ironic to act as the access control mechanism for all activities
>>
>> > involving the hardware.
>>
>> >
>>
>> > The missing part of this scenario is that at the moment this would
>>
>> > require provisioning tools to know how to talk to the Ironic API if
>>
>> > they want to perform BMC actions on the host, such as controlling
>>
>> > power.
>>
>> >
>>
>> > While talking with Mainn the other day, it occurred to me that maybe
>>
>> > we could teach virtualbmc [2] how to talk to Ironic, so that we could
>>
>> > provide a virtual IPMI interface to provisioning tools. There are some
>>
>> > obvious questions here around credentials (I think we'd probably
>>
>> > generate them randomly when assigning control of a piece of hardware
>>
>> > to someone, but that's more of an implementation detail).
>>
>> >
>>
>> > I wanted to sanity check this idea: does this seem reasonable? Are
>>
>> > there alternatives  you would suggest?
>>
>>
>>
>> As far as I'm aware, an IPMI host:port endpoint will manage exactly one
>>
>> baremetal host, with no obvious mechanism to specify which host to
>>
>> control when you have multiple hosts behind a single endpoint. These
>>
>> days with the rise of Redfish I think IPMI is considered a legacy
>>
>> interface now.
>>
>>
>>
>> I suspect a BMC interface is not the right abstraction for a
>>
>> multi-tenant baremetal API, that's why Ironic was started in the first
>>
>> place ;)
>>
>>
>>
>> If there are provisioning tools frequently used by the target audience
>>
>> of Mass Open Cloud which have poor Ironic API support then we'd like to
>>
>> know what those tools are so we can improve that support.
>>
>>
>>
>>
>>
>> > Thanks!
>>
>> >
>>
>> > [1] https://github.com/CCI-MOC/esi
>>
>> > [2] https://github.com/openstack/virtualbmc
>>
>> >
>>
>>
>>
>>
>>
>> --
> Dan Sneddon         |  Senior Principal Software Engineer
> dsneddon at redhat.com |  redhat.com/cloud
> dsneddon:irc        |  @dxs:twitter
>


Lars,
Please forgive my ignorance if I did not understand your question. Why not
just use Nova with the ironic driver? Nova won't tell a user about the
abstraction to metal and it's pretty easy to get setup and running with
Ironic. This way users can request a metal type that is predefined and the
rest is handled for them. This way you can keep consumers and admins
separate and provide that multi-tenant functionality without exposing any
critical details of the underlying infra.

-- 
~/DonnyD
C: 805 814 6800
"No mission too difficult. No sacrifice too great. Duty First"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201019/042c170f/attachment.html>