2
To facilitate API client authentication, service discovery,
distributed multi-tenant authorization, and auditing.
3
‣ Improve upon the specification process, ensure all major
initiatives have an associated specification
‣ Work more closely with the Operators and Deployers of
Keystone to ensure their needs are met
‣ Work towards eliminating the accrued technical debt in the
Keystone code base
‣ Improve the Operator, User, and Deployer experience
Keystone Kilo Priorities
4
‣ Continue to clearly support interoperability between major
OpenStack releases
‣ Improve all python-*client libraries with the Keystone Client
Session object/class
‣ Keystone Client CLI is frozen, new CLI development occurs
in OpenStack Client
‣ Keystone V2 API frozen, not yet deprecated
Continued Stability and Functionality
5
‣ Restructure testing layout to be more logical
‣ Develop and utilize Functional Test suite
‣ Include more 3rd Party CI
‣ Improve testing coverage
‣ Elimination of the git-download of python-keystoneclient for
the test suite
Testing Enhancements
6
‣ Continue building on the success of Federated Identity and
improve the user and deployer story around it
‣ Keystone-to-Keystone (via SAML2) Federated Identity
moved from experimental to stable
‣ Improved Documentation around all forms of Federated
Identity deployment
‣ Full test coverage for all supported forms of Federated
Identity (SAML2, ADFS, Keystone-to-Keystone, OpenID
Connect, ABFAB)
‣ Will utilize 3rd Party CI where possible
Federated Identity
7
‣ As of Kilo-1, Hierarchical Multitenancy is in-tree.
‣ Continued development and improvements around HMT
through the Kilo cycle
‣ “Reseller” use-case to be developed in the Kilo cycle
‣ Shared resources through the hierarchy
‣ Limit visibility and resource access within the hierarchy
Hierarchical Multitenancy (HMT)
8
‣ Cleanup technical debt around token providers
‣ Clear and strictly enforced interface for custom token providers
‣ Provide at least one provider that does not require token
persistence (eliminates token-table bloat)
‣ Eliminate the need for the complete catalog to be in the token
‣ Further develop token “constraints” (limitations on how the token
can be utilized)
‣ Full support for Revocation Events and deprecation of revocation list
Tokens: Persistence, Size, and Constraints
9
‣ Keystone API will no longer have in-tree “extensions”
‣ APIs and functionality will be one of three classes
‣ Stable
‣ Experimental
‣ Out-of-Tree
Changes in “API Extensions”
10
‣ Better support for centralization of Policy.json files in
Keystone
‣ Keystone Team to assist in maintaining policy.py
(oslo.policy)
‣ Support for “dynamic” policy files
‣ Same default rules across all projects
‣ Elimination of hard-coded “is_admin” rule
‣ Move to a better RBAC default policy definition
OpenStack Policy and Policy.json