Open Stack

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


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


> 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? And is it reasonable to assume the domain
"default" will always be present?

Or is the question more related to the need to somehow override this
value in Puppet?


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


-- 
Mathieu