Re: [openstack-dev] [Tripleo] X509 Management

2016-06-21 Thread Juan Antonio Osorio 
On Tue, Jun 21, 2016 at 10:51 PM, Adam Young  wrote:

> On 06/21/2016 02:42 PM, Juan Antonio Osorio wrote:
>
> Adam, this is pretty much the proposal for TLS for the internal services
> (which you were added already as a reviewer for the spec)
> https://review.openstack.org/#/c/282307/
> The services in the overcloud fetching their certificates via certmonger
> is actually work in progress, which you could review here:
> https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
> Only thing is that currently this approach assumes FreeIPA, so the nodes
> need to be registered beforehand (and then trigger self-enrollment via some
> hooks).
> Also, the spec that I'm pointing to doesn't require the CA to be the in
> undercloud and it could be another node. But hey, if we could deploy Anchor
> on the Undercloud, then that could be used, so we wouldn't need another
> node for this means.
>
>
>
> Yes, I was basing my proposal her around your work.  I want there to be
> something guaranteed for Certmonger to talk to, and I realize that Heat can
> probably play that role.
>
> Anchor might also be viable here, I just don't want to force it as a
> dependency.  We are talking the selfsigned use case here, so it should be
> minimal overhead.
>

 I think it's a better idea to have Anchor as a dependency than try to brew
CA functionality into Heat via os-*-config. Maybe a Heat person can answer
this? Then for more complex use-cases we can use FreeIPA. Do we have Anchor
packetized in RDO?

>
> Anyway, in each of the service's profiles (the puppet manifests) I'm
> setting up the tracking of the certificates with the certmonger's puppet
> manifest.
>
> BR
>
> On Tue, Jun 21, 2016 at 5:39 PM, Adam Young  wrote:
>
>> When deploying the overcloud with TLS, the current "no additional
>> technology" approach is to use opensssl and self signed.  While this works
>> for a Proof of concept, it does not make sense if the users need to access
>> the resources from remote systems.
>>
>> It seems to me that the undercloud, as the system of record for deploying
>> the overcloud, should be responsible for centralizing the signing of
>> certificates.
>>
>> When deploying a service, the puppet module sure trigger a getcert call,
>> which registers the cert with  Certmonger.  Certmonger is responsible for
>> making sure the CSR gets to the signing authority, and fetching the cert.
>>
>> Certmonger works via helper apps.  While there is currently a "self
>> signed" helper, this does not do much if two or more systems need to have
>> the same CA sign their certs.
>>
>> It would be fairly simple to write a certmonger helper program that sends
>> a CSR from a controller or compute node to the undercloud, has the Heat
>> instance on the undercloud validate the request, and then pass it on to the
>> signing application.
>>
>> I'm not really too clear on how callbacks are  done from the
>> os-collect-config processes to Heat, but I am guessing it is some form of
>> Rest API that could be reused for this work flow?
>>
>>
>> I would see this as the lowest level of deployment.  We can make use of
>> Anchor or Dogtag helper apps already.  This might also prove a decent
>> middleground for people that need an automated approach to tie in with a
>> third party CA, where they need some confirmation from the deployment
>> process that the data in the CSR is valid and should be signed.
>>
>> __
>> 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
>>
>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> 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
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
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] [Tripleo] X509 Management

2016-06-21 Thread Adam Young 

On 06/21/2016 02:42 PM, Juan Antonio Osorio wrote:
Adam, this is pretty much the proposal for TLS for the internal 
services (which you were added already as a reviewer for the spec) 
https://review.openstack.org/#/c/282307/
The services in the overcloud fetching their certificates via 
certmonger is actually work in progress, which you could review here: 
https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
Only thing is that currently this approach assumes FreeIPA, so the 
nodes need to be registered beforehand (and then trigger 
self-enrollment via some hooks).
Also, the spec that I'm pointing to doesn't require the CA to be the 
in undercloud and it could be another node. But hey, if we could 
deploy Anchor on the Undercloud, then that could be used, so we 
wouldn't need another node for this means.



Yes, I was basing my proposal her around your work.  I want there to be 
something guaranteed for Certmonger to talk to, and I realize that Heat 
can probably play that role.


Anchor might also be viable here, I just don't want to force it as a 
dependency.  We are talking the selfsigned use case here, so it should 
be minimal overhead.


Anyway, in each of the service's profiles (the puppet manifests) I'm 
setting up the tracking of the certificates with the certmonger's 
puppet manifest.


BR

On Tue, Jun 21, 2016 at 5:39 PM, Adam Young > wrote:


When deploying the overcloud with TLS, the current "no additional
technology" approach is to use opensssl and self signed. While
this works for a Proof of concept, it does not make sense if the
users need to access the resources from remote systems.

