Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/04/2015 08:47 PM, Emilien Macchi wrote:
> 
> 
> On 05/04/2015 10:37 PM, Rich Megginson wrote:
>> On 05/04/2015 07:52 PM, Mathieu Gagné wrote:
>>> On 2015-05-04 9:15 PM, Rich Megginson wrote:
>>>> On 05/04/2015 06:03 PM, Mathieu Gagné wrote:
>>>>> On 2015-05-04 7:35 PM, Rich Megginson wrote:
>>>>>> The way authentication works with the Icehouse branch is
>>>>>> that puppet-keystone reads the admin_token and
>>>>>> admin_endpoint from /etc/keystone/keystone.conf and
>>>>>> passes these to the keystone command via the
>>>>>> OS_SERVICE_TOKEN env. var. and the --os-endpoint
>>>>>> argument, respectively.
>>>>>> 
>>>>>> This will not work on a node where Keystone is not
>>>>>> installed (unless you copy /etc/keystone/keystone.conf to
>>>>>> all of your nodes).
>>>>>> 
>>>>>> I am assuming there are admins/operators that have
>>>>>> actually deployed OpenStack using puppet on nodes where
>>>>>> Keystone is not installed?
>>>>> We are provisioning keystone resources from a privileged
>>>>> keystone node which accepts the admin_token. All other
>>>>> keystone servers has the admin_token_auth middleware
>>>>> removed for obvious security reasons.
>>>>> 
>>>>> 
>>>>>> If so, how?  How do you specify the authentication
>>>>>> credentials?  Do you use environment variables?  If so,
>>>>>> how are they specified?
>>>>> When provisioning resources other than Keystones ones, we
>>>>> use custom puppet resources and the credentials are passed
>>>>> as env variables to the exec command. (they are mainly
>>>>> based on exec resources)
>>>> I'm talking about the case where you are installing an
>>>> OpenStack service other than Keystone using puppet, and that
>>>> puppet code for that module needs to create some sort of
>>>> Keystone resource.
>>>> 
>>>> For example, install Glance on a node other than the Keystone
>>>> node. puppet-glance is going to call class
>>>> glance::keystone::auth, which will call
>>>> keystone::resource::service_identity, which will call
>>>> keystone_user { $name }.  The openstack provider used by
>>>> keystone_user is going to need Keystone admin credentials in
>>>> order to create the user.
>>> We "fixed" that part by not provisioning Keystone resources
>>> from Glance nodes but from Keystone nodes instead.
>>> 
>>> We do not allow our users to create users/groups/projects, only
>>> a user with the admin role can do it. So why would you want to
>>> store/use admin credentials on an unprivileged nodes such as
>>> Glance? IMO, the glance user shouldn't be able to
>>> create/edit/delete users/projects/endpoints, that's the
>>> keystone nodes' job.
>> 
>> Ok.  You don't need the Keystone "superuser" admin credentials on
>> the Glance node.
>> 
>> Is the puppet-glance code completely separable so that you can
>> call only glance::keystone::auth (or other classes that use
>> Keystone resources) from the Keystone node, and all of the other
>> puppet-glance code on the Glance node?  Does the same apply to
>> all of the other puppet modules?
>> 
>>> 
>>> If you do not wish to explicitly define Keystone resources for
>>> Glance on Keystone nodes but instead let Glance nodes manage
>>> their own resources, you could always use exported resources.
>>> 
>>> You let Glance nodes export their keystone resources and then
>>> you ask Keystone nodes to realize them where admin credentials
>>> are available. (I know some people don't really like exported
>>> resources for various reasons)
>> 
>> I'm not familiar with exported resources.  Is this a viable
>> option that has less impact than just requiring Keystone
>> resources to be realized on the Keystone node?
> 
> I'm not in favor of having exported resources because it requires 
> PuppetDB, and a lot of people try to avoid that. For now, we've
> been able to setup all OpenStack without PuppetDB in TripleO and in
> some other installers, we might want to keep this benefit.

+100

We're looking at using these puppet modules in a bit, but we're also a
few steps away from getting rid of our puppetmaster and moving to a
completely puppet apply based workflow. I would be double-plus
sad-panda if we were not able to use the openstack puppet modules to
do openstack because they'd been done in such as way as to require a
puppetmaster or puppetdb.

