[keystone][osc]Strange behaviour of OSC in keystone MFA context
adriant at catalystcloud.nz
Tue Feb 2 00:43:01 UTC 2021
*puts up hand*
You can blame me for this. When I implemented this I didn't (and still
don't) fully understand how the loading stuff works in Keystoneauth and
how it works with other things like OSC. I was more focused on getting
the direct auth/session side working because the loading stuff isn't
that useful in OSC really (see below why).
If anyone does know the loader side of keystoneauth better please chime
in and save me from making too much of a fool of myself!
I think adding `.split(',')` is probably enough, but you'd want to also
update the help text clarify that the option is a 'comma separated list'.
The biggest issue, and why this area never got much testing, is because
it is effectively useless since you'd have to supply your MFA values
EVERY command. Imagine how awful that would be for TOTP. The whole point
of the MFA process in keystone with auth-receipt was a dynamic
interactive login. Supplying the MFA upfront isn't that useful.
What the OSC really needs is a `login` command, that goes through a
login process using the auth-receipts workflow from keystone (asks for
password/totp) and sets some sort of state file. We can't set the
environment variables of the parent shell process, so we'd have to go
with a state/session file. But to avoid it clashing with other state
files and terminal sessions we'd need some way to tag them by the parent
process ID so you can login to more than one cloud/project/user/etc
across multiple terminals.
In addition it would be really nice if the OSC had some way of reusing a
scoped token/catalog rather than having to fetch it every time, but I
feel that would have to include changes in Keystoneauth to supply it
some cached data which tells it to not attempt to reauthenticate but
rather trust the catalog/token supplied (does keystoneauth support
that?). Because that reauth every command via Keystoneauth is actually
what often takes longer than the actual API calls... We can also just
throw catalog into that state/session file as json/yaml.
On 29/01/21 7:03 am, Stephen Finucane wrote:
> The definition for those opts can be found at . As Sean thought it might be,
> that is using the default type defined in the parent 'Opt' class of 'str' .
> We don't expose argparse's 'action' parameter that would allow us to use the
> 'append' action, so you'd have to fix this by parsing whatever the user provided
> after the fact. I suspect you could resolve the immediate issue by changing this
> line  from:
> self._methods = kwargs['auth_methods']
> self._methods = kwargs['auth_methods'].split(',')
> However, I assume there's likely more to this issue. I don't have an environment
> to hand to validate this fix, unfortunately.
> If you do manage to test that change and it works, I'd be happy to help you in
> getting a patch proposed to 'keystoneauth'.
> Hope this helps,
>  https://github.com/openstack/keystoneauth/blob/4.3.0/keystoneauth1/loading/_plugins/identity/v3.py#L316-L330
>  https://github.com/openstack/keystoneauth/blob/4.3.0/keystoneauth1/loading/opts.py#L65
>  https://github.com/openstack/keystoneauth/blob/4.3.0/keystoneauth1/loading/_plugins/identity/v3.py#L338
More information about the openstack-discuss