The openstack Ussuri and Victoria versions no longer support the
RHEL7/CentOS7. Update the installtion guide for RHEL8/CentOS8 and RHEL9/CentOS9.
Change-Id: I6c9924c96c1f879b913b39f66878a8f9235ea18f
A contract migration will use the '--contract' flag, obviously.
Change-Id: I288bd0175834fdd3ee8d224f099e37b6294cb7ea
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
We can now auto-generate migrations. Document how this is done.
Change-Id: I754b0eb9eb74cd31f22440c64187d292c19ce4fa
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Section "OpenID Connect with keystone and horizon"
should use openid endpoint instead of saml2.
Change-Id: I147f3888c42e2d8d25a0ddd20f4e3974c8a38632
Signed-off-by: Arvid Requate <requate@univention.de>
This patch provides Keystone documents for OAuth2.0 client
authorization. The specification about new API is added to API
Reference. Also OAuth2.0 client credentials grant flow is added to
admin guide.
Implement: blueprint oauth2-client-credentials-ext
Change-Id: I6ac5835fb64a4e81f34f7b8631d255b2bb7f66da
Add the ability to autogenerate migrations. Because we need to support
different types of migration (expand and contract), this ends up being
significantly more complicated than what was needed in nova and cinder
and more akin to what was done in neutron. The key feature is here is
the use of an alembic hook called 'process_revision_directives', which
is called whenever one calls 'alembic revision --autogenerate'. We
extend this to allow us to hook into the autogeneration process and
ensure we only spit out directives for the relevant phase.
While we're here, we open up the Bobcat DB branch. This is similar to
what Neutron do (e.g. change I13ba740d245a46c41a969ff198e08ddff896eb1a).
Documentation will follow.
Change-Id: I17c9ff9508c5e2bd9521c18973af093d7550ab5a
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Since LDAP is now readonly, the current behavior might be
unexpected. By randomizing the list, we assure a more gradual
failure scenario if the first server on the list (as specified
by the user) fails.
Change-Id: I23f31bd85443784013a6aa158d80c7aeeb343993
Closes-Bug: #1953622
Resolves: rhbz#2024602
The service_type config param is crucial to successfully use
application credentials with access rules.
Closes-Bug: #1950464
Change-Id: I98d1cfcbd229f2939d900861f453efa996466c32
Training-labs had been officially retired as no maintainer.
The information of training-labs has been deleting in the openstack
documentatioan. It is not appropriate to continue the presentation in
note form here.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025586.html
[2] e78d74f105
Change-Id: I0ac3d05389041ac58fe2347171541ffaaf151fdf
We're going to add new alembic-based migrations shortly. These will live
in the 'keystone.common.sql.migrations' module. Prepare for this by
moving the existing migrations from ''keystone.common.sql' into a common
'keystone.common.sql.legacy_migrations' module.
Change-Id: I5ab7b010b21268977f73738e895bbd21442e9455
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This is now folded into the initial migration of the 'expand_repo'
repository. Previously, this was a dummy migration. We simply move
things across and remove any code that was trying to work with the older
repo since it's no longer necessary.
A release note is added, even though it's not really necessary since
nothing will change for users. It's more of a heads up that things are
afoot.
Change-Id: I59882d88fe593ec1ae37415b2157584f7f3c85f8
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
With the new release of SQLAlchemy(1.4.27) TypeDecorator used
in common/sql/core.py file started failing (below error). I am not sure
if it is valid issue in SQLAlchemy or in our code base and we need to
blacklist the SQLAlchemy 1.4.27 version in requirements. But to unblock
the gate let's exclude it from sphinx-apidoc target.
Error:
Warning, treated as error:
/opt/stack/keystone/keystone/common/sql/core.py:docstring of keystone.common.sql.core.DateTimeInt.process_bind_param:19:undefined label: types_typedecorator
-https: //zuul.opendev.org/t/openstack/build/b2ee464fa1554cb89dc8873486865151
Change-Id: I7de055c2b266430bf886e200c3d8829a48ae9600
This avoids the "String length exceeded." error, when using LDAP
domain specific backend in case the user uses a user id
attribute, which can exceed the previous constraint of 64 chars.
Change-Id: I923a2a2a5e79c8f265ff436e96258288dddb867b
Closes-Bug: #1929066
Resolves: rhbz#1959345
After reading through the documentation, I thought this sentence sounded
funny using 'within' and 'in' so close to each other. I updated it so
that it isn't quite so jarring.
Change-Id: I2619108216035a37823e53efb5a3f9fe6cfe5cbb
This commit updates the documentation for service api protection to
better describe the overall personas for system, domain, and project
users. It also adds some examples that show operators how to list users
with all role assignments on a particular target, which include a
superset of the existing examples.
Change-Id: I40dd33fc0afa0240c6b1cd48322fd988fc5524af
The secure RBAC work propogating throughout the community has led to
some interesting discussions about how to implement support for
``reader``. Specifically, should ``reader`` be used for auditing
deployments?
Some compliance targets, verified by third-party auditors, require
access to sensitive information (e.g., thinking about license keys in
glance images or volume type encryption metadata in cinder). The concern
raised among developers updating their default policies to use
``reader`` roles is if they should be using that role to protect
sensitive information, especially if it's the least-authoritative role
in the hierarchy between reader, member, and admin.
This documentation is supposed to assist deployers in understanding the
various personas that developers are implementing by default, but it
doesn't call out the complicated relationship we have with ``reader``
and auditing.
The change here proposes that we explicitly say that ``reader``
shouldn't be used to protect sensitive information, regardless of the
scope, because ``reader`` was designed to be the least-authoritative
role provided by keystone, by default. Instead, service developers
working to implement these personas consistently in other services
should keep sensitive information, if applicable to their API or
resources, at the ``admin`` tier of the hierarchy. This provides better
protection of sensitive information by not exposing is implicitly.
We can consider supporting a formal default role for auditing in the
future, but building it outside the default implied role tree so that
it's not implied to anyone with a role assignment. This will come at
another time and we can use implied roles to re-use all the work we've
done across OpenStack to implement support for ``reader``.
For now, ``reader`` should be viewed from the perspective of the
least-authoritative permissions grant-able to a given scope (e.g.,
system, domain, or project). Even if ``reader`` has limited use in
auditing deployments, it's still incredibly useful for operators
because they have a role they can grant to users with minimal trust, or
minimal permissions in the deployment.
This commit acknowledges the use-case for an elevated auditor role and
that it's something we can implement as a formal role in keystone in the
future.
Change-Id: Iea28faf1b3e63c7ab07e90808d2bc76ee3ee0612
As per the community goal of migrating the policy file
the format from JSON to YAML[1], we need to do two things:
1. Change the default value of '[oslo_policy] policy_file''
config option from 'policy.json' to 'policy.yaml' with
upgrade checks.
2. Deprecate the JSON formatted policy file on the project side
via warning in doc and releasenotes.
Also replace policy.json to policy.yaml ref from doc and tests.
[1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html
Change-Id: Ic65d2fd6ce7215b4a47a6fb41b9cbf991f27773b
In queens we added support for `keystone-manage bootstrap` to
populate a system admin role assignment:
I6b7196a28867d9a699716c8fef2609d608a5b2a2
The end-user/deployer facing documentation doesn't mention this though
and it should because it ensures deployers have a user for system-level
APIs.
Change-Id: I07616c1470cd89130250cc89635a508f48c2be06
Zuul