<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font size="-1"><tt>Hi Ken,<br>
</tt></font><br>
<div class="moz-cite-prefix">On 4/11/19 5:05 PM, Ken D'Ambrosio
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2358baef1296b0d821e46c86fb457f96@jots.org">Hi, all.
Beginning to roll out a newer-than-what-we-had OpenStack release
-- likely to be Pike, "For reasons." (Which is still *worlds*
newer than Juno, where we are.) And I've been asked if there's
such a thing as an account (or ACL) that allows a user to read
everything, but write nothing. Googling, I see mention of such
things -- but nothing really firm. Does it exist? <br>
</blockquote>
<br>
<tt>Not yet, but it is something we're working towards.</tt><br>
<br>
<blockquote type="cite"
cite="mid:2358baef1296b0d821e46c86fb457f96@jots.org"> Is it in
Pike (or more recent releases)? </blockquote>
<br>
<tt>A few projects implemented support for better policy
configuration (nova and keystone) in Pike. During the Queens
development cycle there was a community-wide initiative to
register all policy defaults in code [0]. I'm mentioning this
because that work makes the changes required for a read-only role
a little easier to manage. At least until things get fixed
upstream.<br>
<br>
[0]
<a class="moz-txt-link-freetext" href="https://governance.openstack.org/tc/goals/queens/policy-in-code.html">https://governance.openstack.org/tc/goals/queens/policy-in-code.html</a><br>
</tt><br>
<blockquote type="cite"
cite="mid:2358baef1296b0d821e46c86fb457f96@jots.org">
If it doesn't exist, is there a graceful way to make it happen,
anyway?
<br>
</blockquote>
<br>
<tt>Yes (though it depends on you definition of "graceful".) Most
OpenStack services support a policy file that facilitates a way
for operators to specify the policies they want to use in their
deployment. For example, if you want to override
`identity:get_users = role:reader`, you would do that in
keystone's policy file. Each service has their own policy file,
and most will have defaults in code, so if you don't specify a
policy for a given API a default will be applied.<br>
<br>
There has been extensive work done in Pike, Queens, Rocky, and
Stein to make a read-only a first-class citizen in OpenStack. As
of the Stein release, only a handful of projects support it
out-of-the-box [1][2] (see keystone's Stein release notes for more
details on what exactly we worked on for this release). We're
hoping it will catch hold in some other services in the Train and
U development cycles.<br>
<br>
If you're going to be in Denver for the summit/forum/ptg there is
a hands-on lab scheduled to help people write custom policies
while we get things squared-away by default [3].<br>
<br>
[1] </tt><tt><a
href="https://docs.openstack.org/releasenotes/keystone/stein.html">https://docs.openstack.org/releasenotes/keystone/stein.html</a><br>
[2] </tt><tt><a
href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html</a><br>
[3] </tt><tt><a
href="https://www.openstack.org/summit/denver-2019/summit-schedule/events/23005/access-control-policy-hands-on-lab">https://www.openstack.org/summit/denver-2019/summit-schedule/events/23005/access-control-policy-hands-on-lab</a></tt>
<blockquote type="cite"
cite="mid:2358baef1296b0d821e46c86fb457f96@jots.org">
<br>
Thanks!
<br>
<br>
-Ken
<br>
<br>
</blockquote>
<br>
</body>
</html>