Open Stack

Big +1 to re-evaluating this. In my environment we have many users
deploying and managing a number of different apps in different tenants.
Some of our users, such as Yahoo Mail service engineers could be in up to
40 different tenants. Those service engineers may change products as their
careers develop. Having to re-deploy part of an application stack because
Sally SE changed products would be unnecessarily disruptive.

 I regret that I missed the bus on this back in June. But at Oath we've
built a system (Called Copper Argos) on top of Athenz (it's open source:
www.athenz.io) to provide instance identity in a way that is both unique
but doesn't have all of the problems of a static persistent identity.

 The really really really* high level overview is:
1. Users pass application identity data to Nova as metadata during the boot
process.
2. Our vendor-data driver works with a service called HostSignd to validate
that data and create a one time use attestation document which is injected
into the instance's config drive.
3. On boot an agent within the instance will use that time-limited host
attestation document to identify itself to the Athenz identity service,
which will then exchange the document for a unique certificate containing
the application data passed in the boot call.
4. From then on the instance identity (TLS certificate) is periodically
exchanged by the agent for a new certificate.
5. The host attestation document and the instance TLS certificate can each
only be used a single time to exchange for another certificate. The
attestation document has a very short ttl, and the instance identity is set
to live slightly longer than the planned rotation frequency. So if you
rotate your certificates once an hour, the ttl on the cert should be 2
hours. This gives some wiggle room in the event the identity service is
down for any reason.

The agent is also capable of supporting SSH CA by passing the SSH host key
up to be re-signed whenever it exchanges the TLS certificate. All instances
leveraging Athens identity can communicate to one another using TLS mutual
auth.

If there's any interest i'd be happy to go into more detail here on the ML
and/or at the summit in Sydney

-James
* With several more zoolander-style Really's thrown in for good measure.


On Tue, Oct 10, 2017 at 12:34 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

> Big +1 for reevaluating the bigger picture. We have a pile of api's that
> together don't always form the most useful of api's due to lack of big
> picture analysis.
>
> +1 to thinking through the dev's/devops use case.
>
> Another one to really think over is single user that != application
> developer. IE, Pure user type person deploying cloud app in their tenant
> written by dev not employees by user's company. User shouldn't have to go
> to Operator to provision service accounts and other things. App dev should
> be able to give everything needed to let OpenStack launch say a heat
> template that provisions the service accounts for the User, not making the
> user twiddle the api themselves. It should be a "here, launch this" kind of
> thing, and they fill out the heat form, and out pops a working app. If they
> have to go prevision a bunch of stuff themselves before passing stuff to
> the form, game over. Likewise, if they have to look at yaml, game over. How
> do app credentials fit into this?
>
> Thanks,
> Kevin
>
> ________________________________________
> From: Zane Bitter [zbitter at redhat.com]
> Sent: Monday, October 09, 2017 9:39 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [keystone][nova] Persistent application
> credentials
>
> On 12/09/17 18:58, Colleen Murphy wrote:
> > While it's fresh in our minds, I wanted to write up a short recap of
> > where we landed in the Application Credentials discussion in the BM/VM
> > room today. For convenience the (as of yet unrevised) spec is here:
>
> Thanks so much for staying on this Colleen, it's tremendously helpful to
> have someone from the core team keeping an eye on it :)
>
> > http://specs.openstack.org/openstack/keystone-specs/
> specs/keystone/backlog/application-credentials.html
> >
> > Attached are images of the whiteboarded notes.
> >
> > On the contentious question of the lifecycle of an application
> > credential, we re-landed in the same place we found ourselves in when
> > the spec originally landed, which is that the credential becomes invalid
> > when its creating user is disabled or deleted. The risk involved in
> > allowing a credential to continue to be valid after its creating user
> > has been disabled is not really surmountable, and we are basically
> > giving up on this feature. The benefits we still get from not having to
> > embed user passwords in config files, especially for LDAP or federated
> > users, is still a vast improvement over the situation today, as is the
> > ability to rotate credentials.
>
> OK, there were lots of smart people in the room so I trust that y'all
> made the right decision.
>
> I'd just like to step back for a moment though and ask: how exactly do
> we expect users to make use of Keystone?
>
> When I think about a typical OpenStack user of the near future, they
> looks something like this: there's a team with a handful of developers,
> with maybe one or two devops engineers. This team is responsible for a
> bunch of applications, at various stages in their lifecycles. They work
> in a department with several such teams, in an organisation with several
> such departments. People regularly join or leave the team - whether
> because they join or leave the organisation or just transfer between
> different teams. The applications are deployed with Heat and are at
> least partly self-managing (e.g. they use auto-scaling, or auto-healing,
> or have automated backups, or all of the above), but also require
> occasional manual intervention (beyond just a Heat stack-update). The
> applications may be deployed to a private OpenStack cloud, a public
> OpenStack cloud, or both, with minimal differences in how they work when
> moving back and forth.
>
> (Obviously the beauty of Open Source is that we don't think about only
> one set of users. But I think if we can serve this set of users as a
> baseline then we have built something pretty generically useful.)
>
> So my question is: how do we recommend these users use Keystone? We
> definitely _can_ support them. But the most workable way I can think of
> would be to create a long-lived application user account for each
> project in LDAP/ActiveDirectory/whatever and have that account manage
> the application. Then things will work basically the same way in the
> public cloud, where you also get a user per project. Hopefully some
> auditability is maintained by having Jenkins/Zuul/Solum/whatever do the
> pushing of changes to Heat, although realistically many users will not
> be that sophisticated. Once we have application credentials, the folks
> doing manual intervention would be able to do so in the same way on
> public clouds as on private clouds, without being given the account
> credentials.
>
> Some observations about this scenario:
> * The whole user/role infrastructure is completely unused - 'Users' are
> 1:1 with projects. We might as well not have built it.
> * Having Keystone backed by LDAP/ActiveDirectory is arguably worse than
> useless - it just means there are two different places to set things up
> when creating a project and an extra layer of indirection. (I won't say
> we might as well not have built it, because many organisations have
> compliance rules that, ahem, well let's just say they were developed in
> a different context :)
> * We're missing an essential feature of cloud (or even of VPSs): you
> shouldn't need to raise a ticket with IT to be able to deploy a new
> application. Any involvement from them should be asynchronous (e.g.
> setting quotas - although even that is an OpenStack-specific thing: in
> public clouds excessive use is discouraged by _billing_ and in
> non-OpenStack clouds users set their _own_ quotas); we don't want humans
> in the loop.
> * AFAIK it's not documented anywhere that this is the way we expect you
> to use OpenStack. Anybody would think it's all about the Users and Roles.
>
> Perhaps someone can suggest a better scenario for this group of users? I
> can't think of one that doesn't involve radical differences between
> public & private clouds (something we're explicitly trying to prevent,
> according to our mission statement), and/or risk total application
> breakage when personnel change.
>
> My worry is that in this and other areas, there's a disconnect between
> the needs of the people whom we say we're building OpenStack for and
> what we're actually building. (Speculation: this might be partly due to
> a tendency to see OpenStack projects as merely an abstraction layer over
> a bunch of vendor technologies - Keystone, as abstraction layer over
> LDAP/ActiveDirectory, Nova as an abstraction layer over
> libvirt/Xen/HyperV, &c. - rather than as components of an integrated
> cloud management service.) I'd like to see us do something like develop
> a bunch of user personae and re-evaluate the conceptual underpinnings
> of... everything, to align them with those needs. Put another way, I
> think looking at features like application credentials in isolation is
> likely to produce locally-optimal decisions rather than a
> globally-optimal design.
>
> cheers,
> Zane.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171030/c2837d38/attachment.html>