Open Stack

On 16.3.2014 21:20, Steve Baker wrote:
> On 15/03/14 02:33, Jiří Stránský wrote:
>> On 12.3.2014 17:03, Jiří Stránský wrote:
>>>
>>> Thanks for all the replies everyone :)
>>>
>>> I'm leaning towards going the way Robert suggested on the review [1] -
>>> upload pre-created signing cert, signing key and CA cert to controller
>>> nodes using Heat. This seems like a much cleaner approach to
>>> initializing overcloud than having to SSH into it, and it will solve
>>> both problems i outlined in the initial e-mail.
>>>
>>> It creates another problem though - for simple (think PoC) deployments
>>> without external CA we'll need to create the keys/certs
>>> somehow/somewhere anyway :) It shouldn't be hard because it's already
>>> implemented in keystone-manage pki_setup but we should figure out a way
>>> to avoid copy-pasting the world. Maybe Tuskar calling pki_setup locally
>>> and passing a parameter to pki_setup to override default location where
>>> new keys/certs will be generated?
>>>
>>>
>>> Thanks
>>>
>>> Jirka
>>>
>>> [1] https://review.openstack.org/#/c/78148/
>>>
>>
>> I'm adding [Heat] to the subject. After some discussion on IRC it
>> seems that what we need to do with Heat is not totally straightforward.
>>
>> Here's an attempt at a brief summary:
>>
>> In TripleO we deploy OpenStack using Heat, the cloud is described in a
>> Heat template [1]. We want to externally generate and then upload 3
>> small binary files to the controller nodes (Keystone PKI key and
>> certificates [2]). We don't want to generate them in place or scp them
>> into the controller nodes, because that would require having ssh
>> access to the deployed controller nodes, which comes with drawbacks [3].
>>
>> It would be good if we could have the 3 binary files put into the
>> controller nodes as part of the Heat stack creation. Can we include
>> them in the template somehow? Or is there an alternative feasible
>> approach?
>>
>>
>> Thank you
>>
>> Jirka
>>
>> [1]
>> https://github.com/openstack/tripleo-heat-templates/blob/0490dd665899d3265a72965aeaf3a342275f4328/overcloud-source.yaml
>> [2]
>> http://docs.openstack.org/developer/keystone/configuration.html#install-external-signing-certificate
>> [3]
>> http://lists.openstack.org/pipermail/openstack-dev/2014-March/029327.html
>
> It looks like the cert files you want to transfer are all ascii rather
> than binary, which is good as we have yet to implement a way to attach
> binary data to a heat stack create call.
>
> One way to write out these files would be using cloud-config. The
> disadvantages of this is that it is boot-time config only, so those keys
> couldn't be updated with a stack update. You would also be consuming a
> decent proportion of your 16k user_data limit.
>
>    keystone_certs_config:
>      Type: OS::Heat::CloudConfig
>      Properties:
>        cloud_config:
>          write_files:
>          - path: /etc/keystone/ssl/certs/signing_cert.pem
>            content: |
>              # You have 3 options for how to insert the content here:
>              # 1. inline the content
>              # 2. Same as 1, but automatically with your own template
> pre-processing logic
>              # 3. call {get_file: path/to/your/signing_cert.pem} but this
> only works for HOT syntax templates
>            permissions: '0600'
>
>    keystone_init:
>      Type: OS::Heat::MultipartMime
>      Properties:
>        parts:
>        - subtype: cloud-config
>          config:
>            get_resource: keystone_certs_config
>    notCompute0:
>      Type: OS::Nova::Server
>      Properties:
>        user_data: {Ref: keystone_init}
>
> But it looks like you should just be using os-apply-config templates for
> all of the files in /etc/keystone/ssl/certs/
>
>    notCompute0Config:
>      Type: AWS::AutoScaling::LaunchConfiguration
>      ...
>      Metadata:
>        ...
>        keystone:
>          signing_cert: |
>            # You have 3 options for how to insert the content here:
>            # 1. inline the content
>            # 2. Same as 1, but automatically with your own template
> pre-processing logic
>            # 3. call {get_file: path/to/your/signing_cert.pem} but this
> only works for HOT syntax templates
>
> If the files really are binary then currently you'll have to encode to
> base64 before including the content in your templates, then have an
> os-refresh-config script to decode and write out the binary files.

Ah i don't know why i thought .pem files were binary. Thank you Steve, 
your reply is super helpful :)

Jirka