Open Stack

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.

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)


> 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.


>> 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.


>>> 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.

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.


>> 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?


>> 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.

-- 
Mathieu