Anzeige

Keystone Updates - Kilo Edition

OpenStack Foundation
5. Jan 2015
Anzeige

Más contenido relacionado

Presentaciones para ti(20)

Similar a Keystone Updates - Kilo Edition(20)

Anzeige
Anzeige

Keystone Updates - Kilo Edition

  1. OpenStack Identity Kilo Update Morgan Fainberg Identity PTL IRC: morganfainberg
  2. 2 To facilitate API client authentication, service discovery, distributed multi-tenant authorization, and auditing.
  3. 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. 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. 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. 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. 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. 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. 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. 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
Anzeige