openstack/releases
Code Issues Proposed changes

Add Train cycle highlights for keystone

Browse Source 
Change-Id: Ieb1ea44d33523059fc3c5f06d134627bd70bca36
This commit is contained in:
Colleen Murphy 2019-09-12 12:32:28 -07:00
parent 1749b02282
commit 6211bdd519
1 changed files with 35 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
deliverables/train/keystone.yaml
View File

@ -5,3 +5,38 @@ team: keystone
type: service
repository-settings:
openstack/keystone: {}
cycle-highlights:
- "All keystone APIs now use the default reader, member, and admin roles in
their default policies. This means that it is now possible to create a user
with finer-grained access to keystone APIs than was previously possible
with the default policies. For example, it is possible to create an
\"auditor\" user that can only access keystone's GET APIs. Please be aware
that depending on the default and overridden policies of other OpenStack
services, such a user may still be able to access creative or destructive
APIs for other services."
- "All keystone APIs now support system scope as a policy target, where
applicable. This means that it is now possible to set
``[oslo_policy]/enforce_scope`` to ``true`` in `keystone.conf`, which, with
the default policies, will allow keystone to distinguish between
project-specific requests and requests that operate on an entire
deployment. This makes it safe to grant admin access to a specific keystone
project without giving admin access to all of keystone's APIs, but please
be aware that depending on the default and overridden policies of other
OpenStack services, a project admin may still have admin-level privileges
outside of the project scope for other services."
- "Keystone domains can now be created with a user-provided ID, which allows
for all IDs for users created within such a domain to be predictable. This
makes scaling cloud deployments across multiple sites easier as domain and
user IDs no longer need to be explicitly synced."
- "Application credentials now support access rules, a user-provided list of
OpenStack API requests for which an application credential is permitted to
be used. This level of access control is supplemental to traditional
role-based access control managed through policy rules."
- "Keystone roles, projects, and domains may now be made immutable, so that
certain important resources like the default roles or service projects
cannot be accidentally modified or deleted. This is managed through
resource options on roles, projects, and domains. The ``keystone-manage
bootstrap`` command now allows the deployer to opt into creating the
default roles as immutable at deployment time, which will become the
default behavior in the future. Roles that existed prior to running
``keystone-manage bootstrap`` can be made immutable via resource update."