>>> 
>>> 
>>>> How are you passing those credentials?  As env. vars?  How?
>>> As stated, we use custom Puppet resources (defined types) which
>>> are mainly wrapper around exec. You can pass environment
>>> variable to exec through the environment parameter. I don't
>>> like it but that's how I did it ~2 years ago. I haven't changed
>>> it due to lack of need to change it. This might change soon
>>> with Keystone v3.
>> 
>> Ok.
>> 
>>> 
>>> 
>>>>> I'm starting to think about moving away from env variables
>>>>> and use a configuration file instead. I'm not sure yet
>>>>> about the implementation details but that's the main idea.
>>>> Is there a standard openrc location?  Could openrc be
>>>> extended to hold parameters such as the default domain to use
>>>> for Keystone resources? I'm not talking about OS_DOMAIN_NAME,
>>>> OS_USER_DOMAIN_NAME, etc. which are used for
>>>> _authentication_, not resource creation.
>>> I'm not aware of any "standard" openrc location other than
>>> ~/.openrc which needs to be sourced before running any
>>> OpenStack client commands.
>>> 
>>> I however understand what you mean. I do not have any idea on
>>> how I would implement it. I'm still hoping someday to be
>>> enlightened by a great solution.
>>> 
>>> I'm starting to think about some sort of credentials vault. You
>>> store credentials in it and you tell your resource to use that
>>> specific credentials. You then no longer need to pass around
>>> 6-7 variables/parameters.
>> 
>> I'm sure Adam Young has some ideas about this . . .
>> 
>>> 
>>> 
>>>>>> There is a similar issue when creating domain scoped
>>>>>> resources like users and projects.  As opposed to editing
>>>>>> dozens of manifests to add domain parameters to every
>>>>>> user and project (and the classes that call 
>>>>>> keystone_user/tenant, and the classes that call those
>>>>>> classes, etc.), is there some mechanism to specify a
>>>>>> default domain to use?  If not, what about using the same
>>>>>> mechanism used today to specify the Keystone 
>>>>>> credentials?
>>>>> I see there is support for a default domain in
>>>>> keystone.conf. You will find it defined by the
>>>>> identity/default_domain_id=default config value.
>>>>> 
>>>>> Is this value not usable?
>>>> It is usable, and will be used, _only on Keystone nodes_. If
>>>> you are on a node without Keystone, where will the default id
>>>> come from?
>>> As you probably know already, Puppet can't guess those default
>>> values, nor could Glance.
>>> 
>>> I'm suggesting to not provision keystone resources from nodes
>>> other than keystone themselves. It solves (or avoid) a lot of
>>> problems.
>> 
>> Yes, indeed.
>> 
>>> 
>>> I think we have to change the way we think about Keystone
>>> resources provisioning. I like to compare it to database
>>> provisioning:: You do not provision your database from the
>>> Glance nodes: you do it on your database node. Only the
>>> database node knows about the root password to create and
>>> provision database resources. It should be the same with 
>>> Keystone resources.
>> 
>> Ok.
>> 
>>> 
>>> 
>>>>> And is it reasonable to assume the domain "default" will
>>>>> always be present?
>>>> Yes, but that may not be the "default" domain.  Consider the
>>>> case where you may want to separate user accounts from
>>>> service "pseudo" accounts, by having them in separate
>>>> domains.
>>> I understand what you mean. However, won't the glance service 
>>> (glance.conf) be aware of which domain its service account
>>> lives in?
>> 
>> Yes.  I'm also working on puppet-glance to make it domain aware
>> with respect to authentication and resources.  You will be able
>> to specify the domain for the service account and the domain for
>> the service tenant.
>> 
>>> 
>>> 
>>>>> Or is the question more related to the need to somehow
>>>>> override this value in Puppet?
>>>> If there is a standard Puppet mechanism for being able to
>>>> provide global parameters, other than something like rc files
>>>> or environment variables, then yes.
>>> All I can think of is the "data bag" concept in Chef. It
>>> contains global variables which aren't "owned" by any recipes.
>>> 
>>> We might have to come up with a similar concept where
>>> credentials are stored and shared among all our modules.
>>> 
>> In light of your information, I don't know if that will be
>> necessary.
>> 
>> __________________________________________________________________________
>>
>> 
OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>> 
> 
> 
> __________________________________________________________________________
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVSFRFAAoJEDOQ22gEGhLwiT8QAJmLqBrDdAUvnhQKsoD5TOmS
Adup1Zs2k3sOHPb7MLG/R5Ookvx1iqvfX1BScZ+7TqZ18z2T16vp8v2xxS+6cVtz
/V5ov21l10WoZvDULF0CdU9+v9ERr9hPwYfK/OmLPTmD1mD2D6ZlJH9jdz9JL9H+
WAq4IlTOFV2CDhqGjOqb+aSRKEGA5m5B6Dcr0zFRpoY3fvAtwYZf571MPSCGhtxx
bs5C75ngPSC8zKBoI5FcR7GovWjHbWGhnWyB67ch3M5NrKx1gxN5tIvovQpc/SUP
y+XwQRWFBX6ab1LrGEfL6Hj2R4pZqvke6S0sNao6QB+ewYogqKs78cz+3aWQ2dAc
fy3nuElnicR2lp7qle6qYNJLQ8lAP1pWMajgd8R553MikmHpt7dCx3gYCM36b0tf
p41ygydCDxomA6DptQT9sJUCRV1daM4zHW5Z3pXX0/n1ZMdoqANPKCergjRHvkd8
tNYuY75CuWKdXfc1fxA6lvykvaMXeYuJOPLFSc2l5f6zHVQpY2WgxYtKtb/iyUAd
pHo7YB+2hRkAnTB45iS1aGd5+fDv2nVm7eX1mwVRCKYdMXhoRj1U/9frtCtb0ZaH
6o0RMgyQbQCi6fYp6+ZRrnTtevVZRHgGdj5k4zV0XM7eUsRauwmN6rEhHaBUhkdm
ajJ76CWKy4Jd+SPtzHOH
=hmlj
-----END PGP SIGNATURE-----