Open Stack

> >From: Sandy Walsh [sandy.walsh at RACKSPACE.COM] Monday, December 01, 2014 9:29
> >AM
> > 
> >>From: Duncan Thomas [duncan.thomas at gmail.com]
> >>Sent: Sunday, November 30, 2014 5:40 AM
> >>To: OpenStack Development Mailing List
> >>Subject: Re: [openstack-dev] Where should Schema files live?
> >> 
> >>Duncan Thomas
> >>On Nov 27, 2014 10:32 PM, "Sandy Walsh" <sandy.walsh at rackspace.com> wrote:
> >>> 
> >>> We were thinking each service API would expose their schema via a new
> >>> /schema resource (or something). Nova would expose its schema. Glance
> >>> its own. etc. This would also work well for installations still using
> >>> older deployments.
> >>This feels like externally exposing info that need not be external (since
> >>the notifications are not external to the deploy) and it sounds like it
> >>will potentially leak fine detailed version and maybe deployment config
> >>details that you don't want to make public - either for commercial reasons
> >>or to make targeted attacks harder
> >> 
> > 
> >Yep, good point. Makes a good case for standing up our own service or just
> >relying on the tarballs being in a well know place.
> 
> Hmm, I wonder if it makes sense to limit the /schema resource to service
> accounts. Expose it by role.
> 
> There's something in the back of my head that doesn't like calling out to the
> public API though. Perhaps unfounded.

I'm wondering here how this relates to the other URLs in the
service catalog that aren't intended for external consumption,
e.g. the internalURL and adminURL.

I had assumed that these URLs would be visible to external clients,
but protected by firewall rules such that clients would be unable
to do anything in anger with those raw addresses from the outside.

So would including a schemaURL in the service catalog actually
expose an attack surface, assuming this was in general safely
firewalled off in any realistic deployment?

Cheers,
Eoghan