Difference between revisions of "Peer2PeerKeystones"

Revision as of 00:11, 23 May 2014

Peer-to-Peer Keystones

or

P2P Support for Virtual Organizations (or Virtual Projects)

Goal: Enable one Keystone to "import" services from other Keystones.

Premise: This is tantamount to a P2P VOMS (VO Mgmt Service), rather than an external, third-party VOMS (such as KeyVOMS). Any services that a Keystone can "import" or access from another Keystone are managed in the context of a VO. This could alternatively be called a Virtual Project, but we will stick with the "VO" terminology for now.

Premise: For this blueprint, all service types will be considered; not just OpenStack infrastructure services.

Ground rules:

• As with any P2P system, there will be significant performance and scalability concerns. These will be considered at a later time.
• There will also be significant trust and governance issues that must be thoroughly addressed. In this blueprint, we are just trying to identify the major architectural elements and design choices.
• This blueprint presents a general solution. Many simplifications could be made to trade generality for tractability.

The Current Keystone Model: The Keystone v3 model includes domains, projects, users, roles, services and endpoints. Projects and users are domain-specific, while roles, services and endpoints are Keystone-instance-wide. Users can be assigned roles and given project membership(s). Endpoints can also be associated with projects, thereby enabling endpoint filtering.

Hierarchical projects are currently being considered by Keystone. While not incompatible with the VO concept, they are not critical to this initial VO discussion. Hence, to simplify this blueprint, they are not considered here.

Key Observation: Keystone A does not start by immediately importing services from Keystone B -- it starts by joining a Keystone P2P network (or some other type of collaboration mechanism).

This P2P network enables Keystones to access remote services that are managed through a Virtual Organization (or Virtual Project) abstraction.

A VO is a security and collaboration context for securely managing the sharing of resources (services) among participating Keystones. (See the Object Model diagram.) A VO Domain consists of a set of Roles and a set of Projects. Roles and Projects are the tools whereby user access to services is managed. This management is done by managing the associations between objects, i.e., Users-Roles, Users-Projects, and Projects-Endpoints. (Some representative object associations are shown in the diagram.)

To allow its local users to "join a VO", the local keystone must import the VO domain, i.e., its projects and associated rule set from another Keystone that is already participating in that VO.

Design Issue: Who initially decides this project set and role set? Is it static over the VO lifecycle or can it change?

Each site has a local admin that can

(a) assign (VO) roles to local users,

(b) make a user a member of a VO project, and

(c) assign local services to VO projects (to enable endpoint filtering).

(This local admin is tantamount to a combined vo_admin/vo_site_admin in the KeyVOMS model.)

Design Issue: If each site has its own local (VO) admin, there must be mutual trust among them that each will assign roles and project memberships to their local users and services properly.

When a user authenticates to their local Keystone -- with (VO) project scope -- the local Keystone queries the P2P network for all other services mapped to this project at other Keystones. (See next diagram.)

The service endpoints returned in the Service Catalog are filtered according to which VO projects the services are assigned to, and which VO project the user is a member of.

Design Issue: Who issues the AUTH_TOKEN(s) with this Service Catalog? The Keystone that "owns" the user, or the Keystone that "owns" the service?

If the User's Keystone issues the token:

• The Service PEP must know which Keystone to use for token validation.
• The Service Owner must delegate token validation to remote Keystone,

If the Service's Keystone issues the token:

• User's Keystone must provide a token for potentially each service returned in the VO Svc Catalog. Could possibly do this on-demand(lazy evaluation).
• User must know which token to use for which service invocation.

Third Option: A user's local Keystone acts as a broker to the service's remote Keystone. The user authenticates to the local Keystone. The local Keystone then acts as a user to the remote Keystone: it authenticates to the remote Keystone and then calls the service on behalf of the local user. The local Keystone must assume the user's identity and authorization attributes, i.e., roles. That is to day, the user must _delegate_ this authorization to it's local Keystone.

Third Option Pros: This reduces the number of tokens that have to be issued. These tokens only have to be issued among a trusted set of entities, i.e., Keystone servers.

Third Option Cons: This introduces more layers of sfw to go through, network hops, and latency.

In all cases, once the user's token is validated, the service PEP must make the final authorization decision based the user's roles. After all this, the service executes and returns a result.