<div dir="ltr">Ruan,<div><br></div><div>Good question! I should clarify that there would be no *default* policy file to maintain in the project source code, like in keystone currently [0]. All policy defaults would be coded into the project. Nova has already taken this approach with their policy file [1], which leaves them with nothing to maintain in tree (notice the absence of a sample policy file) [2]. A deployer can still customize policy by using a policy.json file, and those rules are treated as overrides for the defaults in code.</div><div><br></div><div>[0] <a href="https://github.com/openstack/keystone/blob/master/etc/policy.json">https://github.com/openstack/keystone/blob/master/etc/policy.json</a></div><div>[1] <a href="https://github.com/openstack/nova/blob/master/nova/policies/servers.py">https://github.com/openstack/nova/blob/master/nova/policies/servers.py</a></div><div>[2] <a href="https://github.com/openstack/nova/tree/master/etc/nova">https://github.com/openstack/nova/tree/master/etc/nova</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 19, 2017 at 8:35 AM, <span dir="ltr"><<a href="mailto:ruan.he@orange.com" target="_blank">ruan.he@orange.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_4048525803735285786WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Lance,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Your option 3 is not clear for me.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">You say that ‘</span>The result would 0 policy files to maintain in tree and everything would be in code.<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">’
Without this file, how can we define policies? Can user configure policies? <u></u>
<u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Ruan<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Lance Bragstad [mailto:<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>]
<br>
<b>Sent:</b> mercredi 18 janvier 2017 23:16<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions); <a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.<wbr>openstack.org</a><br>
<b>Subject:</b> Re: [openstack-dev] [keystone] 2017-1-11 policy meeting<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Looping this into the operator's list, too!<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Jan 18, 2017 at 2:13 PM, Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">Thanks to Morgan in today's policy meeting [0], we were able to shed some light on the reasons for keystone having two policy files. The main reason a second policy file was introduced was to recenter RBAC around concepts introduced in
the V3 API. The problem was that the policy file that came later [1] wasn't a drop in replacement for the initial one because it required new roles in order to work properly. Switching to the newer policy file by default would break deployers who did nothing
but implement the basic RBAC roles required by the initial version [2]. At the time there was no real way to "migrate" from one policy file to another, so two were maintained in tree. <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Consolidating to a single file, or set of defaults, has benefits for maintainers and deployers, so we covered paths to accomplish that. We were able to come up with three paths forward.<u></u><u></u></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal">
Drop support for the original/initial policy file and only maintain policy.v3cloudsample.json<u></u><u></u></li><li class="MsoNormal">
Leverage `keystone-manage bootstrap` to create the new roles required by policy.v3cloudsample.json<u></u><u></u></li><li class="MsoNormal">
Codify the existing policy file using oslo.policy as a vehicle to introduce new defaults from policy.v3cloudsample.json<u></u><u></u></li></ol>
</div>
<div>
<p class="MsoNormal">Everyone seemed to agree the 1st option was the most painful for everyone. Option 2 (and maybe 3) would more than likely require some sort of upgrade documentation that describes the process.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Without swaying anyone's opinion, I think I tend to lean towards option 3 because it sounds similar to what nova has done, or is going to do. After talking to John Garbutt about some of their nova work, it sounded like one of their next
steps was to re-evaluate all RBAC roles/rules now that they have them in code. If they come across an operation that would benefit from a different default value, they can use oslo.policy to deprecate or propose a new default (much like how we use oslo.config
for changing or deprecating configuration values today). From a keystone perspective, this would effectively mean we would move what we have in policy.json into code, then do the same exercise with policy.v3cloudsample.json. The result would 0 policy files
to maintain in tree and everything would be in code. From there - we can work with other projects to standardize on what various roles mean across OpenStack (hopefully following some sort of guide or document).<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm excited to hear what others think of the current options, or if there is another path forward we missed.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">[0] <a href="http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-01-18-16.00.log.html" target="_blank">http://eavesdrop.<wbr>openstack.org/meetings/policy/<wbr>2017/policy.2017-01-18-16.00.<wbr>log.html</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://github.com/openstack/keystone/blob/7f2b7e58e74c79e5a09bd5c20e0de9c15d9eabd0/etc/policy.v3cloudsample.json" target="_blank">https://github.com/<wbr>openstack/keystone/blob/<wbr>7f2b7e58e74c79e5a09bd5c20e0de9<wbr>c15d9eabd0/etc/policy.<wbr>v3cloudsample.json</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://github.com/openstack/keystone/blob/7f2b7e58e74c79e5a09bd5c20e0de9c15d9eabd0/etc/policy.json" target="_blank">https://github.com/<wbr>openstack/keystone/blob/<wbr>7f2b7e58e74c79e5a09bd5c20e0de9<wbr>c15d9eabd0/etc/policy.json</a><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Jan 11, 2017 at 11:28 AM, Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">Hey folks,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In case you missed the policy meeting today, we had a good discussion [0] around incorporating keystone's policy into code using the Nova approach.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Keystone is in a little bit of a unique position since we maintain two different policy files [1] [2], and there were a lot of questions around why we have two. This same topic came up in a recent keystone meeting, and we wanted to loop
Henry Nash into the conversation, since I believe he spearheaded a lot of the original policy.v3cloudsample work.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Let's see if we can air out some of that tribal knowledge and answer a couple questions.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">What was the main initiative for introducing policy.v3cloudsample.json?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Is it possible to consolidate the two?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">[0] <a href="http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-01-11-16.00.log.html" target="_blank">http://eavesdrop.<wbr>openstack.org/meetings/policy/<wbr>2017/policy.2017-01-11-16.00.<wbr>log.html</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json" target="_blank">https://github.com/<wbr>openstack/keystone/blob/<wbr>master/etc/policy.<wbr>v3cloudsample.json</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://github.com/openstack/keystone/blob/master/etc/policy.json" target="_blank">https://github.com/<wbr>openstack/keystone/blob/<wbr>master/etc/policy.json</a><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
<pre>______________________________<wbr>______________________________<wbr>______________________________<wbr>______________________________<wbr>_
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
</pre></div>
<br>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>