Open Stack

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

-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150504/bcf49f69/attachment.pgp>