It seems to me that the undercloud, as the system of record for
deploying the overcloud, should be responsible for centralizing
the signing of certificates.

When deploying a service, the puppet module sure trigger a getcert
call, which registers the cert with  Certmonger. Certmonger is
responsible for making sure the CSR gets to the signing authority,
and fetching the cert.

Certmonger works via helper apps.  While there is currently a
"self signed" helper, this does not do much if two or more systems
need to have the same CA sign their certs.

It would be fairly simple to write a certmonger helper program
that sends a CSR from a controller or compute node to the
undercloud, has the Heat instance on the undercloud validate the
request, and then pass it on to the signing application.

I'm not really too clear on how callbacks are  done from the
os-collect-config processes to Heat, but I am guessing it is some
form of Rest API that could be reused for this work flow?


I would see this as the lowest level of deployment.  We can make
use of Anchor or Dogtag helper apps already.  This might also
prove a decent middleground for people that need an automated
approach to tie in with a third party CA, where they need some
confirmation from the deployment process that the data in the CSR
is valid and should be signed.

__
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




--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com 



__
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



__
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] [Tripleo] X509 Management

2016-06-21 Thread Juan Antonio Osorio 
Adam, this is pretty much the proposal for TLS for the internal services
(which you were added already as a reviewer for the spec)
https://review.openstack.org/#/c/282307/
The services in the overcloud fetching their certificates via certmonger is
actually work in progress, which you could review here:
https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
Only thing is that currently this approach assumes FreeIPA, so the nodes
need to be registered beforehand (and then trigger self-enrollment via some
hooks).
Also, the spec that I'm pointing to doesn't require the CA to be the in
undercloud and it could be another node. But hey, if we could deploy Anchor
on the Undercloud, then that could be used, so we wouldn't need another
node for this means.

Anyway, in each of the service's profiles (the puppet manifests) I'm
setting up the tracking of the certificates with the certmonger's puppet
manifest.

BR

On Tue, Jun 21, 2016 at 5:39 PM, Adam Young  wrote:

> When deploying the overcloud with TLS, the current "no additional
> technology" approach is to use opensssl and self signed.  While this works
> for a Proof of concept, it does not make sense if the users need to access
> the resources from remote systems.
>
> It seems to me that the undercloud, as the system of record for deploying
> the overcloud, should be responsible for centralizing the signing of
> certificates.
>
> When deploying a service, the puppet module sure trigger a getcert call,
> which registers the cert with  Certmonger.  Certmonger is responsible for
> making sure the CSR gets to the signing authority, and fetching the cert.
>
> Certmonger works via helper apps.  While there is currently a "self
> signed" helper, this does not do much if two or more systems need to have
> the same CA sign their certs.
>
> It would be fairly simple to write a certmonger helper program that sends
> a CSR from a controller or compute node to the undercloud, has the Heat
> instance on the undercloud validate the request, and then pass it on to the
> signing application.
>
> I'm not really too clear on how callbacks are  done from the
> os-collect-config processes to Heat, but I am guessing it is some form of
> Rest API that could be reused for this work flow?
>
>
> I would see this as the lowest level of deployment.  We can make use of
> Anchor or Dogtag helper apps already.  This might also prove a decent
> middleground for people that need an automated approach to tie in with a
> third party CA, where they need some confirmation from the deployment
> process that the data in the CSR is valid and should be signed.
>
> __
> 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
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
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] [Tripleo] X509 Management

2016-06-21 Thread Adam Young 

On 06/21/2016 11:26 AM, John Dennis wrote:

On 06/21/2016 10:55 AM, Ian Cordasco wrote:

-Original Message-
From: Adam Young 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: June 21, 2016 at 09:40:39
To: OpenStack Development Mailing List 


Subject:  [openstack-dev] [Tripleo] X509 Management


When deploying the overcloud with TLS, the current "no additional
technology" approach is to use opensssl and self signed. While this
works for a Proof of concept, it does not make sense if the users need
to access the resources from remote systems.

It seems to me that the undercloud, as the system of record for
deploying the overcloud, should be responsible for centralizing the
signing of certificates.

When deploying a service, the puppet module sure trigger a getcert 
call,

which registers the cert with Certmonger. Certmonger is responsible
for making sure the CSR gets to the signing authority, and fetching the
cert.

Certmonger works via helper apps. While there is currently a "self
signed" helper, this does not do much if two or more systems need to
have the same CA sign their certs.

It would be fairly simple to write a certmonger helper program that
sends a CSR from a controller or compute node to the undercloud, has 
the

Heat instance on the undercloud validate the request, and then pass it
on to the signing application.

