<div dir="ltr">Hi Yuki,<div><br></div><div>Sounds good. The Congress team will be at Austin next week at the summit. Most of the team will be at most of the events that you find by searching for "Congress". Let us know if you want to meet face-to-face to discuss further. </div><div><br></div><div><a href="https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=congress">https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=congress</a><br></div><div><br></div><div>Tim</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 18, 2016 at 6:31 PM Yuki Nisiwaki <<a href="mailto:uckey.1067@gmail.com">uckey.1067@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Tim,<br><br></div><div>Thanks.<br></div>Your information is very useful for me.<br><br></div></div></div><div dir="ltr"><div>>I know someone was doing what you are proposing to implement a sophisticated notion of quotas for Nova<br></div></div><div dir="ltr"><div></div>I'll read later and make use of it as sample program.</div><div dir="ltr"><br><div><br>>though there's been talk of a more dynamic policy.json in the past<br></div></div><div dir="ltr"><div>I didn't know there's been talk of a more dynamic policy.json.<br></div><div>So I tried to search "dinamic policy.json" and<br>I found the keystone blueprint (<a href="https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery" target="_blank">https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery</a>).<br></div><div>And this dynamical policy blueprint might adopt the pluggable policy backend.<br>So I thought we can consider to use congress as this backend.<br></div><div><br></div><div>I'll consider how to implement authorization system with above information as well.<br><br></div></div><div dir="ltr"><div><br>>One thing to think about is what kind of performance and availability
needs you have. Making Congress say Yes or No to every API call puts it
on the critical path.<br></div></div><div dir="ltr"><div>Your point is very useful for me.<br></div><div>Surely, I have to consider the performance problem.<br><br><br>> longer term we could look into more exotic options, such as the cloud
admin managing policy via Congress, and Congress distributing that
policy to the services that need it. Think of this as a mini-Congress
running on each service. This way, instead of each service contacting
Congress on every API call, the service could make the Yes/No decision
itself.<br></div><div>This future plan is very interesting. I think this architecture is also useful other than this time use-case.<br><br><br>Thanks your information, <br></div><div>and I'll put these information in order by myself, and consider how to achieve it.<br></div><div>I'm interested in Congress project, so I'll watch the activity of Congress.<br></div><div><br></div><div>Best regards.<br></div></div><div dir="ltr"><div><br></div><div>Yuki<br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-19 7:35 GMT+09:00 Tim Hinrichs <span dir="ltr"><<a href="mailto:tim@styra.com" target="_blank">tim@styra.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Yuki,<div><br></div><div>That description was very helpful. In short, policy.json doesn't work because the person setting policy is not permitted to change policy.json (which happens in part because policy.json has no API for controlling it). </div><div><br></div><div>In that case, using Congress makes sense. I know someone was doing what you are proposing to implement a sophisticated notion of quotas for Nova. As far as I know, Congress is the best option for your use case today (though there's been talk of a more dynamic policy.json in the past). You can find the plugin for Nova in the repo.</div><div><br></div><div><a href="https://github.com/openstack/congress/tree/master/contrib/nova" target="_blank">https://github.com/openstack/congress/tree/master/contrib/nova</a><br></div><div><br></div><div>One thing to think about is what kind of performance and availability needs you have. Making Congress say Yes or No to every API call puts it on the critical path. How many requests per second do you expect? If each one of those requests needs to talk to Congress, is the latency/throughput of a round-trip to another service going to be a problem? What happens if the network is partitioned and the other services cannot reach Congress for some period of time? Can you deny or allow all access until the network reconnects?</div><div><br></div><div>The Congress team is getting close to finishing a new architecture aimed at high-availability and high-throughput, so we'd love to hear more details about what you think you need. </div><div><br></div><div>Also, longer term we could look into more exotic options, such as the cloud admin managing policy via Congress, and Congress distributing that policy to the services that need it. Think of this as a mini-Congress running on each service. This way, instead of each service contacting Congress on every API call, the service could make the Yes/No decision itself, and Congress would update each mini-Congress as needed. That would give you low-latency and high-availability, even in the presence of network disconnections.</div><div><br></div><div>Tim</div><div><br></div></div><br><div class="gmail_quote"><div><div><div dir="ltr">On Sat, Apr 16, 2016 at 9:41 AM Yuki Nisiwaki <<a href="mailto:uckey.1067@gmail.com" target="_blank">uckey.1067@gmail.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi Masahito, Tim.<br><br></div>Thanks for your messages.<br><br>>> btw, I added [Congress] prefix in the subject.<br><div>Firstly thanks for your point, I'm beginner openstacker. So this information is very useful.<br></div><br></div><div>Move to main topic.<br><br>>So as Masahito mentioned, if you provide more details about your use case<br>>(in particular what kinds of information you need for making authorization<br>>decisions), <br><br></div>I supposed that we use OpenStack as Public Cloud which have multiple tenants.<br></div>So The cloud administrator on OpenStack who have the admin role in OpenStack<br>and The deployer who is in charge of creating OpenStack environment and providing service are not same.<br>So we desire some mechanism to enable the admin on OpenStack in tenant (or domain) to specify which service(or function) can the user to use.<br></div><br></div>>the usual way to authorize API calls in OpenStack is<br>>through policy.json. If I remember right, you can make a decision about<br>>whether an API call is permitted using (i) all the values in the API call<br>>and (ii) the Keystone role of the user making the request. I'm not sure if<br>>you can also use the actual userID of the person making the request or not,<br>>but as soon as you get to 10 users, you'll end up grouping individual users<br>>into roles anyway.<br><br></div>Surely, The policy.json have potential to cover above our needs.<br></div>But as I mentioned before, the deployer and administrator of OpenStack isn't same.<br></div>And the deployer want to restrict the admin from login to the server which start up api processes.<br></div><div>So the admin on OpenStack can't login to the servers of working api process.<br><br></div></div><div>But it can't definitely realized by policy.json.<br></div><div>If we prepare the api server that works changing policy.json and provide the users.<br></div><div>But I think this solution isn't very good. <br></div><div>There are many reason of making this solution bad.<br>first reason is to make the rule of policy.json complex.<br></div><div>second reason is that policy file is <span>distributed in many server and many directory.<br></span></div><div><br><br></div><div>The reasons I'm interested in congress are followings.<br></div><div> - Congress can centrally manage policy rule.<br></div><div> - Congress can change policy or add policy via API.<br></div><div>So honestly I don't concern about dynamical policy (e.g. depending on the policy, which network is connected to) in our use-case.<br><br></div><div><br></div><div>if you'll allow a slight digression, <br>If we integrate authorization mechanism to actual environment,<br></div><div>we will prepare the translator from authorization specific policy to datalog and <br></div><div>we don't expose the congress in order to improve usability in the user perspective.<br></div><div><br></div><div>Can this mail give the image of what I want to do to you?<br><div><div><div><br><div><div><div><div><div>Yuki<br></div><div>------------------------<br>>Hi Yuki,<br>><br>>As Masahito mentioned, the usual way to authorize API calls in OpenStack is<br>>through policy.json. If I remember right, you can make a decision about<br>>whether an API call is permitted using (i) all the values in the API call<br>>and (ii) the Keystone role of the user making the request. I'm not sure if<br>>you can also use the actual userID of the person making the request or not,<br>>but as soon as you get to 10 users, you'll end up grouping individual users<br>>into roles anyway.<br>><br>>That said, Congress would be valuable for authorization decisions IF those<br>>decisions require information other than (i) values in the API call and<br>>(ii) the role of the user making the request. For example, if you wanted<br>>to stop someone from deleting a Neutron network whenever there is a Nova VM<br>>attached to that network with status ACTIVE, then policy.json isn't<br>>adequate, and Congress makes sense.<br>><br>>So as Masahito mentioned, if you provide more details about your use case<br>>(in particular what kinds of information you need for making authorization<br>>decisions), we can help you pick the right tool.<br>><br>>Tim<br>><br>><br>><br>><br>>On Fri, Apr 15, 2016 at 1:06 AM Masahito MUROI <muroi.masahito at <a href="http://lab.ntt.co.jp" target="_blank">lab.ntt.co.jp</a>><br>>wrote:<br>><br>>> Hi Yuki,<br>>><br>>> This sounds interesting. AFAIK, there is no similar use-case you mentioned.<br>>><br>>> On 2016/04/15 10:13, Yuki Nisiwaki wrote:<br>>> > Hi openstacker working on congress.<br>>> ><br>>> > I want to implement the authorization mechanisms for each user, not role<br>>> > base.<br>>> > For example, User A can change security group, But User B can’t change<br>>> > security group like IAM feature of AWS.<br>>> ><br>>> > In order to achieve it,<br>>> > I’m considering whether can I utilize Congress feature.<br>>> > I am thinking somehow that I can achieve it by following step.<br>>> > 1. create policy for each user with datalog in congress<br>>> > 2. prepare the wsgi filter for each project that works confirming<br>>> > authorization of each user to Congress.<br>>> Could you clarify your usecase? I think it can be done by roles and<br>>> modifying policy.json. If you assume A and B are under some conditions,<br>>> what kind of condition do you want to use?<br>>><br>>> btw, I added [Congress] prefix in the subject.<br>>><br>>> ><br>>> > I think this use-case is very popular and there is someone who think<br>>> > same thing.<br>>> > But There is no information about it in any website (blog, presentation<br>>> > in summit).<br>>> > So why is there anyone who achieve it?<br>>> > or does this approach have anxious point?<br>>> > If you are interested in this approach or think same thing, I want to<br>>> > know it.<br>>> ><br>>> ><br>>> > Best regards<br>>> ><br>>> > Yuki Nishiwaki<br>>> > NTT Communitions<br>>> > Technology development<br>>> > Cloud Core Technology Unit<br>>> ><br>>> ><br>>> ><br>>> __________________________________________________________________________<br>>> > OpenStack Development Mailing List (not for usage questions)<br>>> > Unsubscribe:<br>>> OpenStack-dev-request at <a href="http://lists.openstack.org?subject:unsubscribe" target="_blank">lists.openstack.org?subject:unsubscribe</a><br>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>>> ><br>>><br>>> best regards,<br>>> Masahito<br>>><br>>><br>>> --<br>>> 室井 雅仁(Masahito MUROI)<br>>> Software Innovation Center, NTT<br>>> Tel: <a href="tel:%2B81-422-59-4539" value="+81422594539" target="_blank">+81-422-59-4539</a><br>>><br>>><br>>><br>>> __________________________________________________________________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: OpenStack-dev-request at <a href="http://lists.openstack.org?subject:unsubscribe" target="_blank">lists.openstack.org?subject:unsubscribe</a><br>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>>><br>>-------------- next part --------------<br>>An HTML attachment was scrubbed...<br>>URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160415/6e977044/attachment.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160415/6e977044/attachment.html</a>><br><br></div></div></div></div></div></div></div></div></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br></div></div>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>