Bug 1042191 - [RFE][heat]: A resource which generates random strings for passwords
Summary: [RFE][heat]: A resource which generates random strings for passwords
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-heat
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ga
: 5.0 (RHEL 7)
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/heat...
Whiteboard: upstream_milestone_icehouse-1 upstrea...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 21:19 UTC by RHOS Integration
Modified: 2014-09-08 05:42 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
This release adds a new Orchestration resource type called OS::Heat::RandomString. This resource type randomly generates a string that can be accessed via an attribute.
Clone Of:
Environment:
Last Closed: 2014-07-22 19:08:58 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 21:19:19 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/heat/+spec/random-string-resource.

Description:

Orchestrated services often need passwords and secrets to be propagated to multiple servers and set in configuration files or admin tools.

Currently the only practical way of doing this is to define template parameters for passwords and specify the password value on stack create. This can become a burden for complex templates with many services. For example these tripleo examples ask the user to generate 13 random passwords to pass to stack-create:
http://docs.openstack.org/developer/tripleo-incubator/devtest.html

This blueprint suggests creating a resource type OS::Heat::RandomString which randomly generates a string that can be accessed via an attribute. Properties can be set to specify what kind of string to generate, but defaults would aim to generate a string which is appropriate for service and user passwords that heat templates typically configure.

The resource's string will be stored in resource data and will be persisted by heat for the lifecycle of the stack. A future modification could be to store the string on a key server like Barbican.

Specification URL (additional information):

None

Comment 2 Stephen Gordon 2014-01-23 20:47:50 UTC
Moving to POST based on upstream status (Implemented).


Note You need to log in before you can comment on or make changes to this bug.