Describe the business value of consistent RBAC

This has come up several times discussing community goals, but the
effort it going to require people to do the work. This commit attempts
to describe the benefit that a consistent RBAC implementation has for
the entire OpenStack platform and people who use it.

Change-Id: I3e5ef86df320f2fbe945926bff3cc8d76839d3fe

reference/help-most-needed.rst

@@ -341,3 +341,86 @@ Contact
 For questions about getting involved with this initiative, reach out to the
 OpenStack Discuss mailing `list
 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss>`_.
+
+7. Consistent Role Based Access Control
+=======================================
+
+Description
+-----------
+
+OpenStack is comprised of APIs that allow users to manage physical and virtual
+infrastructure. Contributors wrote these APIs for end users and operators
+alike. With tenancy being a pillar of OpenStack's technical vision, ensuring
+isolation between users and layers of the infrastructure is imperative to
+OpenStack's long-term success.
+
+The OpenStack project has grown a tremendous amount of functionality over the
+last several years. Unfortunately, evolution in the way services protect their
+APIs failed to maintain pace with feature development. As a result, services
+today do not protect APIs in ways that expose functionality effectively to
+users, support security requirements, reduce operational complexity for
+operators, or aid interoperability.
+
+Since the Pike release, there has been renewed efforts to improve tools and
+libraries for contributors to use to correct these issues.
+
+Value
+-----
+
+Increased Functionality
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Currently, most OpenStack services have a very binary approach to RBAC
+enforcement. This approach usually handicaps new functionality from being
+exposed to users because users typically do not fall in one of two camps.
+Contributors either need to lock down the feature to only system
+administrators, or open it up to nearly every user in the deployment. This is
+especially true for APIs that expose details about multiple tenants.
+
+Implementing better API protection allows contributors to expose more
+functionality to end users and operators by default. Lowering the bar for users
+to access a feature means more opportunities for feedback loops, more end users
+getting access to the functionality they need, and makes OpenStack more usable
+overall.
+
+Enhanced Security
+~~~~~~~~~~~~~~~~~
+
+OpenStack has a wide variety of users. Auditing APIs and adjusting default
+access control increases security across the entire OpenStack platform. This
+exercise gives contributors the ability to provide secure defaults for new
+deployments. Reasonable default values that are inherently secure makes it
+easier for organizations with strict security requirement to deploy OpenStack.
+
+Reduced Operational Complexity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Today's RBAC enforcement implementation lacks secure defaults, but it is
+somewhat configurable. Deployments that must have a more secure enforcement
+implementation are forced to maintain arduously complex configuration files.
+Furthermore, many organizations re-implement similar use cases.
+
+Interoperability
+~~~~~~~~~~~~~~~~
+
+Because policy configuration gives deployments the flexibility to maintain
+complicated policies at their own expense, it is common to see many
+organizations solve the same problem. Unfortunately, it's unlikely many of them
+are sharing the same solution. This pattern impedes interoperability between
+deployments, making it frustrating for users interacting with different
+OpenStack clouds.
+
+Offering a reasonable set of roles and implementing basic RBAC improves
+interoperability by not requiring each organization to solve the same problem
+individually.
+
+Contact
+-------
+
+For more information on how to contribute to this initiative, please read the
+`authorization documentation`_ dedicated to describing the problem.
+For questions about getting involved with this initiative, reach out to the
+OpenStack Discuss mailing `list`_.
+
+.. _authorization documentation: https://docs.openstack.org/keystone/latest/contributor/services.html#why-are-authorization-scopes-important
+.. _list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss