Open Stack

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.  How are 
you passing those credentials?  As env. vars?  How?


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

>
>
>> For Keystone v3, in order to use v3 for authentication, and in order to
>> use the v3 identity api, there must be some way to specify the various
>> domains to use - the domain for the user, the domain for the project, or
>> the domain to get a domain scoped token.
> If I understand correctly, you have to scope the user to a domain and
> scope the project to a domain: user1 at domain1 wishes to get a token
> scoped to project1 at domain2 to manage resources within the project?

Correct.  So you need to have some way to specify the domain for the 
user and the domain for the project (or the domain for a domain scoped 
token which allows you to manage resources within a domain). These 
correspond to the openstack command line parameters:
http://www.jamielennox.net/blog/2015/02/17/loading-authentication-plugins/
./myapp --os-auth-plugin v3password --help

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

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

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

>
>
>> The goal is that all keystone domain scoped resources will eventually
>> require specifying a domain, but that will take quite a while and I
>> would like to provide an incremental upgrade path.
>