Open Stack

(kicking this thread to the dev mailing list)

Thanks for starting this discussion on Juno work efforts, Nate.  This would be a good discussion to pick up at the 3pm CDT IRC meeting today as well. I've added some thoughts below as well.

I believe the plan is to finalize features and API changes in openstack/barbican for M3 (so Sept 4th). My understanding is that corresponding updates to the client library to accommodate these features could continue after that date. 

So getting finalized KMIP, Dogtag and HSM secret storage options shored up seems like a good goal. I think the last KMIP CR is Kaitlin's (kfarr) [1]. Paul's (reaperhulk) CR [2] fixes an issue with HSM interactions (and stevedore interaction in general...we should discuss at the IRC meeting today).

Removing the tenant-ID from the URLs seems good as well, per this Venkat's (tsv) CR [3].

Regarding the transport key feature, I would hope that we could get the client portion available before the final Juno release.

Adam (rm_work) is working on the Containers portion of the client library in CR [4].

Regarding certificate generation...

I'm hopeful we get can get the framework for certificate generation (based on blueprint [5]) in place by M3, but that might be aggressive. I'm hopeful the feature can include the ability to invoke a certificate plugin to generate a certificate via the orders interface for happy path flows (i.e. data is correct). This could be Ade's Dogtag plugin, and the Symantec plugin. 

Work to retrieve which certificate plugins are available would probably need to be done in K, as well as Ade's sub-CA feature.

Per that blueprint, it would also be nice to have a simple certificate event plugin (that just logs, I'm working on that now) and a simple retry loop using periodic tasks.

As Ade (alee) pointed out, Arvind's (atiwari) CR to add type/meta to the orders resource [6] is needed for follow on asymmetric and certificate generation workflows.  Some initial work on asymmetric generation is happening in Arvind's CR here: https://review.openstack.org/#/c/111412/


Misc...

I'm thinking Arun's (arunkant) Keystone eventing CR [7], and my (woodster) json-home Version resource CR [8] might slip to K, but again we should discuss this today.

Ade, I had thought the Dogtag Chef work was getting fleshed out, so it might be close now?

I'd like to remove the 'context' argument from the secret_store.py plugin interface before M3. 

We might want to consider adding plugin validation to our current hard-coded validators.py classes as well?



Is there anything else out there?

Thanks,
John

[1] = https://review.openstack.org/#/c/101582/
[2] = https://review.openstack.org/#/c/114341/
[3] = https://review.openstack.org/#/c/112149/
[4] = https://review.openstack.org/#/c/113393/
[5] = https://github.com/openstack/barbican-specs/blob/master/specs/juno/add-ssl-ca-support.rst
[6] = https://review.openstack.org/#/c/87405/
[7] = https://review.openstack.org/#/c/110817/
[8] = https://review.openstack.org/#/c/108163/

________________________________________
From: Ade Lee [alee at redhat.com]
Sent: Friday, August 15, 2014 12:16 PM
To: Reller, Nathan S.
Cc: Jarret Raim; John Wood; Coffman, Joel M.; Farr, Kaitlin M.; nkinder at redhat.com; akoneru at redhat.com
Subject: Re: Juno Home Stretch

On Fri, 2014-08-15 at 12:12 -0400, Reller, Nathan S. wrote:
> We are getting into the final weeks of Juno development, and I was
> wondering where we stand with status. I want to make sure we get in
> everything that we can, and I want to make sure I prioritize reviews or
> any other help that we can give appropriately.
>
> We have several Dogtag patches that were accepted. Is there anything left
> for the Dogtag secret store?
>

The key wrapping feature is basically completed on the server side.  On
the client side, though, nothing has yet been done.  I suspect that this
will be something that will end up being tackled in K.

Right now, I am focused on several Dogtag patches:
1. Patch to extend Dogtag plugin to issue certificates through the
backend CA.
2. Patch to extend Dogtag plugin to support asymmetric generation.

So, whats missing?  Once Arvind's CR lands, we still need a follow-on CR
to extend the orders API to be able to both generate and issue
certificates.  Central to this is the decision to not attempt to design
a common set of parameters for all CA's, but rather to require the
client to specify vendor specific metadata.  That means that we will
need to provide some kind of identifier that the client will use to
identify the relevant CA.

Note that a particular plugin may support multiple subCA's.  We plan in
the near future to add a feature to Dogtag that would allow the creation
of lightweight subCA's within a dogtag instance.  This would allow, for
instance, projects to issue certificates scoped to that particular
project.  Possibly adding an admin interface to Barbican to configure
such subCA's, or CA's in general is something that will likely be a
design session for K.

For now, I think we will need a table of ca_id to plugin_name, or
something similar and some mechanism of exposing the ca_id's to the
client.

What would also be nice would be some API that clients can call to
retrieve a schema of the required/optional vendor specific parameters
that they need to provide.  This will ultimately translate into a method
that cert plugins would have to implement.

In any case, at least part of this design work needs to happen now for
cert management to move forward.

The other thing I'd like to get resolved in J is the chef-ization of a
Dogtag instance into the dev instance.  Just need to find the time to
get back to that.

On the Dogtag front, progress has been slow on getting all the relevant
packages approved/accepted within Debian/Ubuntu.  If anyone happens to
know of any core Debian reviewers, or is a whiz at packaging Debian
packages (particularly Java), we could use the help :)

We also need to get the dogtag client python code into pip and then into
global requirements, but that likely wont happen till K time frame
either.

> On our side we do not have too much left. We have the KMIP secret store CR
> (101582) left. Kaitlin is making good progress on that. We released PyKMIP
> this week and are testing with actual KMIP servers. We also need to get
> PyKMIP into global requirements. Joel is pushing a CR soon for that.
>
> What is the main focus for Rackspace? I saw the symantecssl CR. I should
> have more time next week to help with reviews, so if there is anything I
> can help with let me know.
>
> -Nate