Open Stack

On Tue, Sep 16, 2014 at 11:57 AM, Zane Bitter <zbitter at redhat.com> wrote:
> On 16/09/14 13:54, Devananda van der Veen wrote:
>>
>> On Sep 15, 2014 8:20 AM, "James Slagle"<james.slagle at gmail.com>  wrote:
>>>
>>> >
>>> >On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy<shardy at redhat.com>  wrote:
>>>>
>>>> > >
>>>> > >The initial assumption is that there is some discovery step (either
>>>> > >automatic or static generation of a manifest of nodes), that can be
>>>> > > input
>>>> > >to either Ironic or Heat.
>>>
>>> >
>>> >I think it makes a lot of sense to use Heat to do the bulk
>>> >registration of nodes via Ironic. I understand the argument that the
>>> >Ironic API should be "admin-only" a little bit for the non-TripleO
>>> >case, but for TripleO, we only have admins interfacing with the
>>> >Undercloud. The user of a TripleO undercloud is the deployer/operator
>>> >and in some scenarios this may not be the undercloud admin. So,
>>> >talking about TripleO, I don't really buy that the Ironic API is
>>> >admin-only.
>>> >
>>
>> When I say the ironic API is admin only, I'm speaking to the required
>> permissions for accessing it. One must be authenticated with keystone
>> with the "admin" privilege. Borrowing from the ops guide:
>
>
> In most contexts "admin only" means that the default policy.json file
> requires the "admin" role in the current project in order to access a
> particular API endpoint. If you are relying on the is_admin flag in the user
> context and not policy.json then it's likely you are Doing Keystone
> Wrong(TM).

http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json

There are no per-endpoint policies implemented in Ironic. This was
intentional when we started the project.

Also, there have been recent requests to begin providing read-only
access to certain resources to less-privileged users, so we may, in
Kilo, begin implementing more tunable policies.

>
>> " An administrative super user, which has full permissions across all
>> projects and should be used with great care."
>>
>> I'm not sure how TripleO is dividing operator and admin in the
>> undercloud - so I just want to be clear on what you mean when you say
>> "may not be the undercloud admin". Simply put, to use Ironic in the
>> undercloud, you must have "admin" privileges in the undercloud -- or
>> you need to disable Ironic's auth entirely.
>
>
> TripleO can presumably deploy any policy.json file they like in the
> undercloud. It's not entirely surprising that some operations that might are
> admin-only in an overcloud

Ironic isn't in the overcloud, so I'm not sure how this comparison is
appropriate.

> might need to be available in the undercloud to
> "ordinary" users - who, after all, have permissions to create entire
> overclouds - despite them not being admins of the undercloud itself.

Sure. Such a user, who has access to "create an overcloud", and would
be an admin in the overcloud they deployed, would be a regular user of
the undercloud, and have access to the undercloud Nova to provision
their workload. They would not be an admin in the undercloud, nor
would they have any need to talk directly to Ironic.

-Devananda