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@domain1 wishes to get a token
scoped to project1@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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
