[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped
If it is not fixed in Nova it is not fixed in Keystone, as the solution has to start there. ** Changed in: keystone Status: Fix Released => Confirmed -- 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/968696 Title: "admin"-ness not properly scoped Status in Cinder: Fix Released Status in Glance: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (keystone): Confirmed Status in neutron: Fix Released Status in OpenStack Compute (nova): Confirmed Status in puppet-keystone: Invalid Bug description: Fact: Keystone's rbac model grants roles to users on specific tenants, and post-keystone redux, there are no longer "global" roles. Problem: Granting a user an "admin" role on ANY tenant grants them unlimited "admin"-ness throughout the system because there is no differentiation between a scoped "admin"-ness and a global "admin"-ness. I don't have a specific solution to advocate, but being an admin on *any* tenant simply *cannot* allow you to administer all of keystone. Steps to reproduce (from Horizon, though you could do this with the CLI, too): 1. User A (existing admin) creates Project B and User B. 2. User A adds User B to Project B with the admin role on Project B. 3. User B logs in and now has unlimited admin rights not only to view things in the dashboard, but to take actions like creating new projects and users, managing existing projects and users, etc. Note: See changes ongoing under https://bugs.launchpad.net/neutron/+bug/1602081 which is required before policy changes can enforce. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1936686] Re: Install and configure in keystone: after keystone installation, there is no /etc/keystone folder
THis is an installer specific issue and not with the Keystone upstream project. The .deb should be creating the /etc/keytstone directory on install. PLease open the bug with the packager. Note that the page linked is specific to Ubuntu. ** Changed in: keystone Status: New => 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/1936686 Title: Install and configure in keystone: after keystone installation, there is no /etc/keystone folder Status in OpenStack Identity (keystone): Invalid Bug description: Keystone installation is not generating the /etc/keystone folder. Thus, I cannot configure the service. This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [X] This doc is inaccurate in this way: after keystone installation (apt install keystone), there is no /etc/keystone folder. This way, I cannot configure the Keystone service (keystone.conf) - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - The mailing list: https://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 19.0.1.dev1 on 2019-09-18 18:54:05 SHA: f510c806de3e20cdedd55291cd58dafa59398bec Source: https://opendev.org/openstack/keystone/src/doc/source/install/keystone-install-ubuntu.rst URL: https://docs.openstack.org/keystone/wallaby/install/keystone-install-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1936686/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1939879] Re: Failed to discover available identity versions when contacting http://controller1:35357/v3. Attempting to parse version from URL.
The Keystone server was down and the message was reported by the client.
** Changed in: keystone
Status: New => 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/1939879
Title:
Failed to discover available identity versions when contacting
http://controller1:35357/v3. Attempting to parse version from URL.
Status in OpenStack Identity (keystone):
Invalid
Bug description:
Failed to discover available identity versions when contacting
http://controller1:35357/v3. Attempting to parse version from URL.
root@controller1:~# . admin-openrc
root@controller1:~# openstack token issue
Failed to discover available identity versions when contacting
http://controller1:35357/v3. Attempting to parse version from URL.
Unable to establish connection to http://controller1:35357/v3/auth/tokens:
HTTPConnectionPool(host='controller1', port=35357): Max retries exceeded with
url: /v3/auth/tokens (Caused by
NewConnectionError(':
Failed to establish a new connection: [Errno 111] Connection refused',))
root@controller1:~#
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1939879/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped
** Changed in: neutron Status: Triaged => Fix Committed ** Changed in: nova Status: In Progress => Fix Committed ** Changed in: puppet-keystone Status: New => 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/968696 Title: "admin"-ness not properly scoped Status in Cinder: Fix Released Status in Glance: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Committed Status in OpenStack Compute (nova): Fix Committed Status in puppet-keystone: Invalid Bug description: Fact: Keystone's rbac model grants roles to users on specific tenants, and post-keystone redux, there are no longer "global" roles. Problem: Granting a user an "admin" role on ANY tenant grants them unlimited "admin"-ness throughout the system because there is no differentiation between a scoped "admin"-ness and a global "admin"-ness. I don't have a specific solution to advocate, but being an admin on *any* tenant simply *cannot* allow you to administer all of keystone. Steps to reproduce (from Horizon, though you could do this with the CLI, too): 1. User A (existing admin) creates Project B and User B. 2. User A adds User B to Project B with the admin role on Project B. 3. User B logs in and now has unlimited admin rights not only to view things in the dashboard, but to take actions like creating new projects and users, managing existing projects and users, etc. Note: See changes ongoing under https://bugs.launchpad.net/neutron/+bug/1602081 which is required before policy changes can enforce. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1842397] Re: Possibility for project level roles ?
For these kinds of operations, you use role assignment inheritance. Do not attempt to enforce policy on parent project ID. I wrote up an article about this about a year back. CloudForms is just the consumer, but the rules are the same. https://adam.younglogic.com/2018/02/openstack-hmt-cloudforms/ ** Changed in: keystone Status: New => 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/1842397 Title: Possibility for project level roles ? Status in OpenStack Identity (keystone): Invalid Bug description: Hi Team, I want to create project level roles, where this role should allow granting child-project management permissions to a user. It should allow a bearer of the role to create, update and list child-projects underneath a common parent project (the role-assignment of the user would be attached to the parent project). i added the below to policy.json "admin_and_matching_parent_project_id": "rule:admin_required and domain_id:%(project.domain_id)s and parent_id:%(project.parent_id)s", "identity:create_project": "rule:cloud_admin or rule:admin_and_matching_project_domain_id or rule:admin_and_matching_parent_project_id or role:project_admin", Below are my concerns: 1. the user should be part of admin project ? else i get The request you have made requires authentication. (HTTP 401) 2. How to restrict project creation to a specific parent project ? Does it work in production ? Do i create a parent_project_id column as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1235222 https://specs.openstack.org/openstack/keystone-specs/specs/juno/hierarchical_multitenancy.html Any suggestions how to fix the above ? Regards, Rajiv To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1842397/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1832848] [NEW] Set Project ID for synchronization across servers
Public bug reported: Identifiers Each resource in Keystone has a unique identifier. For the majority of resources, the identifiers are currently generated as UUIDs. In addition, the identifiers are assigned by the system, and are not something an end user can specify when creating the resource. The theory is that this would prevent identifier squatting, where a user creates a resource with a specified ID in order to deny that ID to another user, or hijack the use of the identifier for some other reason. In practice it means that two Keystone deployments will have different identifiers for resources that should be common, such as role, project, or user groups. This identifier skew means that to track something for audit purposes you can only correlate on the resource name. But resource names are modifiable. The limiting fact for using the API to duplicate data from one Keystone system to another is the generation of the identifier. Since a new record always gets a new identifier, and the the value for the identifier can only be generated, the API does not allow matching of records. However, allowing all users to specify the identifiers when creating records would create the potential for "squatting" on the identifier, and also prevent synchronization. Thus, for normal record generation, the identifiers should be generated by the system, and explicit identifier specification should be reserved for the synchronization use case only. With the advent of System scoped roles, we can split the RBAC enforcement on the creation APIs. Normal creation should require a project or domain scoped token. Synchronization should require a system scoped token. ** Affects: keystone 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/1832848 Title: Set Project ID for synchronization across servers Status in OpenStack Identity (keystone): New Bug description: Identifiers Each resource in Keystone has a unique identifier. For the majority of resources, the identifiers are currently generated as UUIDs. In addition, the identifiers are assigned by the system, and are not something an end user can specify when creating the resource. The theory is that this would prevent identifier squatting, where a user creates a resource with a specified ID in order to deny that ID to another user, or hijack the use of the identifier for some other reason. In practice it means that two Keystone deployments will have different identifiers for resources that should be common, such as role, project, or user groups. This identifier skew means that to track something for audit purposes you can only correlate on the resource name. But resource names are modifiable. The limiting fact for using the API to duplicate data from one Keystone system to another is the generation of the identifier. Since a new record always gets a new identifier, and the the value for the identifier can only be generated, the API does not allow matching of records. However, allowing all users to specify the identifiers when creating records would create the potential for "squatting" on the identifier, and also prevent synchronization. Thus, for normal record generation, the identifiers should be generated by the system, and explicit identifier specification should be reserved for the synchronization use case only. With the advent of System scoped roles, we can split the RBAC enforcement on the creation APIs. Normal creation should require a project or domain scoped token. Synchronization should require a system scoped token. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1832848/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1827420] [NEW] Document issues with deep nesting of Quota/limits
Public bug reported: I wrote up the issues with gaming the system that can happen with deep quotas. This has driven what happened with 2 level quota in unified limites. https://adam.younglogic.com/2018/05/tracking-quota/ This should merge in with the documentation to explain why we limit things to 2 levels and figure out how to deal with deeper limits in the future. ** Affects: keystone 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/1827420 Title: Document issues with deep nesting of Quota/limits Status in OpenStack Identity (keystone): New Bug description: I wrote up the issues with gaming the system that can happen with deep quotas. This has driven what happened with 2 level quota in unified limites. https://adam.younglogic.com/2018/05/tracking-quota/ This should merge in with the documentation to explain why we limit things to 2 levels and figure out how to deal with deeper limits in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1827420/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1824239] [NEW] predictable role ids
Public bug reported: Make it possible to know what the ID of a role will be prior to creating it. This allows synchronization between multiple keystone servers ** Affects: keystone Importance: Undecided Assignee: Adam Young (ayoung) 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/bugs/1824239 Title: predictable role ids Status in OpenStack Identity (keystone): In Progress Bug description: Make it possible to know what the ID of a role will be prior to creating it. This allows synchronization between multiple keystone servers To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1824239/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1808059] Re: admin user should have admin role in the Default domain
UNtil recently, this should be in bootstrap. This is the minimal amount of configuration a Keystone server needs: to be able to create a new domain, or create projects on the domain, etc. Now it should be one admin user with a service scoped admin role. From that, all other configuration can flow. ** Summary changed: - admin user should have admin role in the Default domain + admin user should have service scoped admin role ** Changed in: keystone Status: Opinion => 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/1808059 Title: admin user should have service scoped admin role Status in OpenStack Identity (keystone): New Bug description: * Some 3rd party (NFV) require the admin user to have the admin role in the Default domain. * Some deployers automatically add the admin user to the Default domain post deployment but it could probably be better to have keystone-manage bootstrap a domain with --bootstrap-domain-name. * We already assign user to project and create the Default domain in the bootstrapping procedure. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1808059/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1804073] Re: Keystone fails to log policy target data
Added Oslo.policy to the bug report, as this is going to be an issue across all of the projects. Barbican, especially, needs target info, but the same is true for anything that enforces the scope check. ** Also affects: oslo.policy 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/1804073 Title: Keystone fails to log policy target data Status in OpenStack Identity (keystone): New Status in oslo.policy: New Bug description: The Oslo Policy Enforcer requires 3 pieces of run-time information in addition to the policy rules to issue a RBAC decision: 1) the name of the rule to be evaluated (called target in the oslo-policy doc) 2) the auth context (called credentials in the oslo-policy doc) 3) the target data (resource data relevant to the rule) If you are trying to debug policy enforcement or simply validate your policy works as expect one can use the oslopolicy-checker tool. But the oslopolicy-checker tool needs the *exact* same data keystone passes to the policy enforcement engine. The fact the target data needs to be logged but isn't is captured in this comment from Henry Nash in authorize.py # TODO(henry-nash) need to log the target attributes as well https://github.com/openstack/keystone/blob/stable/rocky/keystone/common/authorization.py#L139 But that is not the best location to log, the best place is where oslo.policy is called to evaluate a policy rule, that occurs in Policy.enforce() in keystone/policy/backends/policy.py https://github.com/openstack/keystone/blob/stable/rocky/keystone/policy/backends/rules.py#L29:#L34 Here we can see it logs the rule name (e.g. action) and the auth context (credentials) msg = 'enforce %(action)s: %(credentials)s' but the target data is not logged. Besides the fact the target data is not logged is the fact the logging relies on Python's str() method to convert an object into a string representation. This has two problems, 1) all contained objects must also have __str__() methods that fully log their contents, 2) the formatting is often in Python's "representation" style which only humans and Python can parse. Since both the credential and targets parameters to the enforce method are dicts (with arbitrary complex nesting) and the fact JSON is the data format we use for data exchange and the format used by oslopolicy-checker it makes sense to log the enforcement parameters in JSON format. This way no data is lost (because there wasn't an appropriate formatter for the object) and it makes it easy import the data to another tool (again, without loss of data). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1804073/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1794552] [NEW] Flaskification broke ECP
Public bug reported:
THe Federation itegration (not voting) tests for Python35 are failing.
==
2018-09-26 06:26:21.371093 | primary | Failed 1 tests - output below:
2018-09-26 06:26:21.371172 | primary | ==
2018-09-26 06:26:21.371200 | primary |
2018-09-26 06:26:21.371360 | primary |
keystone_tempest_plugin.tests.scenario.test_federated_authentication.TestSaml2EcpFederatedAuthentication.test_request_scoped_token
2018-09-26 06:26:21.371521 | primary |
--
2018-09-26 06:26:21.371538 | primary |
2018-09-26 06:26:21.371576 | primary | Captured traceback:
2018-09-26 06:26:21.371614 | primary | ~~~
2018-09-26 06:26:21.371675 | primary | b'Traceback (most recent call last):'
2018-09-26 06:26:21.371900 | primary | b' File
"/opt/stack/new/tempest/.tox/tempest/lib/python3.5/site-packages/keystone_tempest_plugin/tests/scenario/test_federated_authentication.py",
line 176, in test_request_scoped_token'
2018-09-26 06:26:21.371979 | primary | b"project_id=projects[0]['id'],
token=token_id)"
2018-09-26 06:26:21.372155 | primary | b' File
"/opt/stack/new/tempest/tempest/lib/services/identity/v3/token_client.py", line
140, in auth'
2018-09-26 06:26:21.372357 | primary | b'resp, body =
self.post(self.auth_url, body=body)'
2018-09-26 06:26:21.372573 | primary | b' File
"/opt/stack/new/tempest/tempest/lib/common/rest_client.py", line 279, in post'
2018-09-26 06:26:21.372724 | primary | b"return self.request('POST',
url, extra_headers, headers, body, chunked)"
2018-09-26 06:26:21.372881 | primary | b' File
"/opt/stack/new/tempest/tempest/lib/services/identity/v3/token_client.py", line
172, in request'
2018-09-26 06:26:21.372961 | primary | b"'Unexpected status code
{0}'.format(resp.status))"
2018-09-26 06:26:21.373034 | primary |
b'tempest.lib.exceptions.IdentityError: Got identity error'
2018-09-26 06:26:21.373088 | primary | b'Details: Unexpected status code
500'
2018-09-26 06:26:21.373108 | primary | b''
Looking in the logs for Keystone show an improper string replacement:
/OS-FEDERATION/identity_providers//protocols
See below
2018-09-26 06:26:16.800826 | primary | b'Body: b\'{"protocol":
{"links": {"self":
"http://149.202.181.254/identity/v3/OS-FEDERATION/identity_providers//protocols/mapped",
"identity_provider": "http://149.202.181.254/identity/v3/testshib"},
"mapping_id": "608508b0cd09476289b2be05bcca98e3", "id": "mapped"}}\\n\''
2018-09-26 06:26:16.801021 | primary | b'2018-09-26 06:26:16,423 30292 INFO
[tempest.lib.common.rest_client] Request
(TestSaml2EcpFederatedAuthentication:test_request_scoped_token): 500 POST
http://149.202.181.254/identity/v3/auth/tokens'
2018-09-26 06:26:16.801187 | primary | b"2018-09-26 06:26:16,424 30292
DEBUG[tempest.lib.common.rest_client] Request - Headers: {'Content-Type':
'application/json', 'Accept': 'application/json'}"
2018-09-26 06:26:16.801241 | primary | b'Body: '
2018-09-26 06:26:16.801530 | primary | b"Response - Headers:
{'connection': 'close', 'content-type': 'application/json', 'server':
'Apache/2.4.18 (Ubuntu)', 'date': 'Wed, 26 Sep 2018 06:26:16 GMT',
'x-openstack-request-id': 'req-2185af52-06fa-41c3-80eb-de3d5e667380',
'content-location': 'http://149.202.181.254/identity/v3/auth/tokens',
'content-length': '143', 'vary': 'X-Auth-Token', 'status': '500'}"
2018-09-26 06:26:16.801855 | primary | b'Body: b\'{"error":
{"message": "An unexpected error prevented the server from fulfilling your
request.", "title": "Internal Server Error", "code": 500}}\''
** Affects: keystone
Importance: Undecided
Assignee: Morgan Fainberg (mdrnstm)
Status: New
** Changed in: keystone
Assignee: (unassigned) => Morgan Fainberg (mdrnstm)
--
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/1794552
Title:
Flaskification broke ECP
Status in OpenStack Identity (keystone):
New
Bug description:
THe Federation itegration (not voting) tests for Python35 are failing.
==
2018-09-26 06:26:21.371093 | primary | Failed 1 tests - output below:
2018-09-26 06:26:21.371172 | primary | ==
2018-09-26 06:26:21.371200 | primary |
2018-09-26 06:26:21.371360 | primary |
keystone_tempest_plugin.tests.scenario.test_federated_authentication.TestSaml2EcpFederatedAuthentication.test_request_scoped_token
2018-09-26 06:26:21.371521 | primary |
--
2018-09-26 06:26:21.371538 | primary |
2018-09-26
[Yahoo-eng-team] [Bug 1794527] [NEW] Allow domain creation with a specific ID
Public bug reported: When keeping two Keystone servers in sync, but avoiding Database replication, it is often necessary to hack the database to update the Domain ID so that entries match. Domain ID is then used for LDAP mapped IDs, and if they don't match, the user IDs are different. It should be possible to add a domain with an explicit ID, so that the two servers can match User IDs. ** Affects: keystone Importance: Wishlist Status: New ** Changed in: keystone Importance: Undecided => Wishlist -- 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/1794527 Title: Allow domain creation with a specific ID Status in OpenStack Identity (keystone): New Bug description: When keeping two Keystone servers in sync, but avoiding Database replication, it is often necessary to hack the database to update the Domain ID so that entries match. Domain ID is then used for LDAP mapped IDs, and if they don't match, the user IDs are different. It should be possible to add a domain with an explicit ID, so that the two servers can match User IDs. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1794527/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1794530] [NEW] Federation IDs hardcode UUIDs instead of configured id_generator
Public bug reported: A Federated user gets an entry in the shadow-users table. This entry has a unique ID. It is generated using a UUID. This mirrors what we do for LDAP, but in the LDAP case, the ID is generated from the domain ID + the local id of the user (an attribute that uniquely ids the user in LDAP). THus, the LDAP code can be changed at config time, but the Federated code can't. It also means that Federated IDs cannot be kept in sync between two keystone servers. ** Affects: keystone Importance: Low Assignee: Adam Young (ayoung) Status: In Progress ** Changed in: keystone Importance: Undecided => Low -- 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/1794530 Title: Federation IDs hardcode UUIDs instead of configured id_generator Status in OpenStack Identity (keystone): In Progress Bug description: A Federated user gets an entry in the shadow-users table. This entry has a unique ID. It is generated using a UUID. This mirrors what we do for LDAP, but in the LDAP case, the ID is generated from the domain ID + the local id of the user (an attribute that uniquely ids the user in LDAP). THus, the LDAP code can be changed at config time, but the Federated code can't. It also means that Federated IDs cannot be kept in sync between two keystone servers. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1794530/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1793756] [NEW] remote user tests disabled
Public bug reported: in keystone/tests/unit/test_v3_auth.py there are two tests that have been commented out because they are unrunnable: test_remote_user_with_realm and test_remote_user_with_default_domain These support the External auth mechanism which should be avaialable to people with the LDAP identity backend enabled . ** Affects: keystone 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/1793756 Title: remote user tests disabled Status in OpenStack Identity (keystone): New Bug description: in keystone/tests/unit/test_v3_auth.py there are two tests that have been commented out because they are unrunnable: test_remote_user_with_realm and test_remote_user_with_default_domain These support the External auth mechanism which should be avaialable to people with the LDAP identity backend enabled . To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1793756/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1790428] Re: Keystone policy.json not matching domain_id
Just to be clear, this has always been the case. THe documentation for the cloud sample stated it needed to be edited. Of course, I tripped over this exact problem. A few times. I once proposed reading policy values from the config file as a work around. But this is not a bug. As Lance put, work is underway to make sure we don't need to do this in the future, but the cloudsample is just that, as sample policy file, and it needs to be edited to be correct. ** 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/1790428 Title: Keystone policy.json not matching domain_id Status in OpenStack Identity (keystone): Invalid Bug description: Environment: Queens installed using Kolla Ansible 6.1.0 on CentOS 7.5 I created a rule in the Keystone policy.json that should match a custom role (domain_admin) and match the domain_id. I tried 4 variations, only the last variation worked, which has the domain_id hard-coded: #"domain_admin_and_matching_domain_id": "role:domain_admin and domain_id:%(target.token.user.domain.id)s", #"domain_admin_and_matching_domain_id": "role:domain_admin and domain_id:%(target.token.user.domain_id)s", #"domain_admin_and_matching_domain_id": "role:domain_admin and domain_id:%(domain_id)s", "domain_admin_and_matching_domain_id": "role:domain_admin and domain_id:e93d848b2a274cb588676e029ae53348", The goal was to use this rule for the project creation permission like this: "identity:create_project": "rule:cloud_admin or rule:domain_admin_and_matching_domain_id", However, I always got an error when creating a project with a test user who belongs to the domain_admin role and the respective domain (e93d848b2a274cb588676e029ae53348): Forbidden: You are not authorized to perform the requested action: identity:create_project. (HTTP 403) until I hard-coded the domain_id in the policy.json file, which led me to believe that the syntax for the variable-driven "domain_admin_and_matching_domain_id" rules is incorrect or something else is wrong. The user has the appropriate role assignment (note that this is a test system, not production, so names and UUIDs can be publicly listed in this ticket): openstack role assignment list --domain e93d848b2a274cb588676e029ae53348 +--+--+---+-+--+---+ | Role | User | Group | Project | Domain | Inherited | +--+--+---+-+--+---+ | 13cf2d56ff594a56a9897787ab07cff5 | ad6038fe42564ba2b8278ceae52f2964 | | | e93d848b2a274cb588676e029ae53348 | False | +--+--+---+-+--+---+ The respective UUIDs are listed here (filtered by hand to only include this role): openstack role list +--+---+ | ID | Name | +--+---+ | 13cf2d56ff594a56a9897787ab07cff5 | domain_admin | +--+---+ openstack user list +--+---+ | ID | Name | +--+---+ | ad6038fe42564ba2b8278ceae52f2964 | TestDomainAdmin | +--+---+ openstack domain list +--+--+-++ | ID | Name | Enabled | Description | +--+--+-++ | e93d848b2a274cb588676e029ae53348 | TestDomain | True| | +--+--+-++ Am I missing something obvious in the policy.json file? Thanks! Eric To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1790428/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1782197] [NEW] Mapping Engine Tester is untested
Public bug reported: Looking at a coverage report for the Keystone CLI shows that the entirety of class MappingEngineTester(BaseApp): Is untested. Since this is production and supported code, this is a risk. ** Affects: keystone 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/1782197 Title: Mapping Engine Tester is untested Status in OpenStack Identity (keystone): New Bug description: Looking at a coverage report for the Keystone CLI shows that the entirety of class MappingEngineTester(BaseApp): Is untested. Since this is production and supported code, this is a risk. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1782197/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1780159] Re: Some inherited projects missing when listing user's projects
** Changed in: keystone
Status: Invalid => 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/1780159
Title:
Some inherited projects missing when listing user's projects
Status in OpenStack Identity (keystone):
New
Bug description:
When a project is added as a child to another project and a user has
an inherited role as well as an explicit role on that parent project,
the child project may not appear when the user lists their projects.
It appears that the order in which the inherited and effective role
assignments are made makes a difference.
What actually happens:
# The parent
$ openstack project show parent --children
+-++
| Field | Value |
+-++
| description ||
| domain_id | default|
| enabled | True |
| id | da2265680b3844eaa241a14ac9ee07f1 |
| is_domain | False |
| name| parent |
| parent_id | default|
| subtree | {'3e5e4084c9984d55935198eed49f7164': None} |
| tags| [] |
+-++
# A first child
$ openstack project show 3e5e4084c9984d55935198eed49f7164
+-+--+
| Field | Value|
+-+--+
| description | |
| domain_id | default |
| enabled | True |
| id | 3e5e4084c9984d55935198eed49f7164 |
| is_domain | False|
| name| child|
| parent_id | da2265680b3844eaa241a14ac9ee07f1 |
| tags| [] |
+-+--+
# Next, we give user mradmin the project_admin role on the parent project
explicitly.
$ openstack role add --project parent --user mradmin project_admin
# We give user mradmin the project_admin role on the parent project's subtree
via inheritance.
$ openstack role add --project parent --user mradmin --inherited
project_admin
# When we list the projects as user mradmin, everything is fine for now.
$ openstack project list
+--++
| ID | Name |
+--++
| 3e5e4084c9984d55935198eed49f7164 | child |
| da2265680b3844eaa241a14ac9ee07f1 | parent |
+--++
* Important note: the first child project exists before we do the role
assignments. The second child project is added after the role
assignments.
# Add a second child project to the parent project:
$ openstack project create --parent parent child2
+-+--+
| Field | Value|
+-+--+
| description | |
| domain_id | default |
| enabled | True |
| id | c781f589110c4d07a96c40b50bc6bd19 |
| is_domain | False|
| name| child2 |
| parent_id | da2265680b3844eaa241a14ac9ee07f1 |
| tags| [] |
+-+--+
# The second child does not appear when we list the projects as user mradmin
$ openstack project list
+--++
| ID | Name |
+--++
| 3e5e4084c9984d55935198eed49f7164 | child |
| da2265680b3844eaa241a14ac9ee07f1 | parent |
+--++
If we repeat the above except we reverse the order when assigning the
project_admin role:
$ openstack role add --project parent --user mradmin --inherited
project_admin
$ openstack role add --project parent --user mradmin project_admin
then we are able to see all projects when we list the projects as user
mradmin:
$ openstack project list
+--++
| ID | Name |
+--++
| 79d5300ac137466a9e2a22931d0a6b52 | child2 |
| e18fa9d21fe94bdcb4965233b65081bd | parent |
|
[Yahoo-eng-team] [Bug 1780159] Re: Some inherited projects missing when listing user's projects
** Changed in: keystone
Status: New => 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/1780159
Title:
Some inherited projects missing when listing user's projects
Status in OpenStack Identity (keystone):
Invalid
Bug description:
When a project is added as a child to another project and a user has
an inherited role as well as an explicit role on that parent project,
the child project may not appear when the user lists their projects.
It appears that the order in which the inherited and effective role
assignments are made makes a difference.
What actually happens:
# The parent
$ openstack project show parent --children
+-++
| Field | Value |
+-++
| description ||
| domain_id | default|
| enabled | True |
| id | da2265680b3844eaa241a14ac9ee07f1 |
| is_domain | False |
| name| parent |
| parent_id | default|
| subtree | {'3e5e4084c9984d55935198eed49f7164': None} |
| tags| [] |
+-++
# A first child
$ openstack project show 3e5e4084c9984d55935198eed49f7164
+-+--+
| Field | Value|
+-+--+
| description | |
| domain_id | default |
| enabled | True |
| id | 3e5e4084c9984d55935198eed49f7164 |
| is_domain | False|
| name| child|
| parent_id | da2265680b3844eaa241a14ac9ee07f1 |
| tags| [] |
+-+--+
# Next, we give user mradmin the project_admin role on the parent project
explicitly.
$ openstack role add --project parent --user mradmin project_admin
# We give user mradmin the project_admin role on the parent project's subtree
via inheritance.
$ openstack role add --project parent --user mradmin --inherited
project_admin
# When we list the projects as user mradmin, everything is fine for now.
$ openstack project list
+--++
| ID | Name |
+--++
| 3e5e4084c9984d55935198eed49f7164 | child |
| da2265680b3844eaa241a14ac9ee07f1 | parent |
+--++
* Important note: the first child project exists before we do the role
assignments. The second child project is added after the role
assignments.
# Add a second child project to the parent project:
$ openstack project create --parent parent child2
+-+--+
| Field | Value|
+-+--+
| description | |
| domain_id | default |
| enabled | True |
| id | c781f589110c4d07a96c40b50bc6bd19 |
| is_domain | False|
| name| child2 |
| parent_id | da2265680b3844eaa241a14ac9ee07f1 |
| tags| [] |
+-+--+
# The second child does not appear when we list the projects as user mradmin
$ openstack project list
+--++
| ID | Name |
+--++
| 3e5e4084c9984d55935198eed49f7164 | child |
| da2265680b3844eaa241a14ac9ee07f1 | parent |
+--++
If we repeat the above except we reverse the order when assigning the
project_admin role:
$ openstack role add --project parent --user mradmin --inherited
project_admin
$ openstack role add --project parent --user mradmin project_admin
then we are able to see all projects when we list the projects as user
mradmin:
$ openstack project list
+--++
| ID | Name |
+--++
| 79d5300ac137466a9e2a22931d0a6b52 | child2 |
| e18fa9d21fe94bdcb4965233b65081bd | parent |
|
[Yahoo-eng-team] [Bug 1643301] Re: bootstrapping keystone failed when LDAP backend is in use
I'm closing this Won't fix because running with the LDAP backend is a
bad approach. Use SQL, with LDAP in a domain specific back end.
** Changed in: keystone
Status: Triaged => Won't Fix
--
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/1643301
Title:
bootstrapping keystone failed when LDAP backend is in use
Status in devstack:
In Progress
Status in OpenStack Identity (keystone):
Won't Fix
Bug description:
"keystone-manage bootstrap" command is coded for SQL backend, it's
should be okay if admin token is always supported by keystone, but we
have a plan to remove the support of admin token since it's expose a
security risk. And the patch to remove the support of write operation
for LDAP backend is on the fly.
Based on the above consideration, we should enable the bootrapping
keystone when using LDAP backend, but it currently not work sometimes,
for example.
# keystone-manage bootstrap --bootstrap-username Dave --bootstrap-password
abc123 --bootstrap-project-name admin --bootstrap-role-name admin
2016-10-27 16:26:29.845 11359 TRACE keystone return
self.result(msgid,all=1,timeout=self.timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 497, in result
2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data,
resp_msgid = self.result2(msgid,all,timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 501, in
result2
2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data,
resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 508, in
result3
2016-10-27 16:26:29.845 11359 TRACE keystone
resp_ctrl_classes=resp_ctrl_classes
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 515, in
result4
2016-10-27 16:26:29.845 11359 TRACE keystone ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in
_ldap_call
2016-10-27 16:26:29.845 11359 TRACE keystone result =
func(*args,**kwargs)
2016-10-27 16:26:29.845 11359 TRACE keystone UNDEFINED_TYPE: {'info':
'enabled: attribute type undefined', 'desc': 'Undefined attribute type'}
To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1643301/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1602081] Re: Use oslo.context's policy dict
Fixed in Keystone by f71a78db86632dccb391782e62da69a4627c7cad https://review.openstack.org/#/c/523650/ ** Changed in: keystone Assignee: (unassigned) => Adam Young (ayoung) ** Changed in: keystone Status: Triaged => Fix Released ** Changed in: keystone Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1602081 Title: Use oslo.context's policy dict Status in Cinder: Fix Released Status in Glance: Fix Released Status in OpenStack Heat: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Committed Status in OpenStack Compute (nova): Fix Released Bug description: This is a cross project goal to standardize the values available to policy writers and to improve the basic oslo.context object. It is part of the follow up work to bug #1577996 and bug #968696. There has been an ongoing problem for how we define the 'admin' role. Because tokens are project scoped having the 'admin' role on any project granted you the 'admin' role on all of OpenStack. As a solution to this keystone defined an is_admin_project field so that keystone defines a single project that your token must be scoped to to perform admin operations. This has been implemented. The next phase of this is to make all the projects understand the X -Is-Admin-Project header from keystonemiddleware and pass it to oslo_policy. However this pattern of keystone changes something and then goes to every project to fix it has been repeated a number of times now and we would like to make it much more automatic. Ongoing work has enhanced the base oslo.context object to include both the load_from_environ and to_policy_values methods. The load_from_environ classmethod takes an environment dict with all the standard auth_token and oslo middleware headers and loads them into their standard place on the context object. The to_policy_values() then creates a standard credentials dictionary with all the information that should be required to enforce policy from the context. The combination of these two methods means in future when authentication information needs to be passed to policy it can be handled entirely by oslo.context and does not require changes in each individual service. Note that in future a similar pattern will hopefully be employed to simplify passing authentication information over RPC to solve the timeout issues. This is a prerequisite for that work. There are a few common problems in services that are required to make this work: 1. Most service context.__init__ functions take and discard **kwargs. This is so if the context.from_dict receives arguments it doesn't know how to handle (possibly because new things have been added to the base to_dict) it ignores them. Unfortunately to make the load_from_environ method work we need to pass parameters to __init__ that are handled by the base class. To make this work we simply have to do a better job of using from_dict. Instead of passing everything to __init__ and ignoring what we don't know we have from_dict extract only the parameters that context knows how to use and call __init__ with those. 2. The parameters passed to the base context.__init__ are old. Typically they are user and tenant where most services expect user_id and project_id. There is ongoing work to improve this in oslo.context but for now we have to ensure that the subclass correctly sets and uses the right variable names. 3. Some services provide additional information to the policy enforcement method. To continue to make this function we will simply override the to_policy_values method in the subclasses. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1602081/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1724645] [NEW] remote_id_attribute config options prevents multiple protocol variations for Federation
Public bug reported: In order to activate a protocol for Federation, you need SOME value for remote_id_attribute. However , this is set once per protocol in the config file, not in the federated data. Thus, if two different SAML implementations both wanted to use different values for remote_id_attribute (DN vs CN for example) they could not. ** Affects: keystone 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/1724645 Title: remote_id_attribute config options prevents multiple protocol variations for Federation Status in OpenStack Identity (keystone): New Bug description: In order to activate a protocol for Federation, you need SOME value for remote_id_attribute. However , this is set once per protocol in the config file, not in the federated data. Thus, if two different SAML implementations both wanted to use different values for remote_id_attribute (DN vs CN for example) they could not. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1724645/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1719141] [NEW] Kick off Ansible Playbook from Keystone Actions
Public bug reported: When a Federated User logs in for the first time, many organizations want to be able to provision resources. This is a specific instance of the general idea that a Keystone token operation should be able to kick off a playbook. PLaybooks can perform both Openstack specific actions such as project create, as well as nont - Openstack issues, such as creating resources in third party systems like LDAP. ** Affects: keystone Importance: Wishlist 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/1719141 Title: Kick off Ansible Playbook from Keystone Actions Status in OpenStack Identity (keystone): New Bug description: When a Federated User logs in for the first time, many organizations want to be able to provision resources. This is a specific instance of the general idea that a Keystone token operation should be able to kick off a playbook. PLaybooks can perform both Openstack specific actions such as project create, as well as nont - Openstack issues, such as creating resources in third party systems like LDAP. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1719141/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1689644] [NEW] Keystone does not report microversion headers
Public bug reported: Keystone is now behind the other projects in reporting the microversions in the microversion header ** Affects: keystone 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/1689644 Title: Keystone does not report microversion headers Status in OpenStack Identity (keystone): New Bug description: Keystone is now behind the other projects in reporting the microversions in the microversion header To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1689644/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1648542] Re: keystone does not retry on deadlock Transactions [500 Error]
CLosing as a duplicate. ** Changed in: keystone Status: New => 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/1648542 Title: keystone does not retry on deadlock Transactions [500 Error] Status in OpenStack Identity (keystone): Invalid Bug description: Description of problem: DBDeadlock: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') The above error is retry-able error, but no evidence for keystone would really did a retry before throwing a 500. 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi [req-c7dba8f5-9269-4c6f-b3e2-9a6c43b6cf0b a8377c6c4d05430d92ac661a2319cc95 c24adc59b2d0490c930d0270a1faecb5 - default default] (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi Traceback (most recent call last): 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 225, in __call__ 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi result = method(req, **params) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_log/versionutils.py", line 174, in wrapped 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi return func_or_cls(*args, **kwargs) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/controllers.py", line 164, in delete_user 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self.identity_api.delete_user(user_id, initiator) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 124, in wrapped 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi __ret_val = __f(*args, **kwargs) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 416, in wrapper 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi return f(self, *args, **kwargs) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 426, in wrapper 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi return f(self, *args, **kwargs) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 990, in delete_user 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi driver.delete_user(entity_id) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/backends/sql.py", line 277, in delete_user 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi session.delete(ref) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__ 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self.gen.next() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", line 875, in _transaction_scope 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi yield resource 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__ 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self.gen.next() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", line 522, in _session 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self._end_session_transaction(self.session) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", line 543, in _end_session_transaction 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi session.commit() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 813, in commit 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self.transaction.commit() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 396, in commit 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi t[1].commit() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1574, in commit 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self._do_commit() 2016-11-12 08:55:10.995 13952
[Yahoo-eng-team] [Bug 1648542] [NEW] keystone does not retry on deadlock Transactions [500 Error]
Public bug reported: Description of problem: DBDeadlock: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') The above error is retry-able error, but no evidence for keystone would really did a retry before throwing a 500. 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi [req-c7dba8f5-9269-4c6f-b3e2-9a6c43b6cf0b a8377c6c4d05430d92ac661a2319cc95 c24adc59b2d0490c930d0270a1faecb5 - default default] (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi Traceback (most recent call last): 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 225, in __call__ 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi result = method(req, **params) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_log/versionutils.py", line 174, in wrapped 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi return func_or_cls(*args, **kwargs) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/controllers.py", line 164, in delete_user 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self.identity_api.delete_user(user_id, initiator) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 124, in wrapped 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi __ret_val = __f(*args, **kwargs) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 416, in wrapper 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi return f(self, *args, **kwargs) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 426, in wrapper 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi return f(self, *args, **kwargs) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 990, in delete_user 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi driver.delete_user(entity_id) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/backends/sql.py", line 277, in delete_user 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi session.delete(ref) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__ 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self.gen.next() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", line 875, in _transaction_scope 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi yield resource 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__ 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self.gen.next() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", line 522, in _session 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self._end_session_transaction(self.session) 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", line 543, in _end_session_transaction 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi session.commit() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 813, in commit 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self.transaction.commit() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 396, in commit 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi t[1].commit() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1574, in commit 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self._do_commit() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1605, in _do_commit 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi self.connection._commit_impl() 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 690, in _commit_impl 2016-11-12 08:55:10.995 13952 ERROR keystone.common.wsgi
[Yahoo-eng-team] [Bug 1647486] [NEW] sample-data makes incorrect credentials call
Public bug reported:
ADMIN_PASSWORD=keystone tools/sample_data.sh
... lots of stuff working fine ...
usage: openstack ec2 credentials create [-h]
[-f {json,shell,table,value,yaml}]
[-c COLUMN] [--max-width ]
[--noindent] [--prefix PREFIX]
[--project ] [--user ]
[--user-domain ]
[--project-domain ]
openstack ec2 credentials create: error: argument --user: expected one argument
** Affects: keystone
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/1647486
Title:
sample-data makes incorrect credentials call
Status in OpenStack Identity (keystone):
New
Bug description:
ADMIN_PASSWORD=keystone tools/sample_data.sh
... lots of stuff working fine ...
usage: openstack ec2 credentials create [-h]
[-f {json,shell,table,value,yaml}]
[-c COLUMN] [--max-width ]
[--noindent] [--prefix PREFIX]
[--project ] [--user ]
[--user-domain ]
[--project-domain ]
openstack ec2 credentials create: error: argument --user: expected one
argument
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1647486/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1646305] [NEW] Federation URL is public, but AUTH_URL is private
Public bug reported: Web SSO will be broken in places where the ssumption that the AUTH_URL that Horizon uses is publically accessible. Conversation with deployer: "keystone is open in haproxy to the public world, but the problem is that horizon forming the SSO url based on the region URL, which is also used for normal authentication and the controller node (keystone, apache, horizon, etc) does not have public network access. ha proxy isn't involved because my web browser follows the redirect request, which has a private IP in it" Issue is https://github.com/openstack/django_openstack_auth/blob/a40234be311eae11ca22497a82a82ab404d09a7c/openstack_auth/utils.py#L181 Which uses auth_url to make the Federation urls. A sample solution would be to add FEDERATION_AUTH_URL=https://public in /etc/openstack_dashboard/local_settings and then in /openstack_auth/utils.py federation_auth_url = getattr(settings, 'FEDERATION_AUTH_URL', auth_url) later (auth_url, idp_id, protocol_id, origin)) becomes (federation_auth_url, idp_id, protocol_id, origin)) ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1646305 Title: Federation URL is public, but AUTH_URL is private Status in OpenStack Dashboard (Horizon): New Bug description: Web SSO will be broken in places where the ssumption that the AUTH_URL that Horizon uses is publically accessible. Conversation with deployer: "keystone is open in haproxy to the public world, but the problem is that horizon forming the SSO url based on the region URL, which is also used for normal authentication and the controller node (keystone, apache, horizon, etc) does not have public network access. ha proxy isn't involved because my web browser follows the redirect request, which has a private IP in it" Issue is https://github.com/openstack/django_openstack_auth/blob/a40234be311eae11ca22497a82a82ab404d09a7c/openstack_auth/utils.py#L181 Which uses auth_url to make the Federation urls. A sample solution would be to add FEDERATION_AUTH_URL=https://public in /etc/openstack_dashboard/local_settings and then in /openstack_auth/utils.py federation_auth_url = getattr(settings, 'FEDERATION_AUTH_URL', auth_url) later (auth_url, idp_id, protocol_id, origin)) becomes (federation_auth_url, idp_id, protocol_id, origin)) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1646305/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1643112] [NEW] Auth plugins should be linked to Federation Protocol
Public bug reported: When setting up Federation, if the protocol needs an new auth plugin, the current mechanism is to add it to the methods list for the [auth] section. However, this has the effect of linking them all together, when the real method should be to link the auth plugin with the protocol. Most of the Federation code is going to require the mapped plugin, but that should not be included in the stack that is then used for password or token based authentication. ** Affects: keystone 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/1643112 Title: Auth plugins should be linked to Federation Protocol Status in OpenStack Identity (keystone): New Bug description: When setting up Federation, if the protocol needs an new auth plugin, the current mechanism is to add it to the methods list for the [auth] section. However, this has the effect of linking them all together, when the real method should be to link the auth plugin with the protocol. Most of the Federation code is going to require the mapped plugin, but that should not be included in the stack that is then used for password or token based authentication. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1643112/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1638603] [NEW] Identity LDAP does not support AD nested groups
Public bug reported: Active Directory has a very specific mechanism to handle nested groups. LDAP queries need to look like this: "(&(objectClass=group)(member=member:1.2.840.113556.1.4.1941:=CN=nwalnut,OU=Users,DC=EXAMPLE,DC=COM))" If a deployment is using nested groups, three queries need to be modified to support it: list users in a group list groups for a user check if a user is in a group Since all three are necessary, a single configuration value ensures that the change is synchronized across all three calls. ** Affects: keystone 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/1638603 Title: Identity LDAP does not support AD nested groups Status in OpenStack Identity (keystone): New Bug description: Active Directory has a very specific mechanism to handle nested groups. LDAP queries need to look like this: "(&(objectClass=group)(member=member:1.2.840.113556.1.4.1941:=CN=nwalnut,OU=Users,DC=EXAMPLE,DC=COM))" If a deployment is using nested groups, three queries need to be modified to support it: list users in a group list groups for a user check if a user is in a group Since all three are necessary, a single configuration value ensures that the change is synchronized across all three calls. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1638603/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped
Reopening the Keystone one as the fix does not work for default policy, which is what most people use. ** Changed in: keystone Status: Fix Released => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/968696 Title: "admin"-ness not properly scoped Status in Cinder: Fix Released Status in Glance: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (keystone): In Progress Status in neutron: Triaged Status in OpenStack Compute (nova): In Progress Status in puppet-keystone: New Bug description: Fact: Keystone's rbac model grants roles to users on specific tenants, and post-keystone redux, there are no longer "global" roles. Problem: Granting a user an "admin" role on ANY tenant grants them unlimited "admin"-ness throughout the system because there is no differentiation between a scoped "admin"-ness and a global "admin"-ness. I don't have a specific solution to advocate, but being an admin on *any* tenant simply *cannot* allow you to administer all of keystone. Steps to reproduce (from Horizon, though you could do this with the CLI, too): 1. User A (existing admin) creates Project B and User B. 2. User A adds User B to Project B with the admin role on Project B. 3. User B logs in and now has unlimited admin rights not only to view things in the dashboard, but to take actions like creating new projects and users, managing existing projects and users, etc. Note: See changes ongoing under https://bugs.launchpad.net/neutron/+bug/1602081 which is required before policy changes can enforce. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1410029] Re: Unnecessary conflict wrapper on assignment driver delete_project() method
Not a bugf, leave the wrapper in for SQL message reporting. ** Changed in: keystone Status: Triaged => 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/1410029 Title: Unnecessary conflict wrapper on assignment driver delete_project() method Status in OpenStack Identity (keystone): Invalid Bug description: The assignment driver method delete_project [1] is protected by the sql.handle_conflicts wrapper - but that wrapper doesn't do anything for the delete case - and we don't use it for any other delete_entity() method other than project. We should remove this wrapper protection. https://github.com/openstack/keystone/blob/f468f32d8f5fa3f01799e5ad3022eb8e065dc32a/keystone/resource/backends/sql.py#L164 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1410029/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1627094] Re: Keystone overwhelms Ceilometer with Identity Events
** Project changed: keystone => ceilometer
--
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/1627094
Title:
Keystone overwhelms Ceilometer with Identity Events
Status in Ceilometer:
Triaged
Bug description:
Description of problem:
When configuring OpenStack from OSP director, keystone is enabled to produce
ceilometer events. These events spam Ceilometer, and any CloudForms instance
managing the Overcloud with "identity.authenticate" events. These events cause
unneeded processing on CloudForms and unneeded data storage in ceilometer as
they have no practical use
Version-Release number of selected component (if applicable):
openstack-keystone-8.0.1-1.el7ost.noarch
python-tripleoclient-0.3.4-6.el7ost.noarch
How reproducible:
100%
Steps to Reproduce:
1. Deploy Overcloud with ceilometer Events
parameter_defaults:
CeilometerStoreEvents: true
2. login to controller
3. sudo openstack-config --get /etc/keystone/keystone.conf DEFAULT
notification driver
messagin
Actual results:
literally nearly 100,000 identity events get created per day. Here is a
sample of about 22 hours from an unused Cloud.
grep /ManageIQ/System/Event/EmsEvent/OPENSTACK evm.log | awk '{ print $10
}' | sort | uniq -c
...
86317 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.authenticate]
473
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.created.role_assignment]
2 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.domain.created]
54 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.endpoint.created]
23
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.OS-TRUST:trust.created]
21
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.OS-TRUST:trust.deleted]
29 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.project.created]
21 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.project.deleted]
2 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.region.created]
473
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.role_assignment.created]
8 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.role.created]
18 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.service.created]
467 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.user.created]
404 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.user.deleted]
...
NOTE: the 86,317 identity.authenticate events produced by the
Overcloud
Expected results:
identity events need not be produced by default for CloudForms to do
its thing. these are essentially SPAM events that use valuable
resources
Additional info:
Suggest setting notification_driver to either log or noop in
/etc/keystone/keystone.conf
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1627094/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1627094] [NEW] Keystone overwhelms Ceilometer with Identity Events
Public bug reported:
Description of problem:
When configuring OpenStack from OSP director, keystone is enabled to produce
ceilometer events. These events spam Ceilometer, and any CloudForms instance
managing the Overcloud with "identity.authenticate" events. These events cause
unneeded processing on CloudForms and unneeded data storage in ceilometer as
they have no practical use
Version-Release number of selected component (if applicable):
openstack-keystone-8.0.1-1.el7ost.noarch
python-tripleoclient-0.3.4-6.el7ost.noarch
How reproducible:
100%
Steps to Reproduce:
1. Deploy Overcloud with ceilometer Events
parameter_defaults:
CeilometerStoreEvents: true
2. login to controller
3. sudo openstack-config --get /etc/keystone/keystone.conf DEFAULT notification
driver
messagin
Actual results:
literally nearly 100,000 identity events get created per day. Here is a sample
of about 22 hours from an unused Cloud.
grep /ManageIQ/System/Event/EmsEvent/OPENSTACK evm.log | awk '{ print $10 }'
| sort | uniq -c
...
86317 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.authenticate]
473
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.created.role_assignment]
2 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.domain.created]
54 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.endpoint.created]
23
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.OS-TRUST:trust.created]
21
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.OS-TRUST:trust.deleted]
29 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.project.created]
21 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.project.deleted]
2 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.region.created]
473
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.role_assignment.created]
8 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.role.created]
18 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.service.created]
467 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.user.created]
404 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.user.deleted]
...
NOTE: the 86,317 identity.authenticate events produced by the Overcloud
Expected results:
identity events need not be produced by default for CloudForms to do its
thing. these are essentially SPAM events that use valuable resources
Additional info:
Suggest setting notification_driver to either log or noop in
/etc/keystone/keystone.conf
** Affects: keystone
Importance: Undecided
Assignee: Adam Young (ayoung)
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/1627094
Title:
Keystone overwhelms Ceilometer with Identity Events
Status in OpenStack Identity (keystone):
New
Bug description:
Description of problem:
When configuring OpenStack from OSP director, keystone is enabled to produce
ceilometer events. These events spam Ceilometer, and any CloudForms instance
managing the Overcloud with "identity.authenticate" events. These events cause
unneeded processing on CloudForms and unneeded data storage in ceilometer as
they have no practical use
Version-Release number of selected component (if applicable):
openstack-keystone-8.0.1-1.el7ost.noarch
python-tripleoclient-0.3.4-6.el7ost.noarch
How reproducible:
100%
Steps to Reproduce:
1. Deploy Overcloud with ceilometer Events
parameter_defaults:
CeilometerStoreEvents: true
2. login to controller
3. sudo openstack-config --get /etc/keystone/keystone.conf DEFAULT
notification driver
messagin
Actual results:
literally nearly 100,000 identity events get created per day. Here is a
sample of about 22 hours from an unused Cloud.
grep /ManageIQ/System/Event/EmsEvent/OPENSTACK evm.log | awk '{ print $10
}' | sort | uniq -c
...
86317 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.authenticate]
473
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.created.role_assignment]
2 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.domain.created]
54 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.endpoint.created]
23
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.OS-TRUST:trust.created]
21
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.OS-TRUST:trust.deleted]
29 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.project.created]
21 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.project.deleted]
2 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.region.created]
473
[/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.role_assignment.created]
8 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.role.created]
18 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.service.created]
467 [/ManageIQ/System/Event/EmsEvent/OPENSTACK/identity.user.created]
[Yahoo-eng-team] [Bug 1381961] Re: Keystone API GET 5000/v3 returns wrong endpoint URL in response body
** Also affects: tripleo
Importance: Undecided
Status: New
** Changed in: tripleo
Status: New => Confirmed
** Changed in: keystone
Status: Confirmed => Fix Released
--
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/1381961
Title:
Keystone API GET 5000/v3 returns wrong endpoint URL in response body
Status in OpenStack Identity (keystone):
Fix Released
Status in tripleo:
Confirmed
Bug description:
When I was invoking a GET request to public endpoint of Keystone, I found
the admin endpoint URL in response body, I assume it should be the public
endpoint URL:
GET https://192.168.101.10:5000/v3
{
"version": {
"status": "stable",
"updated": "2013-03-06T00:00:00Z",
"media-types": [
{
"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"
},
{
"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"
}
],
"id": "v3.0",
"links": [
{
"href": "https://172.20.14.10:35357/v3/;,
"rel": "self"
}
]
}
}
===
Btw, I can get the right URL for public endpoint in the response body of the
versionless API call:
GET https://192.168.101.10:5000
{
"versions": {
"values": [
{
"status": "stable",
"updated": "2013-03-06T00:00:00Z",
"media-types": [
{
"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"
},
{
"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"
}
],
"id": "v3.0",
"links": [
{
"href": "https://192.168.101.10:5000/v3/;,
"rel": "self"
}
]
},
{
"status": "stable",
"updated": "2014-04-17T00:00:00Z",
"media-types": [
{
"base": "application/json",
"type": "application/vnd.openstack.identity-v2.0+json"
},
{
"base": "application/xml",
"type": "application/vnd.openstack.identity-v2.0+xml"
}
],
"id": "v2.0",
"links": [
{
"href": "https://192.168.101.10:5000/v2.0/;,
"rel": "self"
},
{
"href":
"http://docs.openstack.org/api/openstack-identity-service/2.0/content/;,
"type": "text/html",
"rel": "describedby"
},
{
"href":
"http://docs.openstack.org/api/openstack-identity-service/2.0/identity-dev-guide-2.0.pdf;,
"type": "application/pdf",
"rel": "describedby"
}
]
}
]
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1381961/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1619758] [NEW] Credential Encryption breaks deployments without Fernet
Public bug reported: A recent change to encrypt credetials broke RDO/Tripleo deployments: 2016-09-02 17:16:55.074 17619 ERROR keystone.common.fernet_utils [req-31d60075-7e0e-401e-a93f-58297cd5439b f2caffbaf10d4e3da294c6366fe19a36 fd71b607cfa84539bf0440915ea2d94b - default default] Either [fernet_tokens] key_repository does not exist or Keystone does not have sufficient permission to access it: /etc/keystone/credential-keys/ 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi [req-31d60075-7e0e-401e-a93f-58297cd5439b f2caffbaf10d4e3da294c6366fe19a36 fd71b607cfa84539bf0440915ea2d94b - default default] MultiFernet requires at least one Fernet instance 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi Traceback (most recent call last): 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 225, in __call__ 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi result = method(req, **params) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 164, in inner 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi return f(self, request, *args, **kwargs) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/controllers.py", line 69, in create_credential 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi ref = self.credential_api.create_credential(ref['id'], ref) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 124, in wrapped 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi __ret_val = __f(*args, **kwargs) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/core.py", line 106, in create_credential 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi credential_copy = self._encrypt_credential(credential) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/core.py", line 72, in _encrypt_credential 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi json.dumps(credential['blob']) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/providers/fernet/core.py", line 68, in encrypt 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi crypto, keys = get_multi_fernet_keys() 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/providers/fernet/core.py", line 49, in get_multi_fernet_keys 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi crypto = fernet.MultiFernet(fernet_keys) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/cryptography/fernet.py", line 128, in __init__ 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi "MultiFernet requires at least one Fernet instance" 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi ValueError: MultiFernet requires at least one Fernet instance 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi ** Affects: keystone Importance: Undecided Status: New ** Affects: tripleo 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/1619758 Title: Credential Encryption breaks deployments without Fernet Status in OpenStack Identity (keystone): New Status in tripleo: New Bug description: A recent change to encrypt credetials broke RDO/Tripleo deployments: 2016-09-02 17:16:55.074 17619 ERROR keystone.common.fernet_utils [req-31d60075-7e0e-401e-a93f-58297cd5439b f2caffbaf10d4e3da294c6366fe19a36 fd71b607cfa84539bf0440915ea2d94b - default default] Either [fernet_tokens] key_repository does not exist or Keystone does not have sufficient permission to access it: /etc/keystone/credential-keys/ 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi [req-31d60075-7e0e-401e-a93f-58297cd5439b f2caffbaf10d4e3da294c6366fe19a36 fd71b607cfa84539bf0440915ea2d94b - default default] MultiFernet requires at least one Fernet instance 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi Traceback (most recent call last): 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 225, in __call__ 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi result = method(req, **params) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 164, in inner 2016-09-02 17:16:55.074 17619 ERROR
[Yahoo-eng-team] [Bug 1381961] Re: Keystone API GET 5000/v3 returns wrong endpoint URL in response body
Reported in a downstream distribution that should have synced from this
code as still a bug. please reconfirm.
** Changed in: keystone
Status: Fix Released => Confirmed
--
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/1381961
Title:
Keystone API GET 5000/v3 returns wrong endpoint URL in response body
Status in OpenStack Identity (keystone):
Confirmed
Bug description:
When I was invoking a GET request to public endpoint of Keystone, I found
the admin endpoint URL in response body, I assume it should be the public
endpoint URL:
GET https://192.168.101.10:5000/v3
{
"version": {
"status": "stable",
"updated": "2013-03-06T00:00:00Z",
"media-types": [
{
"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"
},
{
"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"
}
],
"id": "v3.0",
"links": [
{
"href": "https://172.20.14.10:35357/v3/;,
"rel": "self"
}
]
}
}
===
Btw, I can get the right URL for public endpoint in the response body of the
versionless API call:
GET https://192.168.101.10:5000
{
"versions": {
"values": [
{
"status": "stable",
"updated": "2013-03-06T00:00:00Z",
"media-types": [
{
"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"
},
{
"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"
}
],
"id": "v3.0",
"links": [
{
"href": "https://192.168.101.10:5000/v3/;,
"rel": "self"
}
]
},
{
"status": "stable",
"updated": "2014-04-17T00:00:00Z",
"media-types": [
{
"base": "application/json",
"type": "application/vnd.openstack.identity-v2.0+json"
},
{
"base": "application/xml",
"type": "application/vnd.openstack.identity-v2.0+xml"
}
],
"id": "v2.0",
"links": [
{
"href": "https://192.168.101.10:5000/v2.0/;,
"rel": "self"
},
{
"href":
"http://docs.openstack.org/api/openstack-identity-service/2.0/content/;,
"type": "text/html",
"rel": "describedby"
},
{
"href":
"http://docs.openstack.org/api/openstack-identity-service/2.0/identity-dev-guide-2.0.pdf;,
"type": "application/pdf",
"rel": "describedby"
}
]
}
]
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1381961/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1321378] Re: keystone user-role-* operations fails when user no longer exists in backend
Closing the Keystone server component again, as I just confirmed the user-list error does not happen in this code base, and thus it is a new bug and a regression. Will open a separate ticket for that. ** Changed in: keystone Status: Confirmed => Fix Released -- 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/1321378 Title: keystone user-role-* operations fails when user no longer exists in backend Status in OpenStack Identity (keystone): Fix Released Status in python-keystoneclient: New Status in python-openstackclient: New Bug description: When using an external user catalog (in our case, AD), if the user is removed on the backend catalog, the user-role-* keystone CLI commands no longer work, because keystone cannot look up the user. The specific situation is a user had been granted roles on some projects, but then that user left the company and was removed from the backend directory. When going back to remove the roles assigned to that user, the keystone commands fail. It may still be possible to do these operations directly through the API, I didn't check that. But ultimately was able to work around it by directly removing the entries in the keystone user_project_metadata table. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1321378/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1321378] Re: keystone user-role-delete operation fails when user no longer exists in backend
Reopening the issue against the Keystone server. The fix was not sufficient, as it was just a workaround, and one that we can't apply via the CLI. The real fix requires avoiding the exception from the identity backend when performing any assignment-backend calls. ** Changed in: keystone Status: Fix Released => Confirmed ** Summary changed: - keystone user-role-delete operation fails when user no longer exists in backend + keystone user-role-* operations fails when user no longer exists in backend -- 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/1321378 Title: keystone user-role-* operations fails when user no longer exists in backend Status in OpenStack Identity (keystone): Confirmed Status in python-keystoneclient: New Status in python-openstackclient: New Bug description: When using an external user catalog (in our case, AD), if the user is removed on the backend catalog, the user-role-* keystone CLI commands no longer work, because keystone cannot look up the user. The specific situation is a user had been granted roles on some projects, but then that user left the company and was removed from the backend directory. When going back to remove the roles assigned to that user, the keystone commands fail. It may still be possible to do these operations directly through the API, I didn't check that. But ultimately was able to work around it by directly removing the entries in the keystone user_project_metadata table. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1321378/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1321378] Re: keystone user-role-delete operation fails when user no longer exists in backend
So...this is a continuing Saga. The fix that went in for Keystone only allows the V3 AP call to continue. However, there is currently no way to call that API except for CURL. Something like: curl -X DELETE -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" $OS_AUTH_URL/projects/e9d504e8524e4c8d9876d179420dab89/users/tuser/roles/95a2366f8b514d43a5584342aefe448e Will work, but there is no way to invoke that from python-keystoneclient or python-openwstackclient as both will attempt to list the users and do a lookup. We probably need a --userid option that indicates that the passed in value is a userid, and do not attempt to look it up. ** Also affects: python-openstackclient Importance: Undecided Status: New ** Also affects: python-keystoneclient 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/1321378 Title: keystone user-role-delete operation fails when user no longer exists in backend Status in OpenStack Identity (keystone): Fix Released Status in python-keystoneclient: New Status in python-openstackclient: New Bug description: When using an external user catalog (in our case, AD), if the user is removed on the backend catalog, the user-role-* keystone CLI commands no longer work, because keystone cannot look up the user. The specific situation is a user had been granted roles on some projects, but then that user left the company and was removed from the backend directory. When going back to remove the roles assigned to that user, the keystone commands fail. It may still be possible to do these operations directly through the API, I didn't check that. But ultimately was able to work around it by directly removing the entries in the keystone user_project_metadata table. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1321378/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1588190] Re: policy.v3cloudsample.json broken in mitaka
I think this is a Horizon bug, not Keystone. The stack trace is all
Horizon code.
I suspect it is a conflict between domain and project scoped token code
in Horizon
** Also affects: horizon
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/1588190
Title:
policy.v3cloudsample.json broken in mitaka
Status in OpenStack Dashboard (Horizon):
New
Status in OpenStack Identity (keystone):
Triaged
Bug description:
We have a multi-domain configuration in our private cloud that I've
had to revert to using the Liberty policy.v3cloudsample.json file
instead of Mitaka or master.
Horizon is generating the following trace when a domain admin is
trying to look at projects/users:
[pid: 22842|app: 0|req: 5/17] 10.38.202.12 () {46 vars in 907 bytes} [Thu Jun
2 07:17:24 2016] GET / => generated 0 bytes in 5 msecs (HTTP/1.1 302) 5
headers in 198 bytes (1 switches on core 1)
Internal Server Error: /identity/
Traceback (most recent call last):
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/django/core/handlers/base.py",
line 132, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/horizon/decorators.py",
line 36, in dec
return view_func(request, *args, **kwargs)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/horizon/decorators.py",
line 52, in dec
return view_func(request, *args, **kwargs)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/horizon/decorators.py",
line 36, in dec
return view_func(request, *args, **kwargs)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/django/views/generic/base.py",
line 71, in view
return self.dispatch(request, *args, **kwargs)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/django/views/generic/base.py",
line 89, in dispatch
return handler(request, *args, **kwargs)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/horizon/tables/views.py",
line 159, in get
handled = self.construct_tables()
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/horizon/tables/views.py",
line 150, in construct_tables
handled = self.handle_table(table)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/horizon/tables/views.py",
line 121, in handle_table
data = self._get_data_dict()
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/horizon/tables/views.py",
line 187, in _get_data_dict
self._data = {self.table_class._meta.name: self.get_data()}
File
"/opt/mhos/openstack/horizon/openstack_dashboard/dashboards/identity/projects/views.py",
line 84, in get_data
self.request):
File "/opt/mhos/openstack/horizon/openstack_dashboard/policy.py", line 24,
in check
return policy_check(actions, request, target)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/openstack_auth/policy.py",
line 155, in check
enforcer[scope], action, target, domain_credentials)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/openstack_auth/policy.py",
line 169, in _check_credentials
if not enforcer_scope.enforce(action, target, credentials):
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/oslo_policy/policy.py",
line 578, in enforce
result = self.rules[rule](target, creds, self)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/oslo_policy/_checks.py",
line 160, in __call__
if rule(target, cred, enforcer):
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/oslo_policy/_checks.py",
line 204, in __call__
return enforcer.rules[self.match](target, creds, enforcer)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/oslo_policy/_checks.py",
line 125, in __call__
if not rule(target, cred, enforcer):
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/oslo_policy/_checks.py",
line 160, in __call__
if rule(target, cred, enforcer):
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/oslo_policy/_checks.py",
line 311, in __call__
return self._find_in_dict(creds, path_segments, match)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/oslo_policy/_checks.py",
line 292, in _find_in_dict
return self._find_in_dict(test_value, path_segments, match)
File
"/opt/mhos/openstack/horizon/local/lib/python2.7/site-packages/oslo_policy/_checks.py",
line 283, in _find_in_dict
test_value = test_value[key]
TypeError: 'Token' object has no attribute '__getitem__'
[pid: 22837|app: 0|req: 5/18]
[Yahoo-eng-team] [Bug 1571001] [NEW] Document Multi ldap support
Public bug reported: "When defining the URL for connecting to the LDAP server in the Keystone configuration, looking for a way to specify multiple LDAP servers for redundancy. For example if an AD domain controller were not available, Keystone would try an alternate domain controller." This is suopported, but config comment does not indicatei t. Needs an update. ** Affects: keystone 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/1571001 Title: Document Multi ldap support Status in OpenStack Identity (keystone): New Bug description: "When defining the URL for connecting to the LDAP server in the Keystone configuration, looking for a way to specify multiple LDAP servers for redundancy. For example if an AD domain controller were not available, Keystone would try an alternate domain controller." This is suopported, but config comment does not indicatei t. Needs an update. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1571001/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1568674] [NEW] Revocation events catching too many tokens
Public bug reported: We've seen an effect where setting the dfefault token handler to Fenet, and depending on Revocation events breaks several tests. These tests are supposed to track that a tokne comes back as invalid. However, what actually happens is the admin users token is invalid, returning a 401 instead of a 404. Putting a 1 second delay between, for example, the delete role assignment event and the token validation causese the validation to properly return the 404. It looks like the revocation tree is somehow matching the admin token in its check. ** Affects: keystone 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/1568674 Title: Revocation events catching too many tokens Status in OpenStack Identity (keystone): New Bug description: We've seen an effect where setting the dfefault token handler to Fenet, and depending on Revocation events breaks several tests. These tests are supposed to track that a tokne comes back as invalid. However, what actually happens is the admin users token is invalid, returning a 401 instead of a 404. Putting a 1 second delay between, for example, the delete role assignment event and the token validation causese the validation to properly return the 404. It looks like the revocation tree is somehow matching the admin token in its check. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1568674/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1567900] Re: Keystone API has no method to cleanup revocation tree
Nope. Not going to expose this just for testing. Use direct database access if you want. ** Changed in: keystone Status: New => 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/1567900 Title: Keystone API has no method to cleanup revocation tree Status in OpenStack Identity (keystone): Invalid Bug description: This request comes from new Rally test case implemented so far but not delivered yet. Test case scenario: Context: 1. Create tenants 2. Create users 3. Assign all users to all projects (i.e. create role for all user/tenant pairs) 4. Generate tokens 5. Revoke all users from tenants (i. e. remove roles) Iterations: Validate token The idea of this test case is to measure validate token operation API call when revocation tree is big. But this test has side effect on all other tests that will validate token (after this test case executed). So it should be possible to cleanup revocation tree somehow. The proposal is to implement new API method to do that. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1567900/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1567446] [NEW] Utilizing Role Base Access Control for managing Multi-tenancy
Public bug reported: After creating a new project and allocating some amount of resources, we should be able to create a hierarchy of users like Project Manager (PM) having complete view of the project usage, then PM should be able to allocate resources to different sub-teams (like Dev, QA, Prod, etc), each sub-team leads having access to their allocated resources and able to manage the resources at their level with approval from the PM. All the users will be AD authenticated ones. ** Affects: keystone 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/1567446 Title: Utilizing Role Base Access Control for managing Multi-tenancy Status in OpenStack Identity (keystone): New Bug description: After creating a new project and allocating some amount of resources, we should be able to create a hierarchy of users like Project Manager (PM) having complete view of the project usage, then PM should be able to allocate resources to different sub-teams (like Dev, QA, Prod, etc), each sub-team leads having access to their allocated resources and able to manage the resources at their level with approval from the PM. All the users will be AD authenticated ones. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1567446/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1562965] Re: liberty -> mitaka db migrate fails on postgresql 091 migration
According to conversation in #openstack-keystone, reporter was running this by hand using ipython. The migrations are not designed to run multiple tiumes, and this error was not somthing we would see using the proper migrate mechanism. ** Changed in: keystone Status: New => 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/1562965 Title: liberty -> mitaka db migrate fails on postgresql 091 migration Status in OpenStack Identity (keystone): Invalid Bug description: looks like this row doesn't exist https://github.com/openstack/keystone/blob/9.0.0.0rc1/keystone/common/sql/migrate_repo/versions/091_migrate_data_to_local_user_and_password_tables.py#L51 NoSuchColumnError: "Could not locate column in row for column 'user_password'" To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1562965/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1555137] [NEW] Transition from UUID/PKI to Fernet without dumping all tokens
Public bug reported: To minimize downtime, the conversion from persisted to ephemeral tokens should happen in two steps. The first migrates tokens over to the Fernet format, but will fall back to persisted store if the requested token is not in Fernet format. The second removes persistence. ** Affects: keystone 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/1555137 Title: Transition from UUID/PKI to Fernet without dumping all tokens Status in OpenStack Identity (keystone): New Bug description: To minimize downtime, the conversion from persisted to ephemeral tokens should happen in two steps. The first migrates tokens over to the Fernet format, but will fall back to persisted store if the requested token is not in Fernet format. The second removes persistence. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1555137/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1546834] [NEW] The deletion of an LDAP domain in keystone when write enabled should not clear the LDAP database
Public bug reported: Description of problem: Testing multi domain support in RHOS. The deletion of this domain when write enabled cleared the LDAP database entirely. Thankfully this was done in a lab, because LDAP was a total loss. Version-Release number of selected component (if applicable): # rpm -qa | grep packstack openstack-packstack-puppet-2015.1-0.14.dev1589.g1d6372f.el7ost.noarch openstack-packstack-2015.1-0.14.dev1589.g1d6372f.el7ost.noarch # rpm -qa | grep keystone python-keystoneclient-1.3.0-2.el7ost.noarch python-keystone-2015.1.2-2.el7ost.noarch openstack-keystone-2015.1.2-2.el7ost.noarch python-keystonemiddleware-1.5.1-1.el7ost.noarch How reproducible: Assuming always? I was only able to do this once. Steps to Reproduce: 1. Enable multi domain support in keystone, ensure the following is in /etc/keystone.conf [identity] domain_specific_drivers_enabled = true domain_config_dir = /etc/keystone/domains #default_domain_id = 7d9bed61b1564f2289296a4e9241482d 2. Then add an LDAP domain and ensure that writes are permitted. vim /etc/keystone/domains/keystone.laboratory.conf [ldap] url=ldap://auth.lab.runlevelone.lan user=uid=keystone,cn=users,cn=accounts,dc=lab,dc=runlevelone,dc=lan password=xxx suffix=ccn=accounts,dc=lab,dc=runlevelone,dc=lan user_tree_dn=cn=users,cn=accounts,dc=lab,dc=runlevelone,dc=lan user_objectclass=person user_id_attribute=uid user_name_attribute=uid user_mail_attribute=mail user_allow_create=true user_allow_update=true user_allow_delete=true group_tree_dn=cn=groups,cn=accounts,dc=lab,dc=runlevelone,dc=lan group_objectclass=groupOfNames group_id_attribute=cn group_name_attribute=cn group_member_attribute=member group_desc_attribute=description group_allow_create=true group_allow_update=true group_allow_delete=true user_enabled_attribute=nsAccountLock user_enabled_default=false user_enabled_invert=true [identity] driver = keystone.identity.backends.ldap.Identity 3. Remove the domain, using 'openstack domain delete #domain_id' Actual results: Clears LDAP database, cn=users/groups,cn=accounts,dc=lab,dc=runlevelone,dc=lan was completely empty Expected results: Does not delete users on removal or prompt "THIS WILL DELETE ALL USERS, DO YOU WANT TO PROCEED" ** Affects: keystone 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/1546834 Title: The deletion of an LDAP domain in keystone when write enabled should not clear the LDAP database Status in OpenStack Identity (keystone): New Bug description: Description of problem: Testing multi domain support in RHOS. The deletion of this domain when write enabled cleared the LDAP database entirely. Thankfully this was done in a lab, because LDAP was a total loss. Version-Release number of selected component (if applicable): # rpm -qa | grep packstack openstack-packstack-puppet-2015.1-0.14.dev1589.g1d6372f.el7ost.noarch openstack-packstack-2015.1-0.14.dev1589.g1d6372f.el7ost.noarch # rpm -qa | grep keystone python-keystoneclient-1.3.0-2.el7ost.noarch python-keystone-2015.1.2-2.el7ost.noarch openstack-keystone-2015.1.2-2.el7ost.noarch python-keystonemiddleware-1.5.1-1.el7ost.noarch How reproducible: Assuming always? I was only able to do this once. Steps to Reproduce: 1. Enable multi domain support in keystone, ensure the following is in /etc/keystone.conf [identity] domain_specific_drivers_enabled = true domain_config_dir = /etc/keystone/domains #default_domain_id = 7d9bed61b1564f2289296a4e9241482d 2. Then add an LDAP domain and ensure that writes are permitted. vim /etc/keystone/domains/keystone.laboratory.conf [ldap] url=ldap://auth.lab.runlevelone.lan user=uid=keystone,cn=users,cn=accounts,dc=lab,dc=runlevelone,dc=lan password=xxx suffix=ccn=accounts,dc=lab,dc=runlevelone,dc=lan user_tree_dn=cn=users,cn=accounts,dc=lab,dc=runlevelone,dc=lan user_objectclass=person user_id_attribute=uid user_name_attribute=uid user_mail_attribute=mail user_allow_create=true user_allow_update=true user_allow_delete=true group_tree_dn=cn=groups,cn=accounts,dc=lab,dc=runlevelone,dc=lan group_objectclass=groupOfNames group_id_attribute=cn group_name_attribute=cn group_member_attribute=member group_desc_attribute=description group_allow_create=true group_allow_update=true group_allow_delete=true user_enabled_attribute=nsAccountLock user_enabled_default=false user_enabled_invert=true [identity] driver = keystone.identity.backends.ldap.Identity 3. Remove the domain, using 'openstack domain delete #domain_id' Actual results: Clears LDAP database, cn=users/groups,cn=accounts,dc=lab,dc=runlevelone,dc=lan was completely empty Expected results: Does not delete users on removal or prompt "THIS WILL DELETE ALL USERS,
[Yahoo-eng-team] [Bug 1546562] [NEW] deleting role with implied role fails
Public bug reported:
Create two roles. Make one imply the other (need curl for now)
$ openstack role delete identity_policy_manager
ERROR: openstack An unexpected error prevented the server from fulfilling your
request. (HTTP 500) (Request-ID: req-a2b89f42-ad24-4985-a599-33cc182d8f80)
Looking in the log
Feb 17 14:05:44 ayoung541 admin: 2016-02-17 14:05:44.042 31 ERROR
keystone.common.wsgi [req-a2b89f42-ad24-4985-a599-33cc182d8f80
6259462f07a940f19b1ad8d36ee42612 b0fa955539c442cc838067a55605102d -
default default] (pymysql.err.IntegrityError) (1451, u'Cannot delete or
update a parent row: a foreign key constraint fails
(`keystone`.`implied_role`, CONSTRAINT `implied_role_prior_role_id_fkey`
FOREIGN KEY (`prior_role_id`) REFERENCES `role` (`id`))') [SQL: u'DELETE
FROM role WHERE role.id = %(id)s'] [parameters: {'id':
u'142340f53b624665a86641cf13135615'}]
This is supposed to be a cascading delete.
** Affects: keystone
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/1546562
Title:
deleting role with implied role fails
Status in OpenStack Identity (keystone):
New
Bug description:
Create two roles. Make one imply the other (need curl for now)
$ openstack role delete identity_policy_manager
ERROR: openstack An unexpected error prevented the server from fulfilling
your request. (HTTP 500) (Request-ID: req-a2b89f42-ad24-4985-a599-33cc182d8f80)
Looking in the log
Feb 17 14:05:44 ayoung541 admin: 2016-02-17 14:05:44.042 31 ERROR
keystone.common.wsgi [req-a2b89f42-ad24-4985-a599-33cc182d8f80
6259462f07a940f19b1ad8d36ee42612 b0fa955539c442cc838067a55605102d -
default default] (pymysql.err.IntegrityError) (1451, u'Cannot delete
or update a parent row: a foreign key constraint fails
(`keystone`.`implied_role`, CONSTRAINT
`implied_role_prior_role_id_fkey` FOREIGN KEY (`prior_role_id`)
REFERENCES `role` (`id`))') [SQL: u'DELETE FROM role WHERE role.id =
%(id)s'] [parameters: {'id': u'142340f53b624665a86641cf13135615'}]
This is supposed to be a cascading delete.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1546562/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1546039] Re: If one trustor role is removed, the trust cannot be used
Its a feature. A trust is assumed to be the smallest chunk of delegated roles possible to perform an action. If a user does not have all those roles, the trustor should be informed immediately that the trust is no longer viable. ** 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/1546039 Title: If one trustor role is removed, the trust cannot be used Status in OpenStack Identity (keystone): Invalid Bug description: If a trust is created with a list of roles, when the trust is used by the trustee to obtain a token, we first make sure that the trustor still has all the delegated roles. However, the way the code is written, if any have been removed, we immediately fail the token creation, rather than, instead, grant the token with the remaining roles. The current exception comment suggests that this was not our intention. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1546039/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1542486] Re: nova-compute stack traces with BadRequest: Specifying 'tenant_id' other than authenticated tenant in request requires admin privileges
Adding Nova to the bug report because it absolutely should not require a specific version of the Keystone API to make things work. I suspect that there is a workaround here, but the Keystone API and auth plugins are designed to be versionless. This is a step backwards, and should be treated as a stopgap solution only. ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1542486 Title: nova-compute stack traces with BadRequest: Specifying 'tenant_id' other than authenticated tenant in request requires admin privileges Status in OpenStack Compute (nova): New Status in puppet-nova: New Bug description: The puppet-openstack-integration tests (rebased on https://review.openstack.org/#/c/276773/ ) currently fail on the latest version of RDO Mitaka (delorean current) due to what seems to be a problem with the neutron configuration. Everything installs fine but tempest fails: http://logs.openstack.org/92/276492/6/check/gate-puppet-openstack-integration-scenario001-tempest-dsvm-centos7/78b9c32/console.html#_2016-02-05_20_26_35_569 And there are stack traces in nova-compute.log: http://logs.openstack.org/92/276492/6/check/gate-puppet-openstack-integration-scenario001-tempest-dsvm-centos7/78b9c32/logs/nova/nova-compute.txt.gz#_2016-02-05_20_22_16_151 I talked with #openstack-nova and they pointed out a difference between what devstack yields as a [neutron] configuration versus what puppet-nova configures: # puppet-nova via puppet-openstack-integration [neutron] service_metadata_proxy=True metadata_proxy_shared_secret =a_big_secret url=http://127.0.0.1:9696 region_name=RegionOne ovs_bridge=br-int extension_sync_interval=600 auth_url=http://127.0.0.1:35357 password=a_big_secret tenant_name=services timeout=30 username=neutron auth_plugin=password default_tenant_id=default # Well, it worked in devstack™ [neutron] service_metadata_proxy = True url = http://127.0.0.1:9696 region_name = RegionOne auth_url = http://127.0.0.1:35357/v3 password = secretservice auth_strategy = keystone project_domain_name = Default project_name = service user_domain_name = Default username = neutron auth_plugin = v3password To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1542486/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1543318] [NEW] Token for trust does not expand implied roles
Public bug reported:
def test_trusts_from_implied_role(self):
self._create_three_roles()
self._create_implied_role(self.role_list[0], self.role_list[1])
self._create_implied_role(self.role_list[1], self.role_list[2])
self._assign_top_role_to_user_on_project(self.user, self.project)
# Create a trustee and assign the prior role to her
trustee = unit.create_user(self.identity_api, domain_id=self.domain_id)
ref = unit.new_trust_ref(
trustor_user_id=self.user['id'],
trustee_user_id=trustee['id'],
project_id=self.project['id'],
role_ids=[self.role_list[0]['id']])
r = self.post('/OS-TRUST/trusts', body={'trust': ref})
trust = r.result['trust']
# Only the role that was specified is in the trust, NOT implies roles
self.assertEqual(self.role_list[0]['id'], trust['roles'][0]['id'])
self.assertThat(trust['roles'], matchers.HasLength(1))
# Authenticate as the trustee
auth_data = self.build_authentication_request(
user_id=trustee['id'],
password=trustee['password'],
trust_id=trust['id'])
r = self.v3_create_token(auth_data)
token = r.result['token']
# This fails
self.assertThat(token['roles'], matchers.HasLength(3))
** Affects: keystone
Importance: Undecided
Assignee: Adam Young (ayoung)
Status: New
** Changed in: keystone
Assignee: (unassigned) => Adam Young (ayoung)
--
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/1543318
Title:
Token for trust does not expand implied roles
Status in OpenStack Identity (keystone):
New
Bug description:
def test_trusts_from_implied_role(self):
self._create_three_roles()
self._create_implied_role(self.role_list[0], self.role_list[1])
self._create_implied_role(self.role_list[1], self.role_list[2])
self._assign_top_role_to_user_on_project(self.user, self.project)
# Create a trustee and assign the prior role to her
trustee = unit.create_user(self.identity_api,
domain_id=self.domain_id)
ref = unit.new_trust_ref(
trustor_user_id=self.user['id'],
trustee_user_id=trustee['id'],
project_id=self.project['id'],
role_ids=[self.role_list[0]['id']])
r = self.post('/OS-TRUST/trusts', body={'trust': ref})
trust = r.result['trust']
# Only the role that was specified is in the trust, NOT implies roles
self.assertEqual(self.role_list[0]['id'], trust['roles'][0]['id'])
self.assertThat(trust['roles'], matchers.HasLength(1))
# Authenticate as the trustee
auth_data = self.build_authentication_request(
user_id=trustee['id'],
password=trustee['password'],
trust_id=trust['id'])
r = self.v3_create_token(auth_data)
token = r.result['token']
# This fails
self.assertThat(token['roles'], matchers.HasLength(3))
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1543318/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1536321] [NEW] cyclic dependencies in implied roles
Public bug reported: Today it is possible to define an implied role structure that is not a DAG. This will crash the Keystone server if a token iis requested that will pull in any of those roles. While it might be impractical to prevent cycles in the creation, it is very possible to prevent the expansion from crashing the server. ** Affects: keystone 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/1536321 Title: cyclic dependencies in implied roles Status in OpenStack Identity (keystone): New Bug description: Today it is possible to define an implied role structure that is not a DAG. This will crash the Keystone server if a token iis requested that will pull in any of those roles. While it might be impractical to prevent cycles in the creation, it is very possible to prevent the expansion from crashing the server. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1536321/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1534834] [NEW] Policy check forces impersonation for redelgation of trust
Public bug reported: When redelegating a trust, the API specifies that the trustor_id is the original trustor_id. However, the policy check for create_trust enforces that user_id = trust.trustor_user_id. Effectily limiting the redelgation ofr trusts to trusts which provide impersonation. ** Affects: keystone 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/1534834 Title: Policy check forces impersonation for redelgation of trust Status in OpenStack Identity (keystone): New Bug description: When redelegating a trust, the API specifies that the trustor_id is the original trustor_id. However, the policy check for create_trust enforces that user_id = trust.trustor_user_id. Effectily limiting the redelgation ofr trusts to trusts which provide impersonation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1534834/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1474284] Re: Adding users from different domain to a group
Works as designed and specified. The Wiki is wrong. Would not modify
away from the existing behavior, either.
** Changed in: keystone
Status: New => 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/1474284
Title:
Adding users from different domain to a group
Status in OpenStack Identity (keystone):
Invalid
Bug description:
I have created two domains. And I have created users in both the
domains. I created a group in first domain, and I tried adding those
users from other domains to this group, it added successfully.
But according to this page https://wiki.openstack.org/wiki/Domains, it should
not allow.
Here are the steps to reproduce this :-
created new domain Domain9
curl -i -k -X POST https://url/v3/domains -H "Content-Type: application/json"
-H "X-Auth-Token: $token" -d @domain.json
HTTP/1.1 201 Created
Date: Fri, 10 Jul 2015 09:48:15 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 214
Content-Type: application/json
{"domain": {"links": {"self":
"https://url/v3/domains/dc1d36c037ac4e47b3b21424f1a13273"}, "enabled":
true, "description": "Description.", "name": "Domain9", "id":
"dc1d36c037ac4e47b3b21424f1a13273"}}
created user fd22 in domain Domain9
curl -i -k -X POST https://url/v3/users -H "Content-Type: application/json"
-H "X-Auth-Token: $token" -d @user.json
HTTP/1.1 201 Created
Date: Fri, 10 Jul 2015 09:49:27 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 269
Content-Type: application/json
{"user": {"links": {"self":
"https://url/v3/users/533979e9b80645799028c51ccec55cce"},
"description": "Sample keystone test user", "name": "fd22", "enabled":
true, "id": "533979e9b80645799028c51ccec55cce", "domain_id":
"dc1d36c037ac4e47b3b21424f1a13273"}}
created user fd23 in default domain
vi user.json
provo-sand:~/bajarang # curl -i -k -X POST https://url/v3/users -H
"Content-Type: application/json" -H "X-Auth-Token: $token" -d @user.json
HTTP/1.1 201 Created
Date: Fri, 10 Jul 2015 09:50:56 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 244
Content-Type: application/json
{"user": {"links": {"self":
"https://url/v3/users/8a43e5f3facb4fc2985a18a40de2046e"},
"description": "Sample keystone test user", "name": "fd23", "enabled":
true, "id": "8a43e5f3facb4fc2985a18a40de2046e", "domain_id":
"default"}}
created group DomainGroup10 in default domain
curl -i -k -X POST https://url/v3/groups -H "Content-Type: application/json"
-H "X-Auth-Token: $token" -d @newgroup.json
HTTP/1.1 201 Created
Date: Fri, 10 Jul 2015 09:52:49 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 225
Content-Type: application/json
{"group": {"domain_id": "default", "description": "Description.",
"id": "0b72f1dd6f514adb989a752b9a72e005", "links": {"self":
"url/v3/groups/0b72f1dd6f514adb989a752b9a72e005"}, "name":
"DomainGroup10"}}
Added user 'fd22' from Domain9 to DomainGroup10
curl -i -k -X PUT
https://url/v3/groups/0b72f1dd6f514adb989a752b9a72e005/users/533979e9b80645799028c51ccec55cce
-H "Content-Type: application/json" -H "X-Auth-Token: $token"
HTTP/1.1 204 No Content
Date: Fri, 10 Jul 2015 09:53:17 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 0
Added user 'fd23' from Default to DomainGroup10
curl -i -k -X PUT
https:/url/v3/groups/0b72f1dd6f514adb989a752b9a72e005/users/8a43e5f3facb4fc2985a18a40de2046e
-H "Content-Type: application/json" -H "X-Auth-Token: $token"
HTTP/1.1 204 No Content
Date: Fri, 10 Jul 2015 09:54:20 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 0
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1474284/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1515825] Re: Horizon allows login without credential when configured to use WebSSO
Needs 3 things: 1. Feature in Keystone to track the WebSSO logout URL comparable to the login URL 2. A way to communicate this to Horizon 3. A tie in to Horizon to call the URL in order to logout. Since Keystone manages websso login, it should do the logout directly as well. ** Changed in: keystone Status: New => Confirmed ** Also affects: horizon 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/1515825 Title: Horizon allows login without credential when configured to use WebSSO Status in OpenStack Dashboard (Horizon): New Status in OpenStack Identity (keystone): Confirmed Status in OpenStack Security Advisory: Won't Fix Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. Steps to reproduce 1) Configure openid connect to use gmail 2) Configure horizon to use websso 3) Login via horizon using openid as IDP 4) Gmail login screen will appear, you enter credentials and then you will be logged in 4) Do some thing 5) Logout of horizion -- Do one more login 6) Login via horizon using open id as IDP (same as step 3) 7) Gmail login screen doesn't appear and horizon logs in directly ( step 4) doesn't happen Basically when you logout of horizon, the session you had with GMAIL is not invalidated. So after a person has logged out, another person can login without entering credentials This is true for AFDS too. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1515825/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1242620] Re: "Unable to add token to revocation list" warning happened when revoking token in memcache
Moving to Fernet tokens. Revocations will be handled by revocation events, not revocation list. Memcache as a storage mechanism for PKI tokens was deeply flawed, as dropping tokens from Memcache effectively unrevoked them. ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1242620 Title: "Unable to add token to revocation list" warning happened when revoking token in memcache Status in OpenStack Identity (keystone): Won't Fix Bug description: Memcache backend is used to store the token. When revoking a token, such error reported. "Unable to add token to revocation list" As a result, the revoked token could not be added to revocation-list in memcache although the token was actually revoked. I found this warning always happen when the size of value of the revocation-list key in memcache is about 512K. Expected result: No warning exception should be raised when revoking token. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1242620/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1240163] Re: Can't store a PKI token with a large catalog
Due to a security issue with PKI tokens, we are going to stop supporting PKI and we will move people on to Fernet as a replacement. Thus, no new features will be implemented for PKI tokens ** Changed in: keystone Importance: High => Wishlist ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1240163 Title: Can't store a PKI token with a large catalog Status in OpenStack Identity (keystone): Won't Fix Status in python-keystoneclient: In Progress Bug description: It seems that when you have a sufficiently large catalog, hashing of the v3 token ID fails, so the token cannot be stored to the DB: Basically when the catalog gets sufficiently large, the assumption here about impractically large tokens proves bad: https://github.com/openstack/keystone/blob/master/keystone/common/cms.py#L108 So token[:3] != PKI_ANS1_PREFIX, which means we don't hash the ID and just return the unhashed token ID, in my case I'm seeingtoken[:3] == MIJ, not MII which is assumed to be prefix the token. https://github.com/openstack/keystone/blob/master/keystone/common/cms.py#L174 This results in an error like this, and a failure to store the token, even though it was created OK. 2013-10-15 18:24:45.671 29796 WARNING keystone.common.wsgi [-] String length exceeded.The length of string '' exceeded the limit of column id(CHAR(64)). From: https://github.com/openstack/keystone/blob/master/keystone/common/sql/core.py#L87 I hit this issue because I had some duplicate endpoints in my environment, but it seems to be a more general problem, which could happen anytime you have a sufficiently large number of catalog entries. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240163/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1476264] Re: Cannot delete resources in remote services once project is deleted
This is not a problem with current policy/approach. The approach to fix 968696 will also ensure this continues to work. ** 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/1476264 Title: Cannot delete resources in remote services once project is deleted Status in OpenStack Identity (keystone): Invalid Bug description: Steps to reproduce: Create project Assign non-admin role to user As non-admin user Go to Glance and create image As admin Delete project As non-admin, cannot delete image If policy requires as scoped token, even admin cannot delete the image. This has the effect of forcing "admin somewhere is admin everywhere" To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1476264/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1425174] Re: explicit unscoped token request does not match spec
Was fixed in commit
98732367e384b89c9ff9dd632be870e774083b94
** Changed in: keystone
Status: In Progress => Fix Released
--
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/1425174
Title:
explicit unscoped token request does not match spec
Status in OpenStack Identity (keystone):
Fix Released
Bug description:
Spec states:
http://git.openstack.org/cgit/openstack/keystone-specs/tree/api/v3
/identity-api-v3.rst#n1779
A user may explicitly request an unscoped token by setting
the "scope" value of the token request to the string "unscoped."
However the code actaully tests:
scope_data['unscoped'] = {}
which generates a dictionary, not a string.
In this case, the spec should change to match the code.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1425174/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1505256] [NEW] Potential user_id collision between Federated IdPs
Public bug reported: User Ids cannot be something sepcified entirely by the Federation providers. If they are, there are a handful of potential problems: 1. The userId specified will be too big for the colum (varchar 64) 2. Two different Identity Providers can provide the same value for user_id The solution is to use the id_mapping capability of the identity backend. This should be enabled on a per-idp basis, and the default should be enabled. The id_mapping approach needs a separate domain_id to deconflict userids. This domain should be created by default and linked 1-to-1 with the IdP id. ** Affects: keystone 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/1505256 Title: Potential user_id collision between Federated IdPs Status in Keystone: New Bug description: User Ids cannot be something sepcified entirely by the Federation providers. If they are, there are a handful of potential problems: 1. The userId specified will be too big for the colum (varchar 64) 2. Two different Identity Providers can provide the same value for user_id The solution is to use the id_mapping capability of the identity backend. This should be enabled on a per-idp basis, and the default should be enabled. The id_mapping approach needs a separate domain_id to deconflict userids. This domain should be created by default and linked 1-to-1 with the IdP id. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1505256/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1490690] [NEW] Discovery fails for V3 when admin not exposed
Public bug reported:
V3 is not specifically rtied to either public or Admin in the specs, but
practically speaking, it is tied to admin;
When attempting to use the V3 api and the admin port is not exposed, the
followng happens:
$ echo $OS_AUTH_URL
https://hostname/v3
$ openstack server list
ERROR: openstack Unable to establish connection to
https://hostname:35357/v3/auth/tokens
Running on debug shows more information:
RESP BODY: {"version": {"status": "stable", "updated": "2013-03-06T00:00:00Z",
"media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v3+json"}, {"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"}], "id": "v3.0", "links":
[{"href": "https://keystone-admin.dream.io:35357/v3/;, "rel": "self"}]}}
It is the link in that response being used for discovery. That should be the
public URL, not the admin.
** Affects: keystone
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/1490690
Title:
Discovery fails for V3 when admin not exposed
Status in Keystone:
New
Bug description:
V3 is not specifically rtied to either public or Admin in the specs,
but practically speaking, it is tied to admin;
When attempting to use the V3 api and the admin port is not exposed,
the followng happens:
$ echo $OS_AUTH_URL
https://hostname/v3
$ openstack server list
ERROR: openstack Unable to establish connection to
https://hostname:35357/v3/auth/tokens
Running on debug shows more information:
RESP BODY: {"version": {"status": "stable", "updated":
"2013-03-06T00:00:00Z", "media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v3+json"}, {"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"}], "id": "v3.0", "links":
[{"href": "https://keystone-admin.dream.io:35357/v3/;, "rel": "self"}]}}
It is the link in that response being used for discovery. That should be the
public URL, not the admin.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1490690/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1317815] Re: Documentation Keystone SSL configuration lack
Since we are dropping support for Eventlet based deployments, continuing to document them is counterproductive. Please switch over to using Apache HTTPD. ** Changed in: keystone Status: Confirmed = Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1317815 Title: Documentation Keystone SSL configuration lack Status in Keystone: Won't Fix Bug description: Trying to configuring SSL on OpenStack Havana I read the official documentation here https://github.com/openstack/keystone/blob/stable/havana/doc/source/configuration.rst#ssl But I think that configuration is not enough to configure SSL on OpenStack. As far I know, to configure SSL on OpenStack, besides the configuration above, it is necessary to modify endpoints protocol from http to https and this is not documented on the official SSL Configuration document. Please, confirm if I'm wrong. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1317815/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1464750] Re: Service accounts can be used to login horizon
It might make sense to have Horizon limit login to users with the Member or Admin roles only. ** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Assignee: (unassigned) = Adam Young (ayoung) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1334480] Re: remove revocation model
The code is not moving to client after all. The code in the Server will stand. ** Changed in: keystone Status: Triaged = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1334480 Title: remove revocation model Status in Keystone: Invalid Bug description: The revocation events moved to keystoneclient. The code in Keystone is dead and needs to be removed before people start debuging it and using it. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1334480/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 968696] Re: admin-ness not properly scoped
** Also affects: glance Importance: Undecided Status: New ** Also affects: cinder Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/968696 Title: admin-ness not properly scoped Status in Cinder: New Status in Glance: New Status in OpenStack Dashboard (Horizon): Fix Released Status in Keystone: Confirmed Status in neutron: Incomplete Status in OpenStack Compute (nova): Confirmed Bug description: Fact: Keystone's rbac model grants roles to users on specific tenants, and post-keystone redux, there are no longer global roles. Problem: Granting a user an admin role on ANY tenant grants them unlimited admin-ness throughout the system because there is no differentiation between a scoped admin-ness and a global admin-ness. I don't have a specific solution to advocate, but being an admin on *any* tenant simply *cannot* allow you to administer all of keystone. Steps to reproduce (from Horizon, though you could do this with the CLI, too): 1. User A (existing admin) creates Project B and User B. 2. User A adds User B to Project B with the admin role on Project B. 3. User B logs in and now has unlimited admin rights not only to view things in the dashboard, but to take actions like creating new projects and users, managing existing projects and users, etc. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1472285] Re: set default domain dynamically
Default domain is a forward compat feature necessary to let V2 continue to work in a V3 aware keystone. The default domain is a very important domain, and should be part of the core configuration. Changing that on the fly will change the meaning of the V2 tokens, and is not something to be done lightly. In the future, I would like to drop default domain, but that can only be done after V2 is deprecated. I realize making config changes like this is painful for Puppet, but it is correct based on the way the web servers work. Probably not going to fix. ** Changed in: keystone Status: Incomplete = Opinion ** Changed in: keystone Importance: Undecided = Wishlist -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1472285 Title: set default domain dynamically Status in Keystone: Opinion Bug description: In order to set the default_domain_id, Keystone must first be running, and you must issue a domain create command to create the default domain and retrieve the id of the domain in order to set it in keystone.conf, then restart Keystone for the change to take effect. This causes problems for puppet based installers because puppet does not want to restart Keystone more than once. Instead, what would be preferable is the ability to set the default_domain_id dynamically. For example, when using `openstack`, add an option `--default- domain`:: $ openstack domain create defdomain --enable --description 'my default domain' --default-domain This would create the domain and make it the default domain, without having to restart Keystone for the change in default_domain_id to take effect. It doesn't have to be implemented this way, just a suggestion, but the method to set the default_domain_id should be exposed via the `openstack` cli. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1472285/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1477373] [NEW] No way to convert V2 tokens to V3 if domain id changes
Public bug reported: While many people are still stuck on V2 tokens, we need a safe way to map them to V3. If they default domain changes, the tokens will not be properly converted. THe best that can be done now is to guess that the domain_id is default and the name is Default both these values should be included as hints in V2 tokens until they are completely removed. ** Affects: keystone 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/1477373 Title: No way to convert V2 tokens to V3 if domain id changes Status in Keystone: New Bug description: While many people are still stuck on V2 tokens, we need a safe way to map them to V3. If they default domain changes, the tokens will not be properly converted. THe best that can be done now is to guess that the domain_id is default and the name is Default both these values should be included as hints in V2 tokens until they are completely removed. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1477373/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1476264] [NEW] Cannot delete resources in remote services once project is deleted
Public bug reported: Steps to reproduce: Create project Assign non-admin role to user As non-admin user Go to Glance and create image As admin Delete project As non-admin, cannot delete image If policy requires as scoped token, even admin cannot delete the image. This has the effect of forcing admin somewhere is admin everywhere ** Affects: keystone Importance: High Assignee: Adam Young (ayoung) Status: New ** Changed in: keystone Importance: Undecided = High ** Changed in: keystone Assignee: (unassigned) = Adam Young (ayoung) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1476264 Title: Cannot delete resources in remote services once project is deleted Status in Keystone: New Bug description: Steps to reproduce: Create project Assign non-admin role to user As non-admin user Go to Glance and create image As admin Delete project As non-admin, cannot delete image If policy requires as scoped token, even admin cannot delete the image. This has the effect of forcing admin somewhere is admin everywhere To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1476264/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1452345] [NEW] keystone-manage should not attempt to run if keystone is in httpd
Public bug reported: If a user attempts to run keystone-manage but the instance is configured to run in httpd, it will attempt to start the eventlet server. If the httpd instance is running, the error is confusing, since a port is already in use. ** Affects: keystone 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/1452345 Title: keystone-manage should not attempt to run if keystone is in httpd Status in OpenStack Identity (Keystone): New Bug description: If a user attempts to run keystone-manage but the instance is configured to run in httpd, it will attempt to start the eventlet server. If the httpd instance is running, the error is confusing, since a port is already in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1452345/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1441827] [NEW] Cannot set per protocol remote_id_attribute
Public bug reported: Setup Federation with SSSD. Worked OK with [federation] remote_id_attribute=foo but not with [kerberos] remote_id_attribute=foo ** Affects: keystone Importance: Undecided Assignee: Lin Hua Cheng (lin-hua-cheng) Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1441827 Title: Cannot set per protocol remote_id_attribute Status in OpenStack Identity (Keystone): Confirmed Bug description: Setup Federation with SSSD. Worked OK with [federation] remote_id_attribute=foo but not with [kerberos] remote_id_attribute=foo To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1441827/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1427878] Re: cannot use v3 token with v2 services
The issue is with configuring Nova. When I edited Nova's conf file so that authe vesrion was unset, like this: auth_version= And restarted all the Nova services, it worked. ** Changed in: keystone Importance: Critical = Medium ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1427878 Title: Nova cannot validate v3 token by default Status in OpenStack Compute (Nova): New Bug description: Scenario: keystone is enabled for v3 with v3 policy Create two domains: default domain has service user accounts and projects - user domain is backed by ldap and has plain end user accounts Configure Horizon to be domain aware - hard code the user domain as the keystone domain to use by default Configure a user in the user domain to have admin rights over the default domain service project Can login to Horizon using a user from the user domain Problem: most operations fail - not authorized - but Identity operations work fine I edited keystone/token/providers/common.py - I commented out the line self._assert_default_domain(token_ref) in def validate_v2_token(self, token_ref) I restarted keystone Now, everything works fine - no errors Why isn't the service trying to validate the v3 token? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1427878/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1427878] Re: cannot use v3 token with v2 services
** No longer affects: keystone ** Summary changed: - cannot use v3 token with v2 services + Nova cannot validate v3 token by default -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1427878 Title: Nova cannot validate v3 token by default Status in OpenStack Compute (Nova): New Bug description: Scenario: keystone is enabled for v3 with v3 policy Create two domains: default domain has service user accounts and projects - user domain is backed by ldap and has plain end user accounts Configure Horizon to be domain aware - hard code the user domain as the keystone domain to use by default Configure a user in the user domain to have admin rights over the default domain service project Can login to Horizon using a user from the user domain Problem: most operations fail - not authorized - but Identity operations work fine I edited keystone/token/providers/common.py - I commented out the line self._assert_default_domain(token_ref) in def validate_v2_token(self, token_ref) I restarted keystone Now, everything works fine - no errors Why isn't the service trying to validate the v3 token? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1427878/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1425174] [NEW] explicit unscoped token request does not match spec
Public bug reported:
Spec states:
http://git.openstack.org/cgit/openstack/keystone-specs/tree/api/v3
/identity-api-v3.rst#n1779
A user may explicitly request an unscoped token by setting
the scope value of the token request to the string unscoped.
However the code actaully tests:
scope_data['unscoped'] = {}
which generates a dictionary, not a string.
In this case, the spec should change to match the code.
** Affects: keystone
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/1425174
Title:
explicit unscoped token request does not match spec
Status in OpenStack Identity (Keystone):
New
Bug description:
Spec states:
http://git.openstack.org/cgit/openstack/keystone-specs/tree/api/v3
/identity-api-v3.rst#n1779
A user may explicitly request an unscoped token by setting
the scope value of the token request to the string unscoped.
However the code actaully tests:
scope_data['unscoped'] = {}
which generates a dictionary, not a string.
In this case, the spec should change to match the code.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1425174/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1396763] Re: user id beginning with 0 cannot authenticate through ldap
** Also affects: keystone/icehouse Importance: Undecided Status: New ** Also affects: keystone/kilo Importance: High Assignee: Steve Martinelli (stevemar) Status: In Progress ** Also affects: keystone/juno 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/1396763 Title: user id beginning with 0 cannot authenticate through ldap Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: New Status in Keystone juno series: New Status in Keystone kilo series: In Progress Bug description: In the case where the [ldap] user_id_attribute = uid Lets say a user attempts to authenticate with steve...@example.com, and the UID returned is 01234567. The following log entries show that the leading 0 is dropped: keystone.common.ldap.core [-] LDAP search: base=o=example.com scope=2 filterstr=((emailAddress=steve...@example.com)(objectClass=person)) attrs=['emailAddress', 'userPassword', 'enabled', 'uid'] attrsonly=0 search_s /opt/stack/keystone/keystone/common/ldap/core.py:926 keystone.common.ldap.core [-] LDAP unbind unbind_s /opt/stack/keystone/keystone/common/ldap/core.py:899 keystone.identity.core [-] ID Mapping - Domain ID: default, Default Driver: True, Domains: False, UUIDs: False, Compatible IDs: True _set_domain_id_and_mapping /opt/stack/keystone/keystone/identity/core.py:321 keystone.identity.core [-] Local ID: 1234567 _set_domain_id_and_mapping_for_single_ref /opt/stack/keystone/keystone/identity/core.py:339 keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 _common_ldap_initialization /opt/stack/keystone/keystone/common/ldap/core.py:575 ** here is where the leading 0 is dropped ** keystone.common.ldap.core [-] LDAP search: base=o=example.com scope=2 filterstr=((uid=1234567)(objectClass=person)) attrs=['emailAddress', 'userPassword', 'enabled', 'uid'] attrsonly=0 search_s /opt/stack/keystone/keystone/common/ldap/core.py:926 keystone.common.ldap.core [-] LDAP unbind unbind_s /opt/stack/keystone/keystone/common/ldap/core.py:899 keystone.common.wsgi [-] Authorization failed. Invalid username or password (Disable debug mode to suppress these details.) The main code in question is the following in keystone.common.ldap.core.py https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L110-L128 try: return LDAP_VALUES[val] except KeyError: pass try: return int(val) except ValueError: pass return utf8_decode(val) Where we attempt to convert all fields to int, and if it fails proceed to string. On a semi-related note: the PyCADF library explicitly expects user_ids to be strings, so I had to add str() to user_id in the _get_request_audit_info function, in notifications.py: initiator = resource.Resource(typeURI=taxonomy.ACCOUNT_USER, name=user_id, host=host) to initiator = resource.Resource(typeURI=taxonomy.ACCOUNT_USER, name=str(user_id), host=host) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1396763/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1400362] [NEW] check and delete policy_association_for_region_and_servce performs create
Public bug reported: In http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/endpoint_policy/controllers.py#n133 .create_policy_association should be check_policy_association @controller.protected() def check_policy_association_for_region_and_service( self, context, policy_id, service_id, region_id): Check an association between a policy and region+service. self.policy_api.get_policy(policy_id) self.catalog_api.get_service(service_id) self.catalog_api.get_region(region_id) self.endpoint_policy_api.create_policy_association( policy_id, service_id=service_id, region_id=region_id) create_policy_association( should be delete_policy_association( @controller.protected() def delete_policy_association_for_region_and_service( self, context, policy_id, service_id, region_id): Delete an association between a policy and region+service. self.policy_api.get_policy(policy_id) self.catalog_api.get_service(service_id) self.catalog_api.get_region(region_id) self.endpoint_policy_api.create_policy_association( policy_id, service_id=service_id, region_id=region_id) ** Affects: keystone 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/1400362 Title: check and delete policy_association_for_region_and_servce performs create Status in OpenStack Identity (Keystone): New Bug description: In http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/endpoint_policy/controllers.py#n133 .create_policy_association should be check_policy_association @controller.protected() def check_policy_association_for_region_and_service( self, context, policy_id, service_id, region_id): Check an association between a policy and region+service. self.policy_api.get_policy(policy_id) self.catalog_api.get_service(service_id) self.catalog_api.get_region(region_id) self.endpoint_policy_api.create_policy_association( policy_id, service_id=service_id, region_id=region_id) create_policy_association( should be delete_policy_association( @controller.protected() def delete_policy_association_for_region_and_service( self, context, policy_id, service_id, region_id): Delete an association between a policy and region+service. self.policy_api.get_policy(policy_id) self.catalog_api.get_service(service_id) self.catalog_api.get_region(region_id) self.endpoint_policy_api.create_policy_association( policy_id, service_id=service_id, region_id=region_id) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1400362/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1399768] [NEW] migration ofr endpoint_filter failes due to foreign key constraint
Public bug reported: keystone-manage db_sync --extension endpoint_filter 2 fails with 2014-12-05 13:54:39.295 11241 TRACE keystone OperationalError: (OperationalError) (1005, Can't create table 'keystone.project_endpoint_group' (errno: 150)) '\nCREATE TABLE project_endpoint_group (\n\tendpoint_group_id VARCHAR(64) NOT NULL, \n\tproject_id VARCHAR(64) NOT NULL, \n\tPRIMARY KEY (endpoint_group_id, project_id), \n\tFOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id)\n)\n\n' () Migration 1 fails executing the below sql. CREATE TABLE project_endpoint_group (endpoint_group_id VARCHAR(64) NOT NULL, project_id VARCHAR(64) NOT NULL, PRIMARY KEY (endpoint_group_id, project_id), FOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id)); ERROR 1005 (HY000): Can't create table 'keystone.project_endpoint_group' (errno: 150) Removing the clause FOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id)) makes it work. THis is on Fedora 20 and I mariadb flavor of MySQL. ** Affects: keystone 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/1399768 Title: migration ofr endpoint_filter failes due to foreign key constraint Status in OpenStack Identity (Keystone): New Bug description: keystone-manage db_sync --extension endpoint_filter 2 fails with 2014-12-05 13:54:39.295 11241 TRACE keystone OperationalError: (OperationalError) (1005, Can't create table 'keystone.project_endpoint_group' (errno: 150)) '\nCREATE TABLE project_endpoint_group (\n\tendpoint_group_id VARCHAR(64) NOT NULL, \n\tproject_id VARCHAR(64) NOT NULL, \n\tPRIMARY KEY (endpoint_group_id, project_id), \n\tFOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id)\n)\n\n' () Migration 1 fails executing the below sql. CREATE TABLE project_endpoint_group (endpoint_group_id VARCHAR(64) NOT NULL, project_id VARCHAR(64) NOT NULL, PRIMARY KEY (endpoint_group_id, project_id), FOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id)); ERROR 1005 (HY000): Can't create table 'keystone.project_endpoint_group' (errno: 150) Removing the clause FOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id)) makes it work. THis is on Fedora 20 and I mariadb flavor of MySQL. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1399768/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1399768] Re: migration ofr endpoint_filter failes due to foreign key constraint
Looks like I had an old .pyc file causing this ** Changed in: keystone Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1399768 Title: migration ofr endpoint_filter failes due to foreign key constraint Status in OpenStack Identity (Keystone): Invalid Bug description: keystone-manage db_sync --extension endpoint_filter 2 fails with 2014-12-05 13:54:39.295 11241 TRACE keystone OperationalError: (OperationalError) (1005, Can't create table 'keystone.project_endpoint_group' (errno: 150)) '\nCREATE TABLE project_endpoint_group (\n\tendpoint_group_id VARCHAR(64) NOT NULL, \n\tproject_id VARCHAR(64) NOT NULL, \n\tPRIMARY KEY (endpoint_group_id, project_id), \n\tFOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id)\n)\n\n' () Migration 1 fails executing the below sql. CREATE TABLE project_endpoint_group (endpoint_group_id VARCHAR(64) NOT NULL, project_id VARCHAR(64) NOT NULL, PRIMARY KEY (endpoint_group_id, project_id), FOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id)); ERROR 1005 (HY000): Can't create table 'keystone.project_endpoint_group' (errno: 150) Removing the clause FOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id)) makes it work. THis is on Fedora 20 and I mariadb flavor of MySQL. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1399768/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1399857] [NEW] endpoint_policy has typo in delete
Public bug reported: When activating the endpoint_policy extension, and then deleting a policy file, get the following error: keystoneclient.openstack.common.apiclient.exceptions.InternalServerError: An unexpected error prevented the server from fulfilling your request: 'EndpointPolicy' object has no attribute 'delete_association_by_polcy' (Disable debug mode to suppress these details.) (HTTP 500) There is a typo in the controller that can be fixed by this change. diff --git a/keystone/contrib/endpoint_policy/controllers.py b/keystone/contrib/endpoint_policy/controllers.py index c1533f7..569fe9b 100644 --- a/keystone/contrib/endpoint_policy/controllers.py +++ b/keystone/contrib/endpoint_policy/controllers.py @@ -46,7 +46,7 @@ class EndpointPolicyV3Controller(controller.V3Controller): payload['resource_info']) def _on_policy_delete(self, service, resource_type, operation, payload): -self.endpoint_policy_api.delete_association_by_polcy( +self.endpoint_policy_api.delete_association_by_policy( payload['resource_info']) ** Affects: keystone Importance: Undecided Assignee: Adam Young (ayoung) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1399857 Title: endpoint_policy has typo in delete Status in OpenStack Identity (Keystone): In Progress Bug description: When activating the endpoint_policy extension, and then deleting a policy file, get the following error: keystoneclient.openstack.common.apiclient.exceptions.InternalServerError: An unexpected error prevented the server from fulfilling your request: 'EndpointPolicy' object has no attribute 'delete_association_by_polcy' (Disable debug mode to suppress these details.) (HTTP 500) There is a typo in the controller that can be fixed by this change. diff --git a/keystone/contrib/endpoint_policy/controllers.py b/keystone/contrib/endpoint_policy/controllers.py index c1533f7..569fe9b 100644 --- a/keystone/contrib/endpoint_policy/controllers.py +++ b/keystone/contrib/endpoint_policy/controllers.py @@ -46,7 +46,7 @@ class EndpointPolicyV3Controller(controller.V3Controller): payload['resource_info']) def _on_policy_delete(self, service, resource_type, operation, payload): -self.endpoint_policy_api.delete_association_by_polcy( +self.endpoint_policy_api.delete_association_by_policy( payload['resource_info']) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1399857/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1101287] Re: Keystone LDAP does not support v3 Role Grants
** Changed in: keystone Status: In Progress = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1101287 Title: Keystone LDAP does not support v3 Role Grants Status in OpenStack Identity (Keystone): Fix Released Bug description: Although the current keystone backend does support role grants to user and tenants, it is not hooked up to the new v3 role grant api. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1101287/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1366020] [NEW] LDAP Identity does not convert ID to DN for lookup
Public bug reported: there is a disconnect between how Identity gets users for Authentication and how it creates users. When creating a user, deleting a user, etc, the identity code calls: conn.add_s(self._id_to_dn(values['id']), attrs) Which attempts to convert an id to a dn two different ways. One is by composing the DN: def _id_to_dn_string(self, object_id): return u'%s=%s,%s' % (self.id_attr, ldap.dn.escape_dn_chars( six.text_type(object_id)), self.tree_dn) The other is by searching for a record of that objectclass The difference is whether subtree searches are enabled. The authenticate code path is different: def authenticate(self, user_id, password): try: user_ref = self._get_user(user_id) ... def _get_user(self, user_id): return self.user.get(user_id) def get(self, object_id, ldap_filter=None): res = self._ldap_get(object_id, ldap_filter) def _ldap_get(self, object_id, ldap_filter=None): conn = self.get_connection() query = (u'((%(id_attr)s=%(id)s)' Note that this second way of finding the object matches the subtree search method. I think this has worked thus far mostly due to convention: If a DN is of the form: uid=ayoung,cn and the object has the attribute uid=ayoung Both searches will match the object. However, if the DN is like this: CN=ayoung,CN=... but the user has CN=Adam The second will not match. ** Affects: keystone 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/1366020 Title: LDAP Identity does not convert ID to DN for lookup Status in OpenStack Identity (Keystone): New Bug description: there is a disconnect between how Identity gets users for Authentication and how it creates users. When creating a user, deleting a user, etc, the identity code calls: conn.add_s(self._id_to_dn(values['id']), attrs) Which attempts to convert an id to a dn two different ways. One is by composing the DN: def _id_to_dn_string(self, object_id): return u'%s=%s,%s' % (self.id_attr, ldap.dn.escape_dn_chars( six.text_type(object_id)), self.tree_dn) The other is by searching for a record of that objectclass The difference is whether subtree searches are enabled. The authenticate code path is different: def authenticate(self, user_id, password): try: user_ref = self._get_user(user_id) ... def _get_user(self, user_id): return self.user.get(user_id) def get(self, object_id, ldap_filter=None): res = self._ldap_get(object_id, ldap_filter) def _ldap_get(self, object_id, ldap_filter=None): conn = self.get_connection() query = (u'((%(id_attr)s=%(id)s)' Note that this second way of finding the object matches the subtree search method. I think this has worked thus far mostly due to convention: If a DN is of the form: uid=ayoung,cn and the object has the attribute uid=ayoung Both searches will match the object. However, if the DN is like this: CN=ayoung,CN=... but the user has CN=Adam The second will not match. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1366020/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1355125] Re: keystonemiddleware appears not to hash PKIZ tokens
** Also affects: python-keystoneclient Importance: Undecided Status: New ** No longer affects: keystone ** Changed in: python-keystoneclient Assignee: (unassigned) = Adam Young (ayoung) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1355125 Title: keystonemiddleware appears not to hash PKIZ tokens Status in OpenStack Identity (Keystone) Middleware: In Progress Status in Python client library for Keystone: New Bug description: It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself) And that should make token revocation for PKIZ tokens broken. [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399 [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741 To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1355125/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1356682] [NEW] GET /v3/users lists users in all domains
Public bug reported: The behaviour of this API is different if CONF.identity.domain_specific_drivers_enabled is set or not. If it is not set, then listing user shows for all domains. If it is set, even for SQL, only a single domain is listed. The correct behavior would be to only list users for the domain extracted from the users tokens, regardless of the value set here. Otherwise, data leaks across domains. ** Affects: keystone 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/1356682 Title: GET /v3/users lists users in all domains Status in OpenStack Identity (Keystone): New Bug description: The behaviour of this API is different if CONF.identity.domain_specific_drivers_enabled is set or not. If it is not set, then listing user shows for all domains. If it is set, even for SQL, only a single domain is listed. The correct behavior would be to only list users for the domain extracted from the users tokens, regardless of the value set here. Otherwise, data leaks across domains. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1356682/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1278843] Re: Neutron doesn't report using a stale CA certificate
** Also affects: keystonemiddleware Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1278843 Title: Neutron doesn't report using a stale CA certificate Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Neutron (virtual network service): Confirmed Bug description: It seems that when the CA certificate cashed locally by Neutron in /var/lib/neutron/keystone-signing/ is stale (does not match the current CA cert used by keystone), it is not possible to start a new instance. This is understandable. However, the stacktrace error you get while trying to start as instance in such a situation is a hugely misleading: ERROR: Error: unsupported operand type(s) for +: 'NoneType' and 'str' It's rather tricky to debug the issue. To reproduce just redo the pki-setup for keystone on a deployed and otherwise healthy openstack cluster. This will create a new CA cert for keystone, however neutron-server will be completely oblivious to this fact and will still insist on using it's local copy of the cacert. I'm running Havana on rhel6.4 -- /var/log/nova/compute.log on the compute node when trying to start a vm OpenStack (nova:4668) ERROR: Instance failed network setup after 1 attempt(s) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager Traceback (most recent call last): 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1238, in _allocate_network_async 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager dhcp_options=dhcp_options) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/nova/network/api.py, line 49, in wrapper 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager res = f(self, context, *args, **kwargs) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py, line 358, in allocate_for_instance 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager LOG.exception(msg, port_id) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py, line 323, in allocate_for_instance 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager port_req_body) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py, line 392, in _populate_neutron_extension_values 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager self._refresh_neutron_extensions_cache() 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py, line 376, in _refresh_neutron_extensions_cache 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager extensions_list = neutron.list_extensions()['extensions'] 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py, line 108, in with_params 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager ret = self.function(instance, *args, **kwargs) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py, line 286, in list_extensions 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager return self.get(self.extensions_path, params=_params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py, line 1183, in get 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager headers=headers, params=params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py, line 1168, in retry_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager headers=headers, params=params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py, line 1103, in do_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager resp, replybody = self.httpclient.do_request(action, method, body=body) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/neutronclient/client.py, line 188, in do_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager self.authenticate() 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File /usr/lib/python2.6/site-packages/neutronclient/client.py, line 224, in authenticate 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager token_url = self.auth_url + /tokens 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager TypeError: unsupported operand
[Yahoo-eng-team] [Bug 1354765] [NEW] Valid V3 tokens reported as invalid
Public bug reported:
Use CURL to get an admin token and use it to perform list domains will
result in a failure.
Get an unscoped token:
$ cat token-request-admin.json
{
auth: {
identity: {
methods: [
password
],
password: {
user: {
domain: {
name: Default
},
name: admin,
password: FreeIPA4All
}
}
},
scope: {
project: {
domain: {
name: Default
},
name: demo
}
}
}
}
-sh-4.2$ export TOKEN=`curl -si -d @token-request-admin.json -H Content-type:
application/json http://localhost:35357/v3/auth/tokens | awk
'/X-Subject-Token/ {print $2}'`-sh-4.2$ echo $TOKEN
PKIZ_eJy9Wltz2kq3fJ9fcd537YoukISH70EgIUQ8owgLiZk3JDm6ji8fNkL69acHcLYhTgLZp46rXBhjadZa06u718h__42vseN67H8m9Fa9-ZtQz-PfLD7_8iC8YpsyK0gnD_hdEk4mrltPrMDZTUJrNs6X_7VzOnGryWT67LmT2yf31ktMYgfOzFrjlxvq5MX6w1031xLjuUlK76M325RJHGlrd1SnHd5PN2XqTvvUzLapDMrVbZsT736-Tdyo96qHPDY35ToOSr-0SmrMpXB5y6txzftcZ_YUr_XAj6eFqOaVHwc7P1zqRMS8vJlYZSKnz-IWq0zmDyKeaiuTaTxm_10ZIzORUefdaxsV0esCvp32wnVMIuzlgLqLmtm892NvKCpRU9vZYdWdCKeShen5AoVw9ceknI8OKchokLpNJ1bsG18dw6-sHZtorT_RdnQatLR66PHdstuBznpnSO1s7ZVt7t2PO5IYjw031YXjT55cbJN4-vhawNdwhRtJvoo22cTbIIIXHuuNqplXLxoi5FRPZkH5DeF4sqn3H1RUp8aiYXEw9GPa-_ZCsmpc0CormBsMREV7FgY9j5c7sg9FDoskXr6u9px085HKmxtTFHK3FfstfEaE0YuYjbfreKilx99hG6MumRyqn80WrV9-3tKw7m4qx_Angx2q_ULD9CNeTdqNerGaG-uYNWk3shN3hG085NWJOHtMjME-iqWM7tfx6CU0hs0hwuYlc6MO6VbHnWizeL5Zx7QkKtTXYjGJvF1Hp2HTHH4WDatqE-CpARzdt62dsMeSht6-ZkCtTlLZ7i9ezxZaaj9sb9Q2lYMdq3KEnptIxfSr3GQ93aZG1GWyqcSKboN48byOB4cI0mPI-x1o5o0wmm1Sj14QrkrvMblfNKkUBTcOhebHi9W15Ptehw6wDezLwOAx75ktCiE9vBalH2YNYGtghwrWB9_DV9GTPwrf2G0zLLyP4NrwFQawlUBje57Ct
GDhuGSVN6D2uGC2Y1K7KERIh6wKhtRlktlpRw2kEGnq5trdatyQ_coyqmh5WFHsQeVhu0RBDa5Tmxsi9jQmnc53gyHrl70fiho_7xheCSvPGmR_MwXl8bvQPUcu-RV0WTky6O1nNA6rRRjVftigjXJNVNit0DN5uKiJ7_Ke9kuNGtOG3l4Pa_IW129hTeWioiGrqEuRu9Mx2xrSqmhEVQ95DFYKPQPY6UFpzgkwLsMF32aVs0XkuIG71IWNu_Z0wFxuULWa4WjCLiTtKdiYYTWn_BnkyTWg-YfiVPi54duOQXjFNdBUhwqXPHRaVqVDIZkUttci_9-mR36V3yXpkV_ld0lLnzCSqKKSS96r1mZ2A7EB-0rPVMARknZICWyl0uTf-4Gohtivei-2ySx6fl3x2BMdQ7FYj2_DG4jQ0kS4HGIRNNUCzQdtpHKJPxLVjz3BHhPwYvqbviCXULoqKDQSxfVe6BmLkwtp_CioJ-lpPBxLQsOlgRSkj_w4quzviSXYCVdAZHMAJh2wyTGNd0SIvBcyC62WTtDK5aA9qPBxW8v9xbeH8IdfE7l83cY9ZCUMxXFHxjqXu0fevQ153nBFNlVT-LanC5cihXlD_Ji3LCxqoKxnfQQKTwe0-3nI5xGTa0M-j_hIqoeqw8Zsjrtw8AkSCIxF44NgVbigMPgEAAjIhIaaYHJlMKKCIy_vXs_U3bNZ0x637hFKhBs32t0pOsHUTYVWhujSAaHuUlN35FUGR4JGBmwpHIqADohzSyOfm7sVg48EXo6uDTZvWKfuSHXbd6-YreabwwWFls2sjzfdZ-gmUBjyAQo4YB1orn8YsD7VyI3J-2sL97Zu5IfCVdjfyjOpnMOZco1WC0ldPvBd9IMLlMZLoJNqYOxSpUFUHteEfB4xuTzkaZ3EzctZtDBZIYTTWJowEOC_RcV6dF4FYMUBEJo1tMfnvfhe9fNoyTXh_ttmgmfgJjccOFcOngR-0FwEnqgDx-
2gd9A9GOswavzbgxP37hfD1D2ysDF6TmcRFjpGdawDekHUDMosKlh9u2ioHWgwVmjZAKt5ndJuXs1LDlo7t8WJHEGZ1B2PBfoTVJI3RTNQtO6mv9ypq4jI9RA-xcOBD6pgR1FRP56jG5s9qdIepIpIqL0c-m6kIuqopNo5HsgF8P1lauRnuV2aGvk1eDyYzBTYwKq2MhXoTggsj6cV7wsoNSsRQYo_ynV-ezkTv7WBhJa_9oG_s4HkAl08mgsgcHImNAaThMVT6ceQeOlogPEAbKvzyuqUuUbumGoxyXY_9kYmR5sMZEsg2eXp3ATqgi_BnqAfeIe5qfZtZTJEwyu626MSo7J_tEbkzUxcYWtqNdb935ntvdz9P5jt99zHUIDOMVwMOOZFWDsNxe15mA-FO5eQQ3yGgcN1NMLLPwDQm9TInwLoNTVyyXz8dptBbUPIwEAoIxrSlqATDWrn8MV0xyunhZzBqeYDZgQXzRHk1GgHygtebLSVz_6j2fntHHFqtl2-ozFWCjPQGeYIO4dSFxW1Uw2q3MHSVHDpDe_Td8y2ZNtkNdYzd3naG32x50pe5bhBrobyBsNXzWOvhcMzoUxzeKR8SKV3fl70kpii-J1mkAt8AfBAfyqy5HpPgHkBn4MTSyWJRJEIVVO7jZnEBsvE1KTwhOh342ee4G2k5NJQ_9CpAlBVVgnMTojUAMUZ6JOCKucaTwsolUFgFHRsj3lJuO9Fe724ngkQeaVoZkOF3HlD4VRYDB_YY4qxnZbaNawwGLtftr4Nnzg5Zej9zJT2py0Ld6JOKxFkUQgJZrItyFoD5sLMaIiSVcudsC1wh3XohTfo678PGxcw8k9nJt8-DiAXkCy5cMQDF2AUAOnsO9ZWNbJMH7YAdt_rIW0YoBQH0qG4kmTJNeG-J7zkfeX1sNfBjqPyPoyn8kYC4gtthM1XcxQsf7wA6dAdYVcbi9OIyZ8ehb7ihhwO4nJDnRX5IcQlzFBtBkQ
CNHZWsdCD2AfgySU-804O4o42j20SM6qFHHVJPNX27HxCIPAGmOzQdHBwDka-wGQVdksdpdsZTJaBldw55sBxc26m125UZBO9EnLwKjJNIhdtYiC1GVWn4Qm54gQLjRX8cMJD_vQE61V4yHvKg8GiTNymOq0FuLMP1LTSqhN-Fi4aEYMTMeYCwpYuqrz3Xdr6YT28hp2IMtTUttSAtbt2VlBsRv7NrHCcmVKD2bXB0JU09HZgXmgecjSQs_JHvTXc59wH7-oE-dWscElq5N_MChcIC1Jy0QuhaJihzhiDnYjVdjoD9M2QxbwDlAODhan2zhHINpXsQayYlsp3ekTSFvwwUAeSBoxCxzC1onDwROpIcIkP4ZlgKrmMivd75MAj5FL6fpdcQm9Ijmfq13Lhd-Ymbw_k0QtDeEUdcDYomBqqVMO5dqKKJFVp9l6LQb19ezh30XmiCvVnkZJrOXDv3CoPPsHCzWB1eZh28IPoSFQdwMAI3IATlYDqzPCuPVeuQazeVcfE5HfH4EzC0qjTzR4EAhKFPmL4qHdg65b2XCPqEQA30HXS-YGyUZNnHmfNKQIDGI5FJdxAZ2Gug1CCIbZswCUGq0qprwN-VKQ5L394EmjsikSCG46wFyu0M3C-t6535n51XT1P2r_v5nVi6IU6_j48zHyNAKkcn1Gez42OiEWRxbvDIcM_Iy56QzF0ig7k-_Ml5egBOOxciqErjNSJzUA9yWPd-fnhkcKON8S4pUOVT57NkpOHs-HZw9l-vka-I8q9cR5OJtZKU0_C25U9XtFg004CbpMoCOC95tGyd3xqta6lL52J1U6jeNiLVbCzK4uOcxaNrZSOo-gFNdJoMGhti9u49guxrShK7lmT2Q6nY76_gdW2XzMzM29khMFTbxN3-aJOsqzcGVMrdce3G99qvTW1NJe8PoS3A2dsBUtr7Hlj68tsuKSP34y01bRb52ZR3JW5cZPkT3fR8871k8H9aJazPPf-
[Yahoo-eng-team] [Bug 1343709] [NEW] Cannot Use Default Domain with Kerberos
Public bug reported: From: https://etherpad.openstack.org/p/keystone-juno-hackathon Remove method name from auth plugins (so the method name is owned by keystone.conf) One place where this shows up is that the kerberos method requires a new AuthPlugin for existing functionality, such as using the Default Domain. ** Affects: keystone 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/1343709 Title: Cannot Use Default Domain with Kerberos Status in OpenStack Identity (Keystone): New Bug description: From: https://etherpad.openstack.org/p/keystone-juno-hackathon Remove method name from auth plugins (so the method name is owned by keystone.conf) One place where this shows up is that the kerberos method requires a new AuthPlugin for existing functionality, such as using the Default Domain. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1343709/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1334480] [NEW] remove revocation model
Public bug reported: The revocation events moved to keystoneclient. The code in Keystone is dead and needs to be removed before people start debuging it and using it. ** Affects: keystone Importance: Undecided Assignee: Navid Pustchi (npustchi) Status: New ** Changed in: keystone Assignee: (unassigned) = Navid (navid) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1334480 Title: remove revocation model Status in OpenStack Identity (Keystone): New Bug description: The revocation events moved to keystoneclient. The code in Keystone is dead and needs to be removed before people start debuging it and using it. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1334480/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1259011] Re: Certificates cannot be retrieved from the V3 API
** Also affects: keystonemiddleware 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/1259011 Title: Certificates cannot be retrieved from the V3 API Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack API documentation site: Fix Released Status in Python client library for Keystone: New Bug description: Auth_token middleware relies upon the V2 api to provide the certificates that are required to validate PKI tokens because this information is not provided by the V3 API. Longer term i think we should be encouraging deployers to handle their own certificate distribution as fetching the certificates from the same source that is issuing tokens is not secure, however for the mean time we need some way of providing these certificates to token validators. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1259011/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1317302] Re: pki_setup shouldn't be required to check revocations
** Also affects: keystonemiddleware 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/1317302 Title: pki_setup shouldn't be required to check revocations Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Identity (Keystone) Middleware: New Status in Python client library for Keystone: In Progress Bug description: With the fix for bug 1312858 , auth_token can validate UUID tokens or hashed PKI tokens against the revocation list. But in order to use this in a setting where only UUID tokens are being used, the server still needs to have pki_setup run. We should be able to check UUID tokens against the revocation list even when pki_setup hasn't been done. The reason pki_setup has to be done is that the revocation list is signed using CMS. The auth_token middleware only accepts the signed format for the revocation list. The proposed solution is to change the auth_token middleware to also accept a revocation list that's not signed. If it's not signed, then the PKI certificates aren't required. The keystone server will be changed to allow configuring it such that the revocation list will be sent as an unencrypted JSON object that the auth_token middleware can now accept. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1317302/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1330771] Re: pbr as run time requirement conflicts with distro packaging
There is also a Keystone side to this, in that we import pbr in keystone-all and in keystone/cli.py and it does not belong there. ** Changed in: keystone Status: Invalid = 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/1330771 Title: pbr as run time requirement conflicts with distro packaging Status in OpenStack Identity (Keystone): New Status in Python Build Reasonableness: New Bug description: Using PBR for development makes sense, but it should not be a run time requirement for keystone-all or the other tools. All it is doing is reporting the version of the python library, and that does not require any of the rest of PBR. However, PBR pulls in tools that are rightfully build time requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1330771/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1330771] Re: pbr as run time requirement conflicts with distro packaging
I'll open a separate bug for Keystone ** Changed in: keystone Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1330771 Title: pbr as run time requirement conflicts with distro packaging Status in OpenStack Identity (Keystone): Invalid Status in Python Build Reasonableness: New Bug description: Using PBR for development makes sense, but it should not be a run time requirement for keystone-all or the other tools. All it is doing is reporting the version of the python library, and that does not require any of the rest of PBR. However, PBR pulls in tools that are rightfully build time requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1330771/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1331217] [NEW] keystone should not import pbr
Public bug reported: pbr is a build time tool, and pulls in dependencies that are not appropriate for runtime. It is only used for the version string in order to load the config file. Longer issues with pbr are discussed https://bugs.launchpad.net/keystone/+bug/1330771 ** Affects: keystone 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/1331217 Title: keystone should not import pbr Status in OpenStack Identity (Keystone): New Bug description: pbr is a build time tool, and pulls in dependencies that are not appropriate for runtime. It is only used for the version string in order to load the config file. Longer issues with pbr are discussed https://bugs.launchpad.net/keystone/+bug/1330771 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1331217/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1330771] [NEW] pbr as run time requirement conflicts with distro packaging
Public bug reported: Using PBR for development makes sense, but it should not be a run time requirement for keystone-all or the other tools. All it is doing is reporting the version of the python library, and that does not require any of the rest of PBR. However, PBR pulls in tools that are rightfully build time requirements. ** Affects: keystone 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/1330771 Title: pbr as run time requirement conflicts with distro packaging Status in OpenStack Identity (Keystone): New Bug description: Using PBR for development makes sense, but it should not be a run time requirement for keystone-all or the other tools. All it is doing is reporting the version of the python library, and that does not require any of the rest of PBR. However, PBR pulls in tools that are rightfully build time requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1330771/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1328201] [NEW] Cannot fetch Certs with Compressed token provider
Public bug reported: The simple_cert extension has a check that prevents fetching certificates if the Token provider is not the PKI provider. ** Affects: keystone Importance: Critical Assignee: Adam Young (ayoung) Status: In Progress ** Changed in: keystone Importance: Undecided = Critical -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1328201 Title: Cannot fetch Certs with Compressed token provider Status in OpenStack Identity (Keystone): In Progress Bug description: The simple_cert extension has a check that prevents fetching certificates if the Token provider is not the PKI provider. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1328201/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1211602] Re: revocation list should not be a protected resource
** Changed in: keystone Status: Confirmed = Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1211602 Title: revocation list should not be a protected resource Status in OpenStack Identity (Keystone): Won't Fix Bug description: The Revocation List resources should not be protected. The Revocation list is akin to a CRL and likely should be available for public consumption as a CRL would be. Resources are: v3: /auth/tokens/OS-PKI/revoked v2: /tokens/revoked To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1211602/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1312971] [NEW] mod_wsgi exception processing UTF-F Header
Public bug reported: Using master version of python-keystoneclient (not yet released) gives the following error when running with Keystone in Apache HTTPD and requesting a V3 Token [Fri Apr 25 18:28:14.775659 2014] [:error] [pid 5075] [remote 10.10.63.250:2982] mod_wsgi (pid=5075): Exception occurred processing WSGI script '/var/www/cgi-bin/keystone/main'. [Fri Apr 25 18:28:14.775801 2014] [:error] [pid 5075] [remote 10.10.63.250:2982] TypeError: expected byte string object for header value, value of type unicode found Its due to the utf-8 encoding in keystoneclient/common/cms.py which is making the PKI token Unicode instead of str. ** Affects: keystone 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/1312971 Title: mod_wsgi exception processing UTF-F Header Status in OpenStack Identity (Keystone): New Bug description: Using master version of python-keystoneclient (not yet released) gives the following error when running with Keystone in Apache HTTPD and requesting a V3 Token [Fri Apr 25 18:28:14.775659 2014] [:error] [pid 5075] [remote 10.10.63.250:2982] mod_wsgi (pid=5075): Exception occurred processing WSGI script '/var/www/cgi-bin/keystone/main'. [Fri Apr 25 18:28:14.775801 2014] [:error] [pid 5075] [remote 10.10.63.250:2982] TypeError: expected byte string object for header value, value of type unicode found Its due to the utf-8 encoding in keystoneclient/common/cms.py which is making the PKI token Unicode instead of str. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1312971/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1312971] Re: mod_wsgi exception processing UTF-8 Header
Lets track it for both: it might not really be an issue that cms has converted from str to utf-8 for most things, just that mod_wsgi is enforcing what comes across in the header. I have a patch submitted alrady that mitigates the Keystone problem: https://review.openstack.org/#/c/90476/ I'll make sure it gets linked here. ** Summary changed: - mod_wsgi exception processing UTF-F Header + mod_wsgi exception processing UTF-8 Header ** Also affects: keystone 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/1312971 Title: mod_wsgi exception processing UTF-8 Header Status in OpenStack Identity (Keystone): New Status in Python client library for Keystone: Triaged Bug description: Using master version of python-keystoneclient (not yet released) gives the following error when running with Keystone in Apache HTTPD and requesting a V3 Token [Fri Apr 25 18:28:14.775659 2014] [:error] [pid 5075] [remote 10.10.63.250:2982] mod_wsgi (pid=5075): Exception occurred processing WSGI script '/var/www/cgi-bin/keystone/main'. [Fri Apr 25 18:28:14.775801 2014] [:error] [pid 5075] [remote 10.10.63.250:2982] TypeError: expected byte string object for header value, value of type unicode found Its due to the utf-8 encoding in keystoneclient/common/cms.py which is making the PKI token Unicode instead of str. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1312971/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1302075] [NEW] service catalog in token contains legacy_endpoint_id and enabled fields
Public bug reported:
regression of bug 1152635
Endpoints in the token look like this:
v3 [{url:
http://192.168.187.14:8774/v2/5d15013cbebd4b1e95ad3b5785c866f7;,
region: RegionOne, interface: admin, id:
486ce25c849b471a806d55304cd18191}, {url:
http://192.168.187.14:8774/v2/5d15013cbebd4b1e95ad3b5785c866f7;,
region: RegionOne, interface: internal, id:
63076e278a9e4560a08ce962e49c3618}, {url:
http://192.168.187.14:8774/v2/5d15013cbebd4b1e95ad3b5785c866f7;,
region: RegionOne, interface: public, id:
9b6e089b91734c508bbe117ea0865c76}]
** Affects: keystone
Importance: Critical
Assignee: Adam Young (ayoung)
Status: Incomplete
** Changed in: keystone
Assignee: (unassigned) = Adam Young (ayoung)
** Changed in: keystone
Milestone: None = icehouse-rc2
** Changed in: keystone
Status: New = Incomplete
** Changed in: keystone
Importance: Undecided = Critical
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1302075
Title:
service catalog in token contains legacy_endpoint_id and enabled
fields
Status in OpenStack Identity (Keystone):
Incomplete
Bug description:
regression of bug 1152635
Endpoints in the token look like this:
v3 [{url:
http://192.168.187.14:8774/v2/5d15013cbebd4b1e95ad3b5785c866f7;,
region: RegionOne, interface: admin, id:
486ce25c849b471a806d55304cd18191}, {url:
http://192.168.187.14:8774/v2/5d15013cbebd4b1e95ad3b5785c866f7;,
region: RegionOne, interface: internal, id:
63076e278a9e4560a08ce962e49c3618}, {url:
http://192.168.187.14:8774/v2/5d15013cbebd4b1e95ad3b5785c866f7;,
region: RegionOne, interface: public, id:
9b6e089b91734c508bbe117ea0865c76}]
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1302075/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1301141] Re: Invalid Import in pki.py
I think this report is in error. The UUID token was the base class for the PKI token until Icehouse. PKI tokens are widely deployed. ** Changed in: keystone Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1301141 Title: Invalid Import in pki.py Status in OpenStack Identity (Keystone): Invalid Bug description: Token based authentication is not supported with PKI due to bug in: https://github.com/openstack/keystone/blob/stable/havana/keystone/token/providers/pki.py from keystone.token.providers import uuid class Provider(uuid.Provider): Should be: from keystone.token.providers import pki class Provider(pki.Provider): To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1301141/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1291366] [NEW] documentation should advice against using pki_setup and ssl_setup
Public bug reported: Both of these tools generate Self-signed CA certificates. As such, they are only appropriate for development deployments, and should be treated as such. While sites with mature PKI policies would recognize this, that majority of people new to Open Stack are not PKI experts, and are using the provided tools. The http://docs.openstack.org/developer/keystone/configuration.html #certificates-for-pki should state this clearly. ** Affects: keystone Importance: Undecided Assignee: Adam Young (ayoung) Status: New ** Changed in: keystone Assignee: (unassigned) = Adam Young (ayoung) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1291366 Title: documentation should advice against using pki_setup and ssl_setup Status in OpenStack Identity (Keystone): New Bug description: Both of these tools generate Self-signed CA certificates. As such, they are only appropriate for development deployments, and should be treated as such. While sites with mature PKI policies would recognize this, that majority of people new to Open Stack are not PKI experts, and are using the provided tools. The http://docs.openstack.org/developer/keystone/configuration.html #certificates-for-pki should state this clearly. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1291366/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1291423] [NEW] revocation events sync slows responses to all authenticated calls
Public bug reported: There is a noticable lag when doing multiple calls to Keystone. The server shows in the log: KVS lock acquired for: os-revoke-events acquire /opt/stack/keystone/keystone/common/kvs/core.py:375 Putting the following delay in mitigates it significantly delta = datetime.timedelta(seconds=1) if self._last_fetch and self._last_fetch timeutils.utcnow() + delta: return ** Affects: keystone 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/1291423 Title: revocation events sync slows responses to all authenticated calls Status in OpenStack Identity (Keystone): New Bug description: There is a noticable lag when doing multiple calls to Keystone. The server shows in the log: KVS lock acquired for: os-revoke-events acquire /opt/stack/keystone/keystone/common/kvs/core.py:375 Putting the following delay in mitigates it significantly delta = datetime.timedelta(seconds=1) if self._last_fetch and self._last_fetch timeutils.utcnow() + delta: return To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1291423/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
