Restructure authentication for resource providers
Change-Id: I5fc1d77649d7fd11c5eb076096181b730d24f08e
This commit is contained in:
parent
cb72c6b697
commit
bff5e0d8e2
|
@ -20,6 +20,13 @@ Juno approved specs:
|
||||||
|
|
||||||
specs/juno/*
|
specs/juno/*
|
||||||
|
|
||||||
|
Kilo approved specs:
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
specs/kilo/*
|
||||||
|
|
||||||
==================
|
==================
|
||||||
Indices and tables
|
Indices and tables
|
||||||
|
|
|
@ -0,0 +1,199 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
==================================================================
|
||||||
|
Restructure authentication for OpenStack Puppet resource providers
|
||||||
|
==================================================================
|
||||||
|
|
||||||
|
Launchpad blueprint:
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/puppet-openstacklib/+spec/auth-restructure
|
||||||
|
|
||||||
|
Since OpenStack Puppet modules providers are managing their resources using
|
||||||
|
python-openstackclient (OSC), the 'openstack' CLI, to interface to OpenStack,
|
||||||
|
the mechanism which is used for holding authentication data is causing
|
||||||
|
unnecessary complexity and an inconsistent behavior for providers depending on
|
||||||
|
their context usage.
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
====================
|
||||||
|
|
||||||
|
The authentication data is currently stored as a type parameter ':auth'.
|
||||||
|
Having the authentication information as type parameter makes the credentials
|
||||||
|
available in an instance context but not in class context such as when a
|
||||||
|
resource is used in general context, for example in self.instances method.
|
||||||
|
|
||||||
|
This has several consequences:
|
||||||
|
|
||||||
|
1. It creates code duplication down the the road to work around the fact there
|
||||||
|
isn't authentication data provided in a general context, for example in keystone
|
||||||
|
provider:
|
||||||
|
|
||||||
|
* lib/puppet/provider/keystone_tenant/openstack.rb#L60
|
||||||
|
|
||||||
|
* lib/puppet/provider/keystone_tenant/openstack.rb#L73
|
||||||
|
|
||||||
|
When dealing with authentication, each provider has to duplicate every method
|
||||||
|
in regards of instance or class context.
|
||||||
|
|
||||||
|
2. Consequently, it appears that even in a general context, authentication
|
||||||
|
information has to be obtained from somewhere. Which means the authentication
|
||||||
|
mechanism needs to be revisited to have a consistent way of setting the
|
||||||
|
credentials in a consistent way no matter the context.
|
||||||
|
|
||||||
|
Also, independently of this problem but related to the authentication data, a
|
||||||
|
security issue came up when using command line options to pass credentials to
|
||||||
|
openstack command, for instance '--os_password=blah'. The risk is for a spawned
|
||||||
|
process to have the information displayed, i.e. with a 'PS' command.
|
||||||
|
|
||||||
|
And finally, a change in the way the credentials are obtained changes with step
|
||||||
|
2. which formalizes the default RC file to be used if needed:
|
||||||
|
|
||||||
|
1. Environment variables OS_* are used by default and will be overridden only if
|
||||||
|
defined below
|
||||||
|
|
||||||
|
2. If not enough credentials then OS_* variables defined in RC file to be used.
|
||||||
|
The default is located current user (per execution of Puppet) home directory:
|
||||||
|
$HOME/openrc
|
||||||
|
|
||||||
|
3. If authentication fails it's up to the provider to implement a failsafe to
|
||||||
|
use configuration file to find the credentials.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Therefore the need to review the architecture of handling the authentication
|
||||||
|
data while offering the same features to the OpenStack providers.
|
||||||
|
|
||||||
|
The fist change removes the :auth parameter from the types.
|
||||||
|
This is replaced with a combination of a auth module, and a credentials object.
|
||||||
|
|
||||||
|
Replacing the polymorphism approach used by providers inheriting from
|
||||||
|
Puppet::Provider::Openstack class by a module.
|
||||||
|
The authentication related methods are moved to the module.
|
||||||
|
|
||||||
|
The module creates an interface to the provider classes.
|
||||||
|
When a provider 'extend' the module, all the methods defined in the module
|
||||||
|
are available to the 'inheriting' class as class methods.
|
||||||
|
|
||||||
|
The authentication methods are acting at a sublevel, leaving the superclass
|
||||||
|
Puppet::Provider::Openstack to deal purely interfacing with openstack client.
|
||||||
|
|
||||||
|
The openstacklib structure is used as follow, using keystone provider cases:
|
||||||
|
|
||||||
|
class Puppet::Provider::Openstack
|
||||||
|
end
|
||||||
|
|
||||||
|
class Puppet::Provider::Keystone < Puppet::Provider::Openstack
|
||||||
|
end
|
||||||
|
|
||||||
|
class Puppet::Provider::Keystone_tenant < Puppet::Provider::Keystone
|
||||||
|
end
|
||||||
|
|
||||||
|
The module is extended by the provider intermediate class, for instance
|
||||||
|
class Puppet::Provider::Keystone < Puppet::Provider::Openstack
|
||||||
|
extend Puppet::Provider::Openstack::Auth
|
||||||
|
end
|
||||||
|
|
||||||
|
Secondly a credentials class Puppet::Provider::Openstack::Credentials
|
||||||
|
makes manipulating the authentication data not only easier but allows a class
|
||||||
|
instance variable @credentials to hold the information into a dedicated object.
|
||||||
|
|
||||||
|
To address the security issue point:
|
||||||
|
Credentials passed on a CLI must be forbidden in order to not be visible via PS
|
||||||
|
commands.
|
||||||
|
|
||||||
|
This is enforced by using of `withenv` method from Puppet Util library could help:
|
||||||
|
https://github.com/puppetlabs/puppet/blob/3.0.0/lib/puppet/util.rb#L39-L51
|
||||||
|
|
||||||
|
Note:
|
||||||
|
Although using ENV instead of CLI parameters doesn't remove issues such as:
|
||||||
|
"puppet resource keystone_user foo email=foo@example.com password=test"
|
||||||
|
In order to avoid the above, the related provider type API would have to be
|
||||||
|
changed as well.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
This is an alternative way to the existing solution, other was have not been
|
||||||
|
envisaged so far.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
The goal of this effort is: no data model impact. Existing manifests should
|
||||||
|
continue to work as before.
|
||||||
|
|
||||||
|
|
||||||
|
Module API impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None other than what has been already mentioned.
|
||||||
|
|
||||||
|
End user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
There should be no mandatory end user impact. Existing manifests should
|
||||||
|
continue to work exactly as before.
|
||||||
|
|
||||||
|
Operations wanting use different authentication should be able to provide it.
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
The `request` method and helper methods used by it should cache the contents of
|
||||||
|
files instead of opening/reading/parsing/closing every time.
|
||||||
|
|
||||||
|
|
||||||
|
Deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None other than what has been already mentioned.
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
gilles@redhat.com (IRC nick gildub)
|
||||||
|
|
||||||
|
Other contributors:
|
||||||
|
rmeggins (IRC nick richm)
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
* Implement the code described in the "Module API impact" section.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
Write tests for the new beaker CI test framework.
|
||||||
|
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
The README.md and the examples in the examples directory will be updated.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
Openstack client: http://docs.openstack.org/developer/python-openstackclient/
|
||||||
|
Openstack client config file: http://docs.openstack.org/developer/python-openstackclient/configuration.html#configuration-files
|
Loading…
Reference in New Issue