I'm not really too clear on how callbacks are done from the
os-collect-config processes to Heat, but I am guessing it is some form
of Rest API that could be reused for this work flow?


I would see this as the lowest level of deployment. We can make use of
Anchor or Dogtag helper apps already. This might also prove a decent
middleground for people that need an automated approach to tie in 
with a

third party CA, where they need some confirmation from the deployment
process that the data in the CSR is valid and should be signed.


I'm not familiar with TripleO or it's use of puppet, but I would
strongly advocate for Anchor (or DogTag) to be the recommended
solution. OpenStack Ansible has found it a little bit of an annoyance
to generate and distribute self-signed certificates.


Ah, but the idea is that certmonger is a front to whatever CA you 
chose to use, it provides a consistent interface to a range of CA's as 
well as providing functionality not present in most CA's, for instance 
the ability detect when certs need renewal etc. So the idea would be 
certmonger+Dogtag or certmongner+Anchor, or certmonger+XXX


Exactly.  This allows the interface from Tripleo to be the same 
regardless of the CA.



I am looking for guidance from the Tripleo/Heat team on how to structure 
the certmonger helper app.



__
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] [Tripleo] X509 Management

2016-06-21 Thread Ian Cordasco 
-Original Message-
From: John Dennis 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: June 21, 2016 at 10:28:22
To: OpenStack Development Mailing List (not for usage questions) 
, Adam Young 
Subject:  Re: [openstack-dev] [Tripleo] X509 Management

> On 06/21/2016 10:55 AM, Ian Cordasco wrote:
> > -Original Message-
> > From: Adam Young  
> > Reply: OpenStack Development Mailing List (not for usage questions)
> >  
> > Date: June 21, 2016 at 09:40:39
> > To: OpenStack Development Mailing List  
> > Subject: [openstack-dev] [Tripleo] X509 Management
> >
> >> When deploying the overcloud with TLS, the current "no additional
> >> technology" approach is to use opensssl and self signed. While this
> >> works for a Proof of concept, it does not make sense if the users need
> >> to access the resources from remote systems.
> >>
> >> It seems to me that the undercloud, as the system of record for
> >> deploying the overcloud, should be responsible for centralizing the
> >> signing of certificates.
> >>
> >> When deploying a service, the puppet module sure trigger a getcert call,
> >> which registers the cert with Certmonger. Certmonger is responsible
> >> for making sure the CSR gets to the signing authority, and fetching the
> >> cert.
> >>
> >> Certmonger works via helper apps. While there is currently a "self
> >> signed" helper, this does not do much if two or more systems need to
> >> have the same CA sign their certs.
> >>
> >> It would be fairly simple to write a certmonger helper program that
> >> sends a CSR from a controller or compute node to the undercloud, has the
> >> Heat instance on the undercloud validate the request, and then pass it
> >> on to the signing application.
> >>
> >> I'm not really too clear on how callbacks are done from the
> >> os-collect-config processes to Heat, but I am guessing it is some form
> >> of Rest API that could be reused for this work flow?
> >>
> >>
> >> I would see this as the lowest level of deployment. We can make use of
> >> Anchor or Dogtag helper apps already. This might also prove a decent
> >> middleground for people that need an automated approach to tie in with a
> >> third party CA, where they need some confirmation from the deployment
> >> process that the data in the CSR is valid and should be signed.
> >
> > I'm not familiar with TripleO or it's use of puppet, but I would
> > strongly advocate for Anchor (or DogTag) to be the recommended
> > solution. OpenStack Ansible has found it a little bit of an annoyance
> > to generate and distribute self-signed certificates.
>  
> Ah, but the idea is that certmonger is a front to whatever CA you chose
> to use, it provides a consistent interface to a range of CA's as well as
> providing functionality not present in most CA's, for instance the
> ability detect when certs need renewal etc. So the idea would be
> certmonger+Dogtag or certmongner+Anchor, or certmonger+XXX

I didn't get that. *Starts thinking of suggesting OSA adopting certmonger*

--  
Ian Cordasco


__
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] [Tripleo] X509 Management

2016-06-21 Thread John Dennis 

On 06/21/2016 10:55 AM, Ian Cordasco wrote:

-Original Message-
From: Adam Young 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: June 21, 2016 at 09:40:39
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [Tripleo] X509 Management


When deploying the overcloud with TLS, the current "no additional
technology" approach is to use opensssl and self signed. While this
works for a Proof of concept, it does not make sense if the users need
to access the resources from remote systems.

It seems to me that the undercloud, as the system of record for
deploying the overcloud, should be responsible for centralizing the
signing of certificates.

