Pike: "Observer" or "read-only" admin access?
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? Is it in Pike (or more recent releases)? If it doesn't exist, is there a graceful way to make it happen, anyway? Thanks! -Ken
Hi Ken, On Thu, Apr 11, 2019, at 15:05, Ken D'Ambrosio wrote:
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? Is it in Pike (or more recent releases)? If it doesn't exist, is there a graceful way to make it happen, anyway?
Thanks!
-Ken
There is currently no read-only role that works out of the box in Pike or even in Stein. It's been a longstanding request and we're working on it: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/def... The problem now is that just creating a role named "reader" in keystone doesn't automatically fix the problem, we need to coordinate with every project to redefine their default policies to use the reader role instead of using a catch-all member/Member/__member__ role. In the mean time, you can modify the policies of the services you run to limit write operations to non-reader roles: https://docs.openstack.org/keystone/latest/admin/service-api-protection.html https://docs.openstack.org/oslo.policy/latest/admin/policy-yaml-file.html Hope this helps. Colleen
Hi Ken, On 4/11/19 5:05 PM, Ken D'Ambrosio wrote:
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?
Not yet, but it is something we're working towards.
Is it in Pike (or more recent releases)?
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. [0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
If it doesn't exist, is there a graceful way to make it happen, anyway?
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. 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. 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]. [1] https://docs.openstack.org/releasenotes/keystone/stein.html [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/def... [3] https://www.openstack.org/summit/denver-2019/summit-schedule/events/23005/ac...
Thanks!
-Ken
participants (3)
-
Colleen Murphy
-
Ken D'Ambrosio
-
Lance Bragstad