This changes the scope validation to occur after a token has already
been created.
Previous flow:
1. Validate authentication options.
2. Validate authorization options if the command requires a scope.
3. Create a token (using authentication + authorization options)
4. Run command.
This means that scope was being checked, even if a default scope was
applied in step 3 by Keystone.
New flow:
1. Validate authentication options.
2. Create token (using authentication + authorization options)
3 Validate authorization options if the command requires a scope and
the token is not scoped.
4. Run command.
Change-Id: Idae368a11249f425b14b891fc68b4176e2b3e981
Closes-Bug: 1592062
Use osc-lib directly for exceptions.
Leave openstackclient.common.exceptions for deprecation period.
Change-Id: Iea3e862302372e1b31ccd27f69db59b4953ca828
Currently OpenStackClient uses keystoneclient for authentication.
This change will update OpenStackClient to use keystoneauth for
authentication.
All dependant test have been updated.
Updating how auth_ref is set in the tests to use KSA fixtures had
some racy side-effects. The user_role_list tests failed when they
picked up an auth_ref that was a fixture. This exposed a weakness
in ListUserRole that needed to be fixed at the same time re
handling of unscoped tokens and options.
Change-Id: I4ddb2dbbb3bf2ab37494468eaf65cef9213a6e00
Closes-Bug: 1533369
Previously, if an AttributeError was raised in a plugin's make_client
method, the plugin simply wouldn't be an attribute of the ClientManager,
producing tracebacks like
Traceback (most recent call last):
File ".../openstackclient/shell.py", line 118, in run
ret_val = super(OpenStackShell, self).run(argv)
...
File ".../openstackclient/object/v1/container.py", line 150, in take_action
data = self.app.client_manager.object_store.container_list(
File ".../openstackclient/common/clientmanager.py", line 66, in __getattr__
raise AttributeError(name)
AttributeError: object_store
This made writing minimal third-party auth plugins difficult, as it
obliterated the original AttributeError.
Now, AttributeErrors that are raised during plugin initialization will
be re-raised as PluginAttributeErrors, and the original traceback will
be preserved. This gives much more useful information to plugin
developers, as in
Traceback (most recent call last):
File ".../openstackclient/shell.py", line 118, in run
ret_val = super(OpenStackShell, self).run(argv)
...
File ".../openstackclient/object/v1/container.py", line 150, in take_action
data = self.app.client_manager.object_store.container_list(
File ".../openstackclient/common/clientmanager.py", line 57, in __get__
err_val, err_tb)
File ".../openstackclient/common/clientmanager.py", line 51, in __get__
self._handle = self.factory(instance)
File ".../openstackclient/object/client.py", line 35, in make_client
interface=instance._interface,
File ".../openstackclient/common/clientmanager.py", line 258,
in get_endpoint_for_service_type
endpoint = self.auth_ref.service_catalog.url_for(
PluginAttributeError: 'NoneType' object has no attribute 'url_for'
Change-Id: I0eee7eba6eccc6d471a699a381185c4e76da10bd
Make scope check optional for the "token issue" command as unscoped token is
a valid Keystone V2/V3 API.
Change-Id: Ie1cded4dbfdafd3a78c0ebdf89e3f66762509930
Closes-Bug: #1543214
Move the network endpoint enablement checking from the 'server create'
command to the common client manager. This allows future network
commands to use either nova or neutron networking based on the cloud
environment.
This patch set also includes related unit test enhancements to the
common client manager to trigger authentication on the tests.
Change-Id: Ia37e81d4fb05a1e2fceb3e5d367bda769ab8e64b
Related-Bug: #1519511
Related-to: blueprint neutron-client
User should be able to specify the endpoint type through
a CLI optional argument/ENV variable setting. We will name this new
optional argument: --os-endpoint-type (Env: OS_ENDPOINT_TYPE) and
based on the value given, the service API will use that specific
endpoint type. Possible values: public, admin, internal.
DocImpact
Closes-Bug: #1454392
Change-Id: Ife3d4e46b44c0ddcd712b1130e27e362545a9a29
Recently oslo serialization has started to also include
python-msgpack. Since we were only using it for json support, we
should just use python's json support. Especially since it's only
used by our tests.
Change-Id: I0f8d939d6fca7608eaa3eea7ea4ca93296aaab3a
This adds a new option --os-cloud that allows the configuration values
for multiple clouds to be stored in a local file and selected with
a single option.
Internal option names have had 'os_' removed to be comptible with
the options returned from OpenStackConfig().get_one_cloud().
The config file is ~/.config/openstack/clouds.yaml:
Sample
------
clouds:
devstack:
auth:
auth_url: http://192.168.122.10:35357/
project_name: demo
username: demo
password: 0penstack
region_name: RegionOne
devstack:
auth:
auth_url: http://192.168.122.10:35357/
project_name: demo
username: demo
password: 0penstack
region_name: RegionOne
Co-Authored-By: Monty Taylor <mordred@inaugust.com>
Change-Id: I4939acf8067e44ffe06a2e26fc28f1adf8985b7d
Depends-On: I45e2550af58aee616ca168d20a557077beeab007
So we really weren't deferring the loading of client libs dadgummit,
do that for real where possible. This shaves a couple of tenths off
the static import times.
Also defer as much import-time procesing as possible. This is a little
ugly in api.auth but this also eliminates import of the auth plugins
until they are needed.
Change-Id: Ia11d4b9cf98231d37449103fc29101dc17afb009
The plugin detection at the top of openstackclient.api.auth did not
detect the plugins at the bottom of that file because, surprise,
they had not been declared yet so the entry points were ignored.
Move both plugin subclasses into openstackclient.api.auth_plugin.
Fix a problem with the password callback that was otherwise made
worse with this change.
Closes-Bug: 1428912
Change-Id: Idc3b72534071e0013c8922884a8bc14137509a0f
When we got picky with the auth arguments we broke using help without
any auth config supplied. This rearranges things a bit to do the argument
checking when the deferred auth request to Identity occurs so commands
that do not need auth have a chance to live short but useful lives.
Closes-Bug: #1399588
Change-Id: I8ceac491cf65e25eddb62ab2713f471fe686756d
If either of OS_USER_DOMAIN_ID or OS_USER_DOMAIN_NAME are present
then we don't tinker with anything. Otherwise, we should set
the USER_DOMAIN_ID to 'OS_DEFAULT_DOMAIN', as this provides a better UX,
since the end user doesn't have to specify these arguments.
Same logic applies for OS_PROJECT_DOMAIN_ID.
Closes-Bug: #1385338
Change-Id: I8a4034c16a1dd50d269f809abab8e960d5de20f7
Setting up auth options can be complicated, and we currently don't
do any checking before we build all our auth parameters to send off
to keystoneclient. We should do some basic checking to guide new
users.
Change-Id: I9c88f1c9637b3870c151952ecc797aaf65be271a
Closes-Bug: #1400531
User's don't know what a plugin is.
* Internally, os_auth_type and/or auth_type represents what the
user supplied.
* auth_plugin_name is the name of the selected plugin
* auth_plugin is the actual plugin object
Plugin selection process:
* if --os-auth-type is supplied:
* if it matches against an available plugin, done
* (if it can map to an availble plugin type, done; TODO in a followup)
* if --os-auth-type is not supplied:
* if --os-url and --os-token are supplied, select 'token_endpoint'
* if --os-username supplied, select identity_api_version + 'password'
* if --os-token supplied, select identity_api_version + 'token'
Change-Id: Ice4535214e311ebf924087cf77f6d84d76f5f3ee
Anything that needs a service catalog can get it directly from
auth_ref.service_catalog, no need to carry the extra attribute.
ClientManager.get_endpoint_for_service_type() reamins the proper
method to get an endpoint for clients that still need one directly.
Change-Id: I809091c9c71d08f29606d7fd8b500898ff2cb8ae
Clients that can use ksc Session don't need the old junk to
fake auth anymore:
* compute
* volume
Clients that still need to be fed credentials can pick directly
from the auth object in clientmanager. The _token attribute is
removed, the token can be retrieved from the auth object:
openstackclient/tests/common/test_clientmanager.py
This change will break any plugin that relies on getting a token
from instance._token. They should be updated to use the above, or
preferable, to use keystoneclient.session.Session to create its
HTTP interface object.
Change-Id: I877a29de97a42f85f12a14c274fc003e6fba5135
keystoneclient/openstack/common/jsonutils.py is removed in this patch
https://review.openstack.org/#/c/128454/
Now, we should use jsonutils in oslo.serialization package.
Change-Id: I7c8e8e6d5dffa85244368fd578616c9b19f4fd21
The ksc auth plugins do not have support for the original
token-endpoint (aka token flow) auth where the user supplies
a token (possibly the Keystone admin_token) and an API endpoint.
This is used for bootstrapping Keystone but also has other uses
when a scoped user token is provided.
The api.auth:TokenEndpoint class is required to provide the
same interface methods so all of the special-case code branches
to support token-endpoint can be removed.
Some additional cleanups related to ClientManager and creating
the Compute client also were done to streamline using sessions.
Change-Id: I1a6059afa845a591eff92567ca346c09010a93af
This patch allows the user to choose which authentication plugin
to use with the CLI. The arguments needed by the auth plugins are
automatically added to the argument parser. Some examples with
the currently available authentication plugins::
OS_USERNAME=admin OS_PROJECT_NAME=admin OS_AUTH_URL=http://keystone:5000/v2.0 \
OS_PASSWORD=admin openstack user list
OS_USERNAME=admin OS_PROJECT_DOMAIN_NAME=default OS_USER_DOMAIN_NAME=default \
OS_PROJECT_NAME=admin OS_AUTH_URL=http://keystone:5000/v3 OS_PASSWORD=admin \
OS_IDENTITY_API_VERSION=3 OS_AUTH_PLUGIN=v3password openstack project list
OS_TOKEN=1234 OS_URL=http://service_url:35357/v2.0 \
OS_IDENTITY_API_VERSION=2.0 openstack user list
The --os-auth-plugin option can be omitted; if so the CLI will attempt to
guess which plugin to use from the other options.
Change-Id: I330c20ddb8d96b3a4287c68b57c36c4a0f869669
Co-Authored-By: Florent Flament <florent.flament-ext@cloudwatt.com>
This replaces the restapi requests wrapper with the one from Keystone client so
we can take advantage of the auth plugins.
As a first step only the v2 and v3 token and password plugins are supported.
This maintainis no changes to the command options or environment variables.
The next steps will include reworking the other API client interfaces to
fully utilize the single auth session.
Blueprint: ksc-session-auth
Change-Id: I47ec63291e4c3cf36c8061299a4764f60b36ab89
This is step 1 toward using Keystone client's session.Session as the
primary session/requests interface in OSC.
* Move the session create into ClientManager and rename 'restapi' attribute to 'session'
* Set up ClientManager and session loggers
* Fix container and object command references to restapi/api
Change-Id: I013d81520b336c7a6422cd22c05d1d65655e64f8
There are several reasons for this. One is that the majority of
OpenStack packages behave this way. The second is that it makes writing
software that extends something easier to test (which is a clear usecase
for openstackclient) And third, tests/__init__.py implies a global
package named "tests" - which I'm pretty sure we're not providing.
Change-Id: Ic708ffd92aea78c2ffc1a8579af0587af4fca4ff
