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?
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
