---
launchpad: keystone
release-model: cycle-with-rc
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.
releases:
  - version: 16.0.0.0rc1
    projects:
      - repo: openstack/keystone
        hash: e860c69831289a800a1d7bb52e8621fc460f260b
  - version: 16.0.0.0rc2
    projects:
      - repo: openstack/keystone
        hash: dc9e9e32dfbf9fd9c58f9f8e2b35f0bcfd62328e
  - version: 16.0.0
    projects:
      - repo: openstack/keystone
        hash: dc9e9e32dfbf9fd9c58f9f8e2b35f0bcfd62328e
    diff-start: 15.0.0.0rc1
  - version: 16.0.1
    projects:
      - repo: openstack/keystone
        hash: 40cbb7bebd50276412daa1981ff5a7c7b3b899a5
  - version: 16.0.2
    projects:
      - repo: openstack/keystone
        hash: c65455965aec303b55bc76388314a2b96a2bc12c
  - version: train-em
    projects:
      - repo: openstack/keystone
        hash: c65455965aec303b55bc76388314a2b96a2bc12c
  - version: train-eol
    projects:
      - repo: openstack/keystone
        hash: 9d699a73fda748a6f280cbd61568b847316faa0a
branches:
  - name: stable/train
    location: 16.0.0.0rc1
release-notes: https://docs.openstack.org/releasenotes/keystone/train.html