[openstack-dev] 答复: [congress]role in Congress

Tim Hinrichs tim at styra.com
Thu Dec 3 15:33:08 UTC 2015


Hi Yali,

To support the kind of collaboration you describe, we have multiple
policies.  (By "policy" here I mean a collection of rules.)  One reasonable
workflow is to designate some policy (e.g. "library") to be where people
define predicates and complicated relations that are useful for writing
policy in general, and then have everyone else use the tables defined in
"library".  I'd imagine we could do the same kind of workflow in the UI.

By the way, your original patch never got merged (it's got a -1 on review
and a -1 on tests), so before looking into adding new features it'd be
great if we could finish off your original patch.  Let us know if you want
help.

Tim


On Mon, Nov 30, 2015 at 2:20 AM Masahito MUROI <muroi.masahito at lab.ntt.co.jp>
wrote:

> Hi Yali,
>
> I'm not sure which your concern is about UI by Horizon or for a policy
> in Congress.
>
> On 2015/11/30 16:27, zhangyali (D) wrote:
> > Hi Tim,
> >
> > In the implementation of Congress UI, I have realized that we need to
> > add role assignment. In many systems and cases, RBAC (Role-Based Access
> > Control) is an vital function which are beneficial to the division of
> work.
> >
> > I think we should have “admin” and “tenant” user at least.  The admin
> > user could define predicates or complicated relations used in the
> > violations, and tenant user could just use the predicates defined by
> > admin user.
> >
> > A typical example is that, the owner of network connected to VM should
> > be in the same group with the owner of this VM. In this example,
> > same_group is a predicates or complicated relations. It should be
> I think this depends on how admin writes policy and what service works
> as Congress datasource. If admin want to adopt the policy to specific
> tenant, user or group, admin writes an additional policy to affect them
> by the policy.
>
>
> > defined by admin user. And this predicate could be used by any tenant
> > user. In this way, some typical or common predicates could be defined in
> > a individual admin board, and other tenant user could choose which one
> > to use.
> On the other hand, this mentions about which user has permission to edit
> and to see a policy by Horizon.
>
> best regard,
> Masahito
>
> >
> > Yali
> >
> > *发件人:*Tim Hinrichs [mailto:tim at styra.com]
> > *发送时间:*2015年11月30日10:37
> > *收件人:*zhangyali (D); OpenStack Development Mailing List (not for
> > usage questions)
> > *主题:*Re: [openstack-dev][congress]role in Congress
> >
> > Hi Yali,
> >
> > We didn't discuss role assignment for service users in Tokyo.  Could you
> > explain a bit more what you need?
> >
> > Tim
> >
> > On Sun, Nov 29, 2015 at 7:33 PM zhangyali (D) <zhangyali369 at huawei.com
> > <mailto:zhangyali369 at huawei.com>> wrote:
> >
> >     Hi Tim and All,
> >
> >     I remember there is a topic named “role assignment for service
> >     users”in the Tokyo Summit. Since I have not heard any message of
> >     this topic. Does anyone could contribute some information for me? I
> >     think it is vital for my design of Congress UI in horizon. Thanks a
> lot!
> >
> >     Best Regards,
> >
> >     Yali
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> 室井 雅仁(Masahito MUROI)
> Software Innovation Center, NTT
> Tel: +81-422-59-4539,FAX: +81-422-59-2699
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151203/a7cf6be4/attachment.html>


More information about the OpenStack-dev mailing list