Kilo Update: Keystone

Welcome to the PTL overview series, where we will highlight each of the projects and the upcoming features that will be in the next OpenStack release: Kilo. These updates are posted on the OpenStack Foundation YouTube channel, and each PTL is available for questions on IRC.

OpenStack Identity PTL Morgan Fainberg began his webinar by giving a brief overview of the OpenStack Identity program goals for the Kilo Cycle: “To facilitate API client authentication, service discovery, distributed multi-tenant authorization, and auditing.”

Priorities

One of the main Kilo priorities for Keystone is to improve upon the specification process and ensure all major initiatives have an associated specification. Fainberg noted that Keystone started last cycle with the spec process and found it quite successful and that the work now is to lighten up the template to make it a bit easier and quicker to work with. He expects big improvements in the specification experience for both developers and proposers that will make the process useful for deployers.

The second priority is to work closely with operators and deployers of Keystone to ensure their needs are met. The team has made great inroads talking to both operators and deployers and expect them to be more involved in the development process, including participating in the Keystone mid-cycle meeting.

A third priority is to eliminate the accrued technical debt in the Keystone codebase. This means focusing on simplifying, making things more maintainable including how the split between identity and assignment works.

The fourth priority, and generally speaking, is improving the operator, user, and deployer experience. Fainberg stressed that the Identity team is looking for feedback from the community, and strengthening the working relationships in order to improve the experience.

Fainberg then went on to outline how those priorities and themes will be implemented across the many facets of the Identity project.

Continued Stability and Functionality

The Keystone project will continue keeping stability for the Keystone API, as well as making sure all interoperability is maintained between major versions of OpenStack. It’s important to note that you can run all the versions of OpenStack with new versions of Keystone and vice-versa.

The team is working to improve all integration with Keystone in the Python client libraries; specifically, including the Session object and making sure that the experience of utilizing these libraries is much better.

All new CLI developments will occur in the OpenStack client, and CLI support in Keystone Client itself has not been deprecated yet. Similarly, the V2 API for Keystone is frozen, but not yet deprecated.

Testing Enhancements

In the Kilo cycle, Fainberg expects to see significant improvements to testing. The layout of all tests are being restructured to be more logical, and a Functional Test suite is being developed, utilized and improved. Fainberg said that he’d like to make it possible to use these functional tests across any OpenStack deployment and verify that deployment meets the standards that are run on the upstream integration.

In addition, there are places to include more 3rd Part CI, improve testing coverage, and eliminate the download of python-keystoneclient for the test suite.

Federated Identity

Building on the success of Federated Identity that began in Icehouse, the Keystone team will continue to improve the user and developer story around it, make deployment options clear, significantly improve documentation, and then to maintain a full set of test suite (SAML2, ADFS, Keystone-to-Keystone, OpenID Connect, ABFAB) including third party CI where possible.

Hierarchical Multitenancy (HMT)

Hierarchical Multitenancy is now in the Keystone tree and it is supported fully as of Kilo-1. While this is the basic implementation supporting the project hierarchy, improvements will continue to support HTM throughout the Kilo cycle. This will include a “reseller” use-case, allowing for shared resources throughout the hierarchy, and limiting visibility and resource access within the hierarchy.

Tokens

Fainberg acknowledge that there have been a number of issues with Tokens over the lifespan of Keystone, and that the community can expect to see improvements in persistence, size issues, as well as improving how Tokens can be utilized to limit access for certain types of Tokens.

A top priority will be to clean up technical debt around token providers, as well as to make sure custom token providers have a clear and strictly enforced interface. Also, it will become very easy to develop your own custom token provider and provide new tokens needed in a tree, thus improving deployer experience.

We should also expect to have full support for Token Constraints, a limitation on how tokens can be utilized (such as requiring X509 client certificate, or cogross, or other form of authentication when interacting with main point).

Changes in API extensions

The major change to the Keystone REST API is the elimination of the concept of an extension. Keystone’s API will no longer have the in-tree extension, and instead will be moved to a simple classification of functionality, whether it’s a functionality that’s part of the directory API, or that is internal to Keystone itself.

Also, APIs and functionality will be classified in three ways: Stable, Experimental, and Out-of-Tree. New functionality will be added as experimental and promoted to stable once it has been proven out. Then Out-of-Tree functionality will only occur after a full cycle of being included in-tree.

OpenStack policy and policy.json

There are a number of exciting changes to how policies work in OpenStack, namely the Identity team will improve support for centralization of the Policy.json files. This allows Keystone to support dynamic policy files in the future, avoiding having to have varying assumptions within each end point. This ensures that there are the same default rules across all projects, allows for the elimination of hard-coded “is_admin” rules, and allows for a better RBAC default policy definition. The Keystone team is assisting in maintaining the rules engine, and is working to help ensure the graduation back to a full fledged external library.

Get Involved

If you’re interested in getting involved with the Identity project and community, get in touch with Morgan (user: morgainfainberg) on IRC and Freenode: #openstack-keystone

To see the full Keystone update, be sure to check out the webinar here: