Open Stack

Hi Steve,

Thank you for highlighting the different aspects of it. I'm aware that this
is a journey with multiple steps along the way.

>From what we can see here in New Zealand, these are the kind of features
that would propel the adoption of OpenStack by larger organisations.

How is the cross project blueprint going? Are you getting traction with all
PTLs?

I wonder if a few mid-cycle meetings between the TC and PTLs would be
useful to facilitate and ensure progress on important cross-project
features like this.

Cheers,
Bruno

Catalyst Cloud
http://www.catalyst.net.nz/catalyst-cloud

Hey Bruno,

Dynamic policy is just one aspect of the issues keystone has with
authorization. We've also recently merged `implied roles`, which can be
seen here:
http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/implied-roles.html
Additionally, a few keystone core members have proposed this cross-project
spec: https://review.openstack.org/#/c/245629/ - an effort to create a
common policy scenario across all projects.

What I'm trying to convey is that we know there are shortcomings, it's on
our radar and we're trying to solve them. Feedback from operators is
paramount for us to make the right changes, so feel free to review the new
cross-project spec as well!

Steve Martinelli
OpenStack Keystone Project Team Lead

[image: Inactive hide details for Bruno L ---2016/02/18 04:47:13 PM---Hi
everyone, I thought I'd pass on feedback from a Catalyst Cloud]Bruno L
---2016/02/18 04:47:13 PM---Hi everyone, I thought I'd pass on feedback
from a Catalyst Cloud customer showing how

From: Bruno L <teolupus.ext at gmail.com>
To: openstack <openstack at lists.openstack.org>
Date: 2016/02/18 04:47 PM
Subject: [Openstack] [Keystone] Dynamic RBAC policy please?
------------------------------



Hi everyone,

I thought I'd pass on feedback from a Catalyst Cloud customer showing how
desperate people are for dynamic RBAC.

---

Subject: "kill me now"

"Sometimes Openstack just seems half-baked.  None of the ACL / IAM we need
for an enterprise solution is actually there, so I'm resorting to splitting
things across multiple accounts, but then I run into problems when I want
something like private ..."

---

I don't know how other cloud service providers feel about this topic, but
here in New Zealand we have several customers (in particular large ones)
needing more granular access control. Ultimately customers want to be able
to define their own roles and policies, ideally to a very granular level
(eg: Application X role allows user to perform all actions on compute
instance with ID 1234).

We are aware of the work proposed by Adam Young from RedHat (
*https://review.openstack.org/#/c/279379/*
<https://review.openstack.org/#/c/279379/>) and think he is absolutely on
the right track. We are even keen to help with the development work related
to this blueprint.

My main concern here is that such a change requires coordinated effort
across all projects to adopt the new dynamic RBAC mechanism. The key word
here is "coordinated", because from a governance point of view I think
OpenStack is lacking a few mid-cycle meetings where all PTLs and TCs agree
on a handful of cross-project blueprints that are essential to advance
OpenStack and ensure that all project teams working on them.

Keen to hear your thoughts about this matter.

Cheers,
Bruno

Catalyst Cloud
*http://www.catalyst.net.nz/catalyst-cloud*
<http://www.catalyst.net.nz/catalyst-cloud>
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : openstack at lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160220/3cb0f265/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160220/3cb0f265/attachment.gif>