<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 15/03/14 02:33, Jiří Stránský wrote:<br>
    </div>
    <blockquote cite="mid:5323051A.3080904@redhat.com" type="cite">On
      12.3.2014 17:03, Jiří Stránský wrote:
      <br>
      <blockquote type="cite">
        <br>
        Thanks for all the replies everyone :)
        <br>
        <br>
        I'm leaning towards going the way Robert suggested on the review
        [1] -
        <br>
        upload pre-created signing cert, signing key and CA cert to
        controller
        <br>
        nodes using Heat. This seems like a much cleaner approach to
        <br>
        initializing overcloud than having to SSH into it, and it will
        solve
        <br>
        both problems i outlined in the initial e-mail.
        <br>
        <br>
        It creates another problem though - for simple (think PoC)
        deployments
        <br>
        without external CA we'll need to create the keys/certs
        <br>
        somehow/somewhere anyway :) It shouldn't be hard because it's
        already
        <br>
        implemented in keystone-manage pki_setup but we should figure
        out a way
        <br>
        to avoid copy-pasting the world. Maybe Tuskar calling pki_setup
        locally
        <br>
        and passing a parameter to pki_setup to override default
        location where
        <br>
        new keys/certs will be generated?
        <br>
        <br>
        <br>
        Thanks
        <br>
        <br>
        Jirka
        <br>
        <br>
        [1] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/78148/">https://review.openstack.org/#/c/78148/</a>
        <br>
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
      Here's an attempt at a brief summary:
      <br>
      <br>
      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].
      <br>
      <br>
      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?
      <br>
      <br>
      <br>
      Thank you
      <br>
      <br>
      Jirka
      <br>
      <br>
      [1]
<a class="moz-txt-link-freetext" href="https://github.com/openstack/tripleo-heat-templates/blob/0490dd665899d3265a72965aeaf3a342275f4328/overcloud-source.yaml">https://github.com/openstack/tripleo-heat-templates/blob/0490dd665899d3265a72965aeaf3a342275f4328/overcloud-source.yaml</a><br>
      [2]
<a class="moz-txt-link-freetext" href="http://docs.openstack.org/developer/keystone/configuration.html#install-external-signing-certificate">http://docs.openstack.org/developer/keystone/configuration.html#install-external-signing-certificate</a><br>
      [3]
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2014-March/029327.html">http://lists.openstack.org/pipermail/openstack-dev/2014-March/029327.html</a><br>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
      keystone_certs_config:<br>
        Type: OS::Heat::CloudConfig<br>
        Properties:<br>
          cloud_config:<br>
            write_files:<br>
            - path:
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    /etc/keystone/ssl/certs/signing_cert.pem<br>
              content: |<br>
                # You have 3 options for how to insert the content here:<br>
                # 1. inline the content<br>
                # 2. Same as 1, but automatically with your own template
    pre-processing logic<br>
                # 3. call {get_file: path/to/your/signing_cert.pem} but
    this only works for HOT syntax templates<br>
              permissions: '0600'<br>
    <br>
      keystone_init:<br>
        Type: OS::Heat::MultipartMime<br>
        Properties:<br>
          parts:<br>
          - subtype: cloud-config<br>
            config:<br>
              get_resource: keystone_certs_config<br>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      notCompute0:<br>
        Type: OS::Nova::Server<br>
        Properties:<br>
          user_data: {Ref: keystone_init}<br>
    <br>
    But it looks like you should just be using os-apply-config templates
    for all of the files in /etc/keystone/ssl/certs/<br>
    <br>
      notCompute0Config:<br>
        Type: AWS::AutoScaling::LaunchConfiguration<br>
        ...<br>
        Metadata:<br>
          ...<br>
          keystone:<br>
            signing_cert: |<br>
              # You have 3 options for how to insert the content here:<br>
              # 1. inline the content<br>
              # 2. Same as 1, but automatically with your own template
    pre-processing logic<br>
              # 3. call {get_file: path/to/your/signing_cert.pem} but
    this only works for HOT syntax templates<br>
    <br>
    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.<br>
  </body>
</html>