Open Stack

Excerpts from Xav Paice's message of 2015-12-06 14:09:58 -0800:
> On 7 December 2015 at 05:38, Clint Byrum <clint at fewbar.com> wrote:
> 
> > Excerpts from Xav Paice's message of 2015-12-05 13:26:23 -0800:
> > > >
> >
> > I respect that this is what works for you and we shouldn't require you to
> > change your ways without good reason. However, I just want to point out
> > that if you don't trust Keystone's own ACL's to prevent administrative
> > access by users who haven't been granted access, then you also don't
> > trust Keystone to keep users out of each-others accounts!
> >
> >
> That's an excellent point, and one which scares me quite a lot.  But that's
> the sad reason we need two lots of API servers - so even if someone were to
> get hold of an admin userid/password, they still can't go deleting the
> entire cloud.  It does at least limit the damage.
> 

Indeed, this is one paradigm where it actually creates a hardened core,
not a squisy one, so I think it's not a terrible idea.

> > That said, if there really is a desire to keep admin functions separate
> > from user functions, why not formalize that and make it an entirely
> > separate service in the catalog? So far, Keystone is the only service
> > to make use of "adminurl". So a valid path forward is to simply make it
> > a different entry.
> >
> 
> Keystone is indeed the only one that does this - I hesitate to say "right"
> because it might not be.
> 
> I'm not sure I follow when you say separate service - you mean a completely
> different service, with a full set of endpoints?  Makes sense if the
> projects that use the catalogue also honour that, but I don't know I see
> the difference between having a different service for admin requests, and a
> split admin url and public url.  Maybe I'm just being thick here, but I had
> thought that was the original intention despite it never being used by
> anyone other than Keystone.
> 

What I mean is, you'd just have two completely separate _services_,
instead of one service, with two separate endpoint "interface" entries:

now:

[
  {
    "name": "keystone",
    "id": "bd73972c0e14fb69bae8ff76e112a90",
    "type": "identity",
    "endpoints": [
      {
        "id": "29beb2f1567642eb810b042b6719ea88",
        "interface": "admin",
        "region": "RegionOne",
        "url": "http://your.network.internal:3537/v2.0"
      },
      {
        "id": "8707e3735d4415c97ae231b4841eb1c",
        "interface": "internal",
        "region": "RegionOne",
        "url": "http://your.network.internal:5000/v2.0"
      },
      {
        "id": "ef303187fc8d41668f25199c298396a5",
        "interface": "public",
        "region": "RegionOne",
        "url": "http://your.cloud.com:5000/v2.0"
      }
    ]
  }
]

Proposed:

[
  {
    "name": "keystone",
    "id": "bd73972c0e14fb69bae8ff76e112a90",
    "type": "identity",
    "endpoints: [
      {
        "id": "29beb2f1567642eb810b042b6719ea88",
        "region": "RegionOne",
        "url": "http://your.cloud.com:3537/v2.0"
      },
    ]
  },
  {
    "name": "keystone-admin",
    "id": "94e572e15aad443a937b100be977b26c",
    "type": "identity-admin",
    "endpoints": [
      {
        "id": "8707e3735d4415c97ae231b4841eb1c",
        "region": "RegionOne",
        "url": "http://your.network.internal:5000/v2.0"
      }
  }
]