When deploying a service, the puppet module sure trigger a getcert call,
which registers the cert with Certmonger. Certmonger is responsible
for making sure the CSR gets to the signing authority, and fetching the
cert.

Certmonger works via helper apps. While there is currently a "self
signed" helper, this does not do much if two or more systems need to
have the same CA sign their certs.

It would be fairly simple to write a certmonger helper program that
sends a CSR from a controller or compute node to the undercloud, has the
Heat instance on the undercloud validate the request, and then pass it
on to the signing application.

I'm not really too clear on how callbacks are done from the
os-collect-config processes to Heat, but I am guessing it is some form
of Rest API that could be reused for this work flow?


I would see this as the lowest level of deployment. We can make use of
Anchor or Dogtag helper apps already. This might also prove a decent
middleground for people that need an automated approach to tie in with a
third party CA, where they need some confirmation from the deployment
process that the data in the CSR is valid and should be signed.


I'm not familiar with TripleO or it's use of puppet, but I would
strongly advocate for Anchor (or DogTag) to be the recommended
solution. OpenStack Ansible has found it a little bit of an annoyance
to generate and distribute self-signed certificates.


Ah, but the idea is that certmonger is a front to whatever CA you chose 
to use, it provides a consistent interface to a range of CA's as well as 
providing functionality not present in most CA's, for instance the 
ability detect when certs need renewal etc. So the idea would be 
certmonger+Dogtag or certmongner+Anchor, or certmonger+XXX

--
John

__
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] [Tripleo] X509 Management

2016-06-21 Thread Ian Cordasco 
-Original Message-
From: Adam Young 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: June 21, 2016 at 09:40:39
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [Tripleo] X509 Management

> When deploying the overcloud with TLS, the current "no additional
> technology" approach is to use opensssl and self signed. While this
> works for a Proof of concept, it does not make sense if the users need
> to access the resources from remote systems.
>
> It seems to me that the undercloud, as the system of record for
> deploying the overcloud, should be responsible for centralizing the
> signing of certificates.
>
> When deploying a service, the puppet module sure trigger a getcert call,
> which registers the cert with Certmonger. Certmonger is responsible
> for making sure the CSR gets to the signing authority, and fetching the
> cert.
>
> Certmonger works via helper apps. While there is currently a "self
> signed" helper, this does not do much if two or more systems need to
> have the same CA sign their certs.
>
> It would be fairly simple to write a certmonger helper program that
> sends a CSR from a controller or compute node to the undercloud, has the
> Heat instance on the undercloud validate the request, and then pass it
> on to the signing application.
>
> I'm not really too clear on how callbacks are done from the
> os-collect-config processes to Heat, but I am guessing it is some form
> of Rest API that could be reused for this work flow?
>
>
> I would see this as the lowest level of deployment. We can make use of
> Anchor or Dogtag helper apps already. This might also prove a decent
> middleground for people that need an automated approach to tie in with a
> third party CA, where they need some confirmation from the deployment
> process that the data in the CSR is valid and should be signed.

I'm not familiar with TripleO or it's use of puppet, but I would
strongly advocate for Anchor (or DogTag) to be the recommended
solution. OpenStack Ansible has found it a little bit of an annoyance
to generate and distribute self-signed certificates.

--
Ian Cordasco

__
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

[openstack-dev] [Tripleo] X509 Management

2016-06-21 Thread Adam Young 
When deploying the overcloud with TLS, the current "no additional 
technology" approach is to use opensssl and self signed.  While this 
works for a Proof of concept, it does not make sense if the users need 
to access the resources from remote systems.


It seems to me that the undercloud, as the system of record for 
deploying the overcloud, should be responsible for centralizing the 
signing of certificates.


When deploying a service, the puppet module sure trigger a getcert call, 
which registers the cert with  Certmonger.  Certmonger is responsible 
for making sure the CSR gets to the signing authority, and fetching the 
cert.


Certmonger works via helper apps.  While there is currently a "self 
signed" helper, this does not do much if two or more systems need to 
have the same CA sign their certs.


It would be fairly simple to write a certmonger helper program that 
sends a CSR from a controller or compute node to the undercloud, has the 
Heat instance on the undercloud validate the request, and then pass it 
on to the signing application.


I'm not really too clear on how callbacks are  done from the 
os-collect-config processes to Heat, but I am guessing it is some form 
of Rest API that could be reused for this work flow?



I would see this as the lowest level of deployment.  We can make use of 
Anchor or Dogtag helper apps already.  This might also prove a decent 
middleground for people that need an automated approach to tie in with a 
third party CA, where they need some confirmation from the deployment 
process that the data in the CSR is valid and should be signed.


__
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