Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
We also run all masterless/puppet apply. And we just populate a bare bones keystone.conf on any box that does not have keystone installed, but Puppet needs to be able to create keystone resources. Also agreed on avoiding puppetdb, for the same reasons. (Something to note for those of us doing masterless today: there are plans from Puppet to move more of the manifest compiling functionality to run only in the puppet master process. So at some point, it’s likely that masterless setups may not be possible.) Mike 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? I'm not in favor of having exported resources because it requires PuppetDB, and a lot of people try to avoid that. For now, we've been able to setup all OpenStack without PuppetDB in TripleO and in some other installers, we might want to keep this benefit. +100 We're looking at using these puppet modules in a bit, but we're also a few steps away from getting rid of our puppetmaster and moving to a completely puppet apply based workflow. I would be double-plus sad-panda if we were not able to use the openstack puppet modules to do openstack because they'd been done in such as way as to require a puppetmaster or puppetdb. 100% agree. Even if you had a puppetmaster and puppetdb, you would still end up in this eventual consistency dance of puppet runs. __ 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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
On Wed, May 6, 2015 at 4:26 PM, Mike Dorman mdor...@godaddy.com wrote: We also run all masterless/puppet apply. And we just populate a bare bones keystone.conf on any box that does not have keystone installed, but Puppet needs to be able to create keystone resources. Also agreed on avoiding puppetdb, for the same reasons. (Something to note for those of us doing masterless today: there are plans from Puppet to move more of the manifest compiling functionality to run only in the puppet master process. So at some point, it’s likely that masterless setups may not be possible.) I don't think that's true. I think making sure puppet apply works is a priority for them, just the implementation as they move to a C++-based agent has yet to be figured out. Colleen Mike __ 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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
Cool, fair enough. Pretty glad to hear that actually! From: Colleen Murphy Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Wednesday, May 6, 2015 at 5:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials? On Wed, May 6, 2015 at 4:26 PM, Mike Dorman mdor...@godaddy.commailto:mdor...@godaddy.com wrote: We also run all masterless/puppet apply. And we just populate a bare bones keystone.conf on any box that does not have keystone installed, but Puppet needs to be able to create keystone resources. Also agreed on avoiding puppetdb, for the same reasons. (Something to note for those of us doing masterless today: there are plans from Puppet to move more of the manifest compiling functionality to run only in the puppet master process. So at some point, it’s likely that masterless setups may not be possible.) I don't think that's true. I think making sure puppet apply works is a priority for them, just the implementation as they move to a C++-based agent has yet to be figured out. Colleen Mike __ 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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
On 05/04/2015 10:37 PM, Rich Megginson wrote: 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 . . poof, and the devil appears. OK, the Keystone setup info is three distinct things: 1. You you are (username and password) 2. Where you start the process (auth_url) 3. Scope. (project) Both 1 and 3 are further namespace scoped by domain; Passwords are Bad. BADBADBAD. In Liberty, we have a work in progress to do tokenless operations using X509 based certificates. https://review.openstack.org/#/c/156870/ Ideally we would do something like this. For those of you that hate X509 (I know you are out there seething) we don't have a naked SSH Key based way to authenticate to Keystone. Sorry. We also Have Kerberos. I don't think I would want to put all of these in a vault. I could, however, see standardizing a config file setup for the clients where OS_AUTH_URL is defined at /etc/openrc.conf and the other values at ~/.openrc. One nice thing to add there would be the auth plugin used, and that would allow for Kerberos, X509, Password, or whatever. the cli could then take --conf= as an override. We might need to work on the file names. __ 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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
On 2015-05-05 1:25 AM, Monty Taylor wrote:
On 05/04/2015 08:47 PM, Emilien Macchi wrote:
On 05/04/2015 10:37 PM, Rich Megginson wrote:
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?
I'm not in favor of having exported resources because it requires
PuppetDB, and a lot of people try to avoid that. For now, we've
been able to setup all OpenStack without PuppetDB in TripleO and in
some other installers, we might want to keep this benefit.
+100
We're looking at using these puppet modules in a bit, but we're also a
few steps away from getting rid of our puppetmaster and moving to a
completely puppet apply based workflow. I would be double-plus
sad-panda if we were not able to use the openstack puppet modules to
do openstack because they'd been done in such as way as to require a
puppetmaster or puppetdb.
100% agree.
Even if you had a puppetmaster and puppetdb, you would still end up in
this eventual consistency dance of puppet runs.
--
Mathieu
__
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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
On 05/04/2015 10:37 PM, Rich Megginson wrote:
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?
I'm not in favor of having exported resources because it requires
PuppetDB, and a lot of people try to avoid that.
For now, we've been able to setup all OpenStack without PuppetDB in
TripleO and in some other installers, we might want to keep this benefit.
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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/04/2015 08:47 PM, Emilien Macchi wrote:
On 05/04/2015 10:37 PM, Rich Megginson wrote:
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?
I'm not in favor of having exported resources because it requires
PuppetDB, and a lot of people try to avoid that. For now, we've
been able to setup all OpenStack without PuppetDB in TripleO and in
some other installers, we might want to keep this benefit.
+100
We're looking at using these puppet modules in a bit, but we're also a
few steps away from getting rid of our puppetmaster and moving to a
completely puppet apply based workflow. I would be double-plus
sad-panda if we were not able to use the openstack puppet modules to
do openstack because they'd been done in such as way as to require a
puppetmaster or puppetdb.
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
[openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
I'm currently working on Keystone v3 support in the openstack puppet modules. 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? If so, how? How do you specify the authentication credentials? Do you use environment variables? If so, how are they specified? 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. 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? 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
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
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@domain1 wishes to get a token scoped to project1@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 __ 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
