Public bug reported:
In keystone, when a user gets an unscoped token using a password and
their username, the unscoped token response contains a method list. This
method list will consist of ['password'], since it was the method used
to obtain the token. When the user goes to scope their unscoped
** Also affects: tempest
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1473567
Title:
Fernet tokens fail tempest runs
Status in Keystone:
** Also affects: keystonemiddleware
Importance: Undecided
Status: New
** Changed in: keystonemiddleware
Importance: Undecided => Low
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net
Public bug reported:
Keystone's current schema uses SQL's DATETIME format. Depending on the
version of SQL, it may or may not support sub-second accuracy/precision.
We should replace keystone's use of DATETIME with an integer timestamp.
With integer timestamps we can support sub-second accuracy r
Public bug reported:
The fernet token provider has sub-second format, but it is currently
truncated to .00Z. This is because the library (pyca/cryptography
[0]) that keystone relies on for generating fernet tokens uses integer
timestamps instead of floats, which loses sub-second accuracy. We s
Marking this as invalid based on Steve's comment. If there are things
that need to be addressed in http://specs.openstack.org/openstack
/keystone-specs/api/v3/identity-api-v3.html we can either reopen this
bug, or better yet, open a separate bug that is specific to the issue.
** Changed in: keyst
Hi Karan,
You should be able to enforce strict password checking in keystone [0].
The strict_password_check should pull in the max_password_length value
in it's check [1]. Strict password checking isn't enabled by default.
Try enabling that in your test and see if that helps. I was able to
create
Karan,
Valid point, when we first implemented the jsonschema validation layer
on keystone, we attempted to validate email addresses on user
create/update requests. The functionality for doing this already exists
in jsonschema. The reason we didn't was because the default keystone
identity backend
Hi Karan,
Keystone doesn't require passwords on user creation because the
authentication methods used by keystone are configurable [0]. It is
possible for a keystone deployment to use another authentication method
in-place of traditional password authentication. Because we can't
guarantee the way
** Also affects: keystone/liberty
Importance: Undecided
Status: New
** Tags added: liberty-backport-potential
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs
Public bug reported:
We currently forbid the ability of deleting the default domain [0] (or
at least make it really hard to do so). There is nothing in the update
domain flow that protects against disabling the default domain.
We should add the same check to prevent someone from accidentally
disa
Public bug reported:
When using fernet tokens, I'm unable to get a token if the
key_repository isn't writeable [0]. The main keystone process is only
required to read keys from the key repository. The keystone-manage
process must have write access to the key repository in order to
bootstrap keys.
Public bug reported:
Steps to recreate
1.) Generate a v2.0
token http://pasteraw.com/37q9v3y80tlydltujo7vwfk7gcabggf
2.) Pull token from the body of the response and use the /v3/auth/tokens/ GET
api call to verify the token
http://pasteraw.com/3oycofc541dil3d7hkzhihlcxlthqg4
Notice that the 'i
Steps to reproduce
1.) set use_syslog=true in keystone.conf
2.) make sure rsyslog(syslog) process is not running
3.) restart Keystone
http://paste.openstack.org/show/89191/
** Also affects: oslo
Importance: Undecided
Status: New
--
You received this bug notification because you are
** Description changed:
- It looks like Keystone hashes only PKI tokens -
https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L1399
- and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token in
https://github.com/openstack/keystonemiddlew
Public bug reported:
The Identity API lists `domain_id` as an optional attribute when
creating a project. If a `domain_id` is optional, it can be supplied in
the request as a valid id string, supplied in the request with value
None, or not supplied in the request at all.
Currently, the Keystone i
The implementation does make sure a `domain_id` is supplied in the
project reference:
https://github.com/openstack/keystone/blob/f4f0bdf092edf7ba6e74019f5524629fd2ad85ce/keystone/assignment/controllers.py#L399
This invalids this bug since the user doesn't *have* to specific a
`domain_id` in the r
Public bug reported:
The tests for Trusts leverage the test_v3.py module and are housed in
test_v3_auth.py. These tests use the new_trust_ref() provided in
test_v3.py to build new trust references [1]. The new_trust_ref method
is suppose to go through and build a list of role ids that can be used
** Also affects: keystone/icehouse
Importance: Undecided
Status: New
** Tags added: icehouse-backport-potential
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1358243
Title:
being superseded by json-home:
https://github.com/openstack/keystone-specs/blob/master/specs/juno/json-
home.rst
** Changed in: keystone
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keysto
>From bug 1340041 there has been a fix merged to handle the attribute
mapping [1]. Sam, I'd suggest recreating with that patch to see if that
part of your issue is resolved. As for the write access to AD, I think
Nathan's comment above helps clarify that situation/use case.
[1] https://review.ope
Andrey, you'll need to set 'https' in your keystone configuration in
order to use SSL with Keystone.
Maybe we can look for an opportunity to improve the documentation.
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Public bug reported:
Some things need cleanup in the ML2Manager.
1.) In the current ML2 Manager, we are using sys.exit(1) if the
network_type isn't found in self.drivers:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py#L70
Here we should probably throw an except
Public bug reported:
When implementing Keystone notifications for Trusts, an IndexError is
returned saying 'tuple index out of range'.
http://paste.openstack.org/show/61217/
This causes notification to fail when creating trusts in Keystone. I
believe the reason why args isn't "indexible" is beca
Public bug reported:
Steps to create:
1.) Create and instance, hosted on a Hyper-V system
2.) Create a new volume that is carved out of IBM Storwize V7K
3.) Confirm both are available/active
3.) Attach volume to instance
$ nova volume-attach ldbragst-instance ldbragst-volume auto
The followin
Public bug reported:
The keystone functional protection tests that use tempest are failing
during Neutron setup:
+ functions-common:is_service_enabled:1965 : return 1
+ functions-common:run_process:1575: time_stop run_process
+ functions-common:time_stop:2309 : local name
+
Public bug reported:
If you enable LDAP in a devstack deployment you get errors about
ldap_modify failing.
Example local.conf:
enable_service ldap
LDAP_PASSWORD=ldap_password
Failure:
LDAP_PASSWORD is nomoresecret
+ lib/ldap:install_ldap:133: local slappass
++ lib/ldap:instal
Public bug reported:
In order for keystonemiddleware to validate access rules it needs to be
configured with the service_type [0].
We should update the application credential documentation [1] to
describe this, or potentially add a new section to the admin guide so
that operators are aware they n
Public bug reported:
We've updated most policies in neutron to adhere to common personas
across OpenStack (system-admin, system-member, system-reader, project-
admin, project-member, project-reader).
In the process of updating the policies we changed the default policy
for listing external networ
Public bug reported:
In Rocky, keystone added a default role hierarchy. This was part of a
large initiative to improve RBAC across all OpenStack projects. That
effort is still underway today. Through the process of adopting the
default roles implemented in Rocky, OpenStack developers and operators
Public bug reported:
In Rocky, keystone added a default role hierarchy. This was part of a
large initiative to improve RBAC across all OpenStack projects. Through
the process of adopting the default roles implemented in Rocky,
OpenStack developers and operators have acknowledged that several
OpenS
Public bug reported:
In Rocky, keystone implemented support to ensure at least three default
roles were available [0]. The application credentials API doesn't
incorporate these defaults into its default policies [1], but it should.
For example, system administrators should be able to clean up
app
Public bug reported:
In Rocky, keystone implemented support to ensure at least three default
roles were available [0]. The EC2 credentials API doesn't incorporate
these defaults into its default policies [1], but it should.
For example, system administrators should be able to clean up
credentials
Public bug reported:
In Rocky, keystone implemented support to ensure at least three default roles
were available [0].
An endpoint group is a collection of endpoints that can be populated in a users
service catalog through association to projects. Ultimately, endpoint groups
are system-specifi
Public bug reported:
Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release [0]. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
limit and registered limit APIs. This is because there are some
Public bug reported:
In Rocky, keystone implemented support to ensure at least three default
roles were available [0]. The OS-EP-FILTER API doesn't incorporate these
defaults into its default policies [1], but it should. The association
between projects and endpoints are system-specific actions, b
Public bug reported:
In Rocky, keystone implemented support to ensure at least three default
roles were available [0]. The revocation list API doesn't incorporate
these defaults into its default policies [1], but it should.
Even though this API isn't really useful without PKI/Z tokens, we should
Public bug reported:
In Rocky, keystone implemented support to ensure at least three default
roles were available [0]. The token API doesn't incorporate these
defaults into its default policies [1], but it should.
For example, a system reader should be able to validate tokens for other
users, but
Public bug reported:
In Rocky, keystone implemented support to ensure at least three default
roles were available [0]. The trust API doesn't incorporate these
defaults into its default policies [1], but it should.
It would be useful for system members and readers to diagnose issues
with trusts, i
Public bug reported:
Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API.
The trust API and trust entities require projects in orde
Public bug reported:
A user came to use in IRC asking about caching feedback [0]. Using the
performance results they supplied (linked in the IRC conversation), we
noticed that keystone is actually validating tokens twice on every
request.
This is due to the fact keystone overrides the keystonemid
Public bug reported:
Keystone has a timeout configuration option for memcache [0]. Keystone's
definition of this option isn't actually used anywhere, so it appears to
be a broken knob.
In fact oslo.cache has a duplicate option that appears to be used
instead [1].
We should deprecate the keystone
Public bug reported:
Keystone provides multiple configuration options for operators to setup
LDAP connection pooling [0]. Connection pooling has the ability to
increase performance by keeping LDAP connection open and available for
use across threads within a single keystone process. It's not clear
Public bug reported:
System-scope was introduced in Queens [0] but recently we discovered a
weird case where system users aren't able to do things they should be
able to with system-scoped tokens when domain-specific drivers are
enabled.
For example, they are unable to list groups or users becaus
** Also affects: keystone/stein
Importance: High
Assignee: Lance Bragstad (lbragstad)
Status: In Progress
** Also affects: keystone/train
Importance: Undecided
Status: New
** No longer affects: keystone/stein
** Changed in: keystone/train
Status: New => Confir
** Also affects: keystone/rocky
Importance: Undecided
Status: New
** Changed in: keystone/rocky
Status: New => In Progress
** Changed in: keystone/rocky
Importance: Undecided => High
** Changed in: keystone/rocky
Assignee: (unassigned) => Lance Bragstad (
** Also affects: keystone/queens
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1843609
Title:
Domain-specific domain ID
** Changed in: keystone/queens
Importance: Undecided => High
** Also affects: keystone/trunk
Importance: Undecided
Status: New
** No longer affects: keystone/trunk
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Open
Public bug reported:
In Rocky, keystone implemented support to ensure at least three default
roles were available [0]. The project tags API or policies don't
incorporate these defaults into its default policies [1], but it should.
[0]
http://specs.openstack.org/openstack/keystone-specs/specs/key
Public bug reported:
Project resources in keystone can be tagged with simple strings called
tags. Operations for managing a project's tags should only be managed by
system administrators and not project-level or domain-level users.
The policies that protect project tags should understand system-s
Public bug reported:
Microsoft AD has a default attribute in its schema for users and groups
called objectGUID [0]. The attribute is assigned when new users and
groups are created.
If we attempt to use this attribute as a user's ID by setting
user_id_attribute=objectGUID, keystone throws an HTTP
Public bug reported:
Keystone provides a configuration option that allows users to page LDAP
responses [0].
You can disable paging by setting page_size to 0, which should return
all query data from LDAP in a single response.
I have an AD server with 10,000 users and I have paging set to 1,000. I
Public bug reported:
If you're using page_size [0] and are integrating keystone with an LDAP
server that supports paging (like Active Directory), it's possible to
see keystone memory footprint slowly increase over time.
The problem isn't as noticable with large page sizes (e.g., page_size =
1
Public bug reported:
We recently updated openstack/requirements upper constraints for Sphinx
to 3.4.2 [0]. Sphinx 3.4.2 breaks keystone master development (Wallaby)
git sha b0b93c03986f3bb40c5a2ec31ee37c83014e197a with the following
trace:
building [mo]: targets for 0 po files that are out of dat
Public bug reported:
When keystone implemented support for default personas (system-admin,
system-member, system-reader, domain-admin, domain-member, domain-
reader, project-admin, project-member, project-reader), we took the
stance that HTTP 403s should be returned for non-existent resources
outs
Public bug reported:
Several APIs in glance use a pattern where an image is fetched from the
backend before performing an operation, updating an image for example.
The API code for updating an image calls the image repository, which
ultimately enforces the policy for get_image [0][1]. This can be
*** This bug is a security vulnerability ***
Private security bug reported:
╭─ubuntu@glance-devstack ~/devstack ‹master*›
╰─➤ $ source openrc demo demo
Public bug reported:
Neutron recently made a bunch of great progress evolving policy check
strings to include default role support (admin, member, and reader) and
system-scope [0]. Please reference keystone's default role and persona
documentation for a primer on authroization patterns we're tryin
Public bug reported:
Nova instances need to be owned by a project, so users always call the
create server API with project-scoped tokens. Nova fetches the
project_id from the token/context object used in the request for
ownership of the instance.
Keystone supports other token scopes, which are mu
Public bug reported:
The new default policies in neutron help fix tenancy issues where users
of one project are not allowed to view, create, modify, or delete
resources within another project (enforcing hard tenancy).
With the new policies enabled by default, I'm able to view networks for
other p
Public bug reported:
Glance has four different layers that implement some portion of access
control logic:
1.) the controller layer
2.) the authorization layer
3.) the policy layer
4.) the database layer
Adding support for system-scope or better policy checks is difficult
because it need to be u
** Also affects: keystonemiddleware
Importance: Undecided
Status: New
** Also affects: keystoneauth
Importance: Undecided
Status: New
** No longer affects: keystone
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed
Public bug reported:
During the Xena PTG we discussed how to continue integrating the secure
RBAC effort into Horizon [0].
One improvement we agreed upon was for Horizon to use the user's
unscoped token to fetch authorization scopes (GET /v3/auth/projects, GET
/v3/auth/domains, GET /v3/auth/syste
Public bug reported:
Now that keystone supports system-scope as well as default roles,
several upstream OpenStack services are updating their default policies
to be more secure [0].
Horizon may need to understand how these services are configured via
policy to present the proper panels to certain
Public bug reported:
Keystone has a configuration option to control the maximum size of a
token `keystone.conf [DEFAULT] max_token_size` [0].
With Fernet tokens, the ideal token should be less than 255 characters.
This was due to initial design targets when developing non-persistent
tokens and to
Public bug reported:
Keystone supports notifications via oslo.messaging. Included with
oslo.messaging notifications is the ability to emit messages using AMQP
(e.g., rabbitmq).
Keystone uses notification extensively in its API to signal when
resources are modified (creating, updating, or deleting
** Changed in: keystone
Milestone: None => train-rc1
** Changed in: keystone
Status: In Progress => Fix Committed
** Changed in: keystone
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is s
ne/keystone/assignment/core.py",
line 1140, in create_system_grant_for_user'
b"'role_id': role_id"
b'keystone.exception.ValidationError: Role 4f86f7a9e6864eb0a6f74af7f7ef0c7c
is a domain-spec
I'm going to mark this as Invalid for the time being since we don't have
a plan to support MFA for non-SQL users. Please feel free to continue
using this bug report for discussion, though.
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are
Public bug reported:
I'm attempting to use tripleo's network isolation technique [0] on
stable/train, but my undercloud neutron service is failing during subnet
creation for the overcloud with a generic python KeyError:
2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager
[req-be6ef908
Public bug reported:
If two clients attempt to update the same user, they are susceptible to
a race condition in the update_user method of the sql driver:
I ran into this by using multiple (16) clients to run a script that
updates the password for a user:
#!/bin/bash
set -xo
function cleanup {
Public bug reported:
The v2.0 API has an /extensions path that helps discoverability of
extensions for v2.0 enabled for that deployment. When asking for v2.0
enabled extensions, you actually get APIs that are meant only for v3.
To recreate, just ask v2.0 for it's extensions, something like:
$ cu
Public bug reported:
The API reference for listing trusts declares support for ``page`` and
``per_page`` query parameters [0], but those don't seem to be supported:
http://paste.openstack.org/show/663481/
We should either update the documentation or include support for paging
trusts so that the
Public bug reported:
Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release [0]. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API. This is documented in each patch with FIXMEs [1].
The
** Changed in: keystone
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1714937
Title:
keystone returns 500 on password change
Public bug reported:
During the Queens release, keystone added support for a new scope type
called system. This extended the support for users and groups to not
only have roles on projects and domains, but also on a different entity
called the "system". This is an effort to make RBAC support more
** Summary changed:
- bootstrapping system administrator causes issues with tempest
+ Role assignment API doesn't prune system roles when querying role.id={role_id}
** Changed in: tempest
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engi
Public bug reported:
Keystone cleans up role assignments a user has on projects and domains
when deleting the user. This isn't true for system role assignments.
Instead, they are left after the user is deleted. I recreate the issue
by doing the following with a basic devstack install:
$ openstack
Public bug reported:
The whole purpose of the `keystone-manage bootstrap` command is to help
operators establish an admin account they can use to administer the rest
of the deployment. It does this by granting the admin user in the
bootstrap command an admin role on a project [0].
A system role a
Public bug reported:
Keystone cleans up role assignments a group has on projects and domains
when deleting the group. This isn't true for system role assignments.
Instead, they are left after the group is deleted. I recreate the issue
by doing the following with a basic devstack install:
$ openst
** Also affects: keystone/queens
Importance: High
Assignee: Lance Bragstad (lbragstad)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net
** Also affects: keystone/queens
Importance: High
Assignee: Lance Bragstad (lbragstad)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net
** Also affects: keystone/trunk
Importance: Undecided
Status: New
** Also affects: keystone/queens
Importance: High
Assignee: Lance Bragstad (lbragstad)
Status: In Progress
** No longer affects: keystone/trunk
--
You received this bug notification because you are a
** Tags added: queens-backport-potential
** Also affects: keystone/queens
Importance: High
Status: Triaged
** Also affects: keystone/rocky
Importance: Undecided
Status: New
** No longer affects: keystone/rocky
** Also affects: keystone/rocky
Importance: Undecided
S
Public bug reported:
Some information in tokens obtained with application credentials isn't
available unless caching is enabled. I was able to recreate this using
some of the tests in test_v3_trust.py and by setting
CONF.token.cache_on_issue to False, which resulted in a 500 because a
specific key
Public bug reported:
Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API. This is documented in each patch with FIXMEs [1].
The fol
Public bug reported:
Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API. This is documented in each patch with FIXMEs [0].
The fol
Public bug reported:
Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API. This is documented in each patch with FIXMEs [0].
The fol
Public bug reported:
Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API. This is documented in each patch with FIXMEs [0].
The fol
Public bug reported:
Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API. This is documented in each patch with FIXMEs [0].
The fol
Public bug reported:
Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API. This is documented in each patch with FIXMEs [0].
The fol
Now that we're in the Rocky development cycle, we've removed the uuid
token provider and the sql token storage driver, since it was slated for
removal this release [0].
[0] https://review.openstack.org/#/c/543060/
** Changed in: keystone
Status: In Progress => Invalid
--
You received thi
Public bug reported:
During the Rocky PTG, we reviewed the unified limit API as a group. One
of the things that became apparent during the discussion was that the
API shouldn't return a list of all limits when updating limits or
creating new limits.
Originally, the API was designed this way so th
Public bug reported:
The experimental unified limits API was discussed during the Rocky PTG.
One of the things people wanted to see supported was an optional
`description` attribute for limits. Supporting this will give users an
opportunity to describe a limit, much like they can describe other
th
Public bug reported:
Now that system scope is implemented and oslo.policy understands
different scope types. One of two things will happen when a token of the
wrong scope is used to access an API. Either a warning will be logged if
oslo.policy's enforce_scope is False, or an exception will be rais
Public bug reported:
When you setup a user with a role assignment on a domain and then a role
assignment on a project "acting as a domain", you can't actually remove
them. The following pastes sets up the environment:
http://paste.openstack.org/show/695978/
Which results in the following when a
That appears to be an oslo.messaging configuration option [0]. Keystone
will "inherit" and expose them through the configuration library [1].
Working with the oslo community directly might help if you're having
configuration issues.
Is there a specific issue with keystone's usage of the oslo.messa
I'm not sure I completely understand this bug report, but based on the
information it has to do with the password authentication API [0] [1].
The only response parameter that isn't in the body of the response when
authenticating in the X-Auth-Token header. Which is documented correctly
and the impl
No worries, Alain. Thanks for the update.
** Changed in: keystone
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1752382
Title:
Public bug reported:
We have a document in our administrator guide that describes what tokens
are, different scope types, and token providers [0]. While this is good
information, we could elaborate on it a bit more to make the document
even more useful:
- Different types of scopes should have ex
1 - 100 of 354 matches
Mail list logo
