GENI Engineering Conference 13 Session The GENI Federation Software Architecture

Sponsored by the National Science Foundation

GENI Engineering Conference 13 Session

The GENI Federation Software Architecture

Marshall Brinn, GPORob Ricci, University of Utah

March 14, 2012

Sponsored by the National Science Foundation 2March 14, 2012

GENI Architecture Team

• At GEC12, the GENI Architecture Team was constituted to:– Define the software architecture of the GENI federation– Document the architecture for the broader GENI community– Ensure that GENI software implementations and deployments are

interoperable and comply with this architecture• The Architecture Team has been meeting (by teleconference) bi-

weekly since GEC12.– We have focused on an initial critical set of architectural decisions, many

of which are reflected in this presentation– At a meeting yesterday, we agreed in principle (pending last edits) to the

first version (V1.0) of the GENI Federation Software Architecture document.

GENI Architecture TeamCo-chairs:

Rob Ricci, University of Utah Marshall Brinn, GENI Project Office (GPO)

Voting members:Nick Bastin, Stanford University Jeff Chase, Duke UniversityMax Ott, NICTA Larry Peterson, Princeton UniversityChip Elliott, GPO


Architecture Context

• Obviously, this is not the first time people have tried to describe an architecture for GENI

• Our current approach builds on many these approaches– Including SFA, and materials from the GENI Planning

Group, and the Control Framework Working Group• The architecture has evolved as the scope and

focus of the program has evolved– We’ve gained more experience in deploying and

integrating resources, and supporting experimenters – We’ve placed more emphasis on details of federation,

trust, interoperability


The GENI Federation Software Architecture Document V1.0

This presentation covers the high-level concepts in the document.

The document will be available on the GENI website shortly, and contains much more detail than is provided here.

This is only V1.0, the first deliverable in an ongoing process of definition and refinement.


Scope

The term GENI has come to mean many things in different contexts: • GENI is, first, a vision for providing and managing highly scalable

programmable dynamic computation topologies from a broad range of heterogeneous resources.

• GENI is also the name of the NSF program and community of researchers, campuses, architects, and developers working to bring the GENI vision to fruition.

• GENI is a software architecture defining interfaces by which such topologies are managed and used and such resources are federated.

• GENI is the name of a specific federation (“the GENI Federation”), built under the GENI program, which represents an implementation and deployment of the GENI architecture on a specific set of hardware resources and a set of policies for administering those resources in the context of that federation.

This presentation and associated document describes the GENI software architecture in general as well as the GENI Federation in specific.


GENI Vision: An architecture-specific rendering

GENI is a deeply programmable infrastructure suite for performing computer science experimentation at scale.

Deeply Programmable: Allows programmatic configuration and control of all aspect of a computation network (computation, storage, communications)

Infrastructure suite: Provides transparent access to a federation of sliceable and shareable resources in custom topologies

At Scale: Allows support for extremely large, distributed experimental topologies, distributed across 100-200 campuses with realistic traffic loads or real traffic from users who ‘opt in’


The GENI Federation ArchitectureA federation is a set of agreements among people or organizations, representing the policies and terms under which they will trust, collaborate, share resources or engage in other common activities.

A federation architecture is a set of constructs and services that codify and enforce those agreements.

The GENI software architecture seeks to mediate the requirements of a set of different (human) principals: • Management authorities that own computation and network

resources at a campus, test-bed, regional or backbone and are willing to contribute to the GENI federation for use subject to policies they set.

• IT Staff who manage the operations of these resources.• Experimenters1 who wish to make use of federation resources for

deploying experiments, services or applications.

1The consumers of GENI resources may also include researchers, students, application developers, service providers and opt-in users, but the main focus of the GENI federation, and this presentation, is experimenters.


Architecture Services: Motivation

Experimenter:

I want deeply programmable resource topologies

Aggregate Manager API Federation Services API

Aggregate Manager:

I want to protect my resources

Authentication: Trusted 3rd parties vouch for all participantsAuthorization: All participants conform to essential standardsAccountability: Any misbehavior can be identified and stopped.Autonomy: Ultimate allocation decisions reside with Aggregate.


GENI Federation Schematic

ExperimenterTool

Aggregate

AM Requests

AM Responses

Experimenter:




Experimenter:


Aggregate Manager:

I want to protect my resources:• Authentication

Identity Provider

(IdP)

Certified Identity

ExperimenterTool

Aggregate

AM Requests

AM Responses



Experimenter:


Aggregate Manager:

I want to protect my resources:• Authentication• Authorization

Identity Provider

(IdP)

CredentialProvider

(SA)

ExperimenterTool

Aggregate

AM Requests

AM Responses

AM Requests

AM Responses

AuthZ Services

Certified Identity

Rights to Resources



Experimenter:


Aggregate Manager:

I want to protect my resources:• Authentication• Authorization• Accountability Identity

Provider (IdP)

CredentialProvider

(SA)

ExperimenterTool

Aggregate

AM Requests

AM Responses

AM Requests

AM Responses

AuthZ Services

Logging Services

GMOC

Forensics DataRequests and Responses

Certified Identity

Rights to Resources


GENI and Standardized API’s

• GENI aggregates provide a range of innovative, powerful control frameworks: ORCA, PlanetLab, ProtoGENI– They are interoperable, providing the AM API– Each provides its own authentication, authorization and

accountability (AAA) services– Others may come as GENI evolves and federates with new

aggregates, frameworks, other federations.• These may or may not provide their own AAA services

Much as we developed the AM API to support standardized Aggregate Services, this year will be devoted to support standardized Federation Services

The GENI Federation seeks to provide open and interoperable AAA services across GENI to support “one-stop” help, forensics, shutdown capabilities to the GMOC


Architecture Details: Outline

• Aggregate Services• Federation Services• Federation Deployment Configurations• Trust Relationships


Architecture Details: Aggregate Services

Some Definitions:

An aggregate represents a resource or set of resources that can be offered for inclusion in some customer specified topology. These typically fall into the broad categories of Computation, Communication and Storage resources.

A sliver is a (real or virtual) resource group provided by the aggregate via the “Aggregate Manager” (AM) API.

A slice is a collection of slivers gathered for a common purpose that are configured into a topology on which to deploy experiments or applications in some degree of isolation from other slices.

Slices may contain slivers from a single aggregate or may span across multiple aggregates. In the latter case, an operation called stitching is required to coordinate shared constraints such as common services or network constraints (e.g. VLAN ID’s).


Aggregate Manager (AM) API Summary

The essential service types provided by an aggregate are:

• Directory services: Listing resources available (e.g. listResources)

• Reservation services: Pre-allocating resources by gaining a ticket that can be redeemed in the future for a resource.

• Allocation services: Requesting a sliver or list of slivers from an aggregate manager to be placed into a slice.

• Sliver services: Requesting changes to a sliver’s state (modifying its current life-cycle stage, e.g.)

The architecture document does not include details at the level of APIs; rather, it is intended toguide the development of those APIs. The AM API is defined in greater detail athttp://groups.geni.net/geni/wiki/GAPI_AM_API. Note that the current AM API (Version 2) requires changes to support all of these services.

http://groups.geni.net/geni/wiki/GAPI_AM_API

http://groups.geni.net/geni/wiki/GAPI_AM_API


Architecture Details: Federation Services

In the GENI Federation, we refer to this collection of services as the Clearinghouse.

Authentication Services: Establishing trusted, common identity and credentials among participants in GENI interactions.

Authorization Services: Enforcing allowed/prohibited actions within GENI based on experimenter credentials and federation policy. Accountability Services: Providing support for forensics and analytics by logging all (successful and failed) interactions among experimenters, aggregates and other services.


Federation Services: Accountability

The federation provides a series of services for managing the credentials of entities trusted by GENI.

• Identity Providers (IdPs) providing certificates and PKI key materials to people, registering them with the GENI federation.

• A Project Authority asserts the existence of projects and the roles of members (e.g. PI, Experimenter).

• Slice Authorities providing experimenters with slice credentials by which to invoke AM API calls on federation aggregates.

• A Service Registry provides experimenters with a ‘yellow pages’ of URL’s of all trusted services of different kinds. In particular, the list of all available aggregate managers trusted by GENI (possibly satisfying particular search criteria) is provided.

• A Portal provides web-based authentication and access to the authorized Clearinghouse services and other GENI tools, providing a per-session repository for user certificates and credentials for the user’s convenience.


Federation Services:Authorization [1]

• Trust Policy is set of statements from which allowable actions may be inferred from the attributes of a principal. – These statements are credentials (assertions about a principal signed by a

trusted authority) regarding possession or delegation of rights and privileges or delegations of rights and privileges, or e.g. a principle’s role with respect to a particular project, slice, resource or institution.

• Resource Allocation Policy is a statement regarding the resource allocations or allocation behaviors associated with a given project, slice or experimenter. – For example, we may wish to limit the number of compute nodes (computers

or VM’s) allocated to a given project at any given time.– It does not override an aggregate’s local resource allocation policies unless

the aggregate has explicitly agreed to do so as part of federation membership


Federation Services:Authorization [2]

• The Authorization Service determines whether a given action is permitted by policy. – It contains a series of guards, each of which may veto a given action (i.e.

an act is authorized if and only if it is allowed by every guard). – Aggregates may use this service, or by mutual agreement, a different

trusted authorization service that enforces federation and local policy

• The Credential Store provides storage/retrieval access to credentials to Federation Services and also may be used by AM’s to support their own authorization decisions.– By keeping authorization credentials separate from authentication

certificates and by imposing short expiration times on credentials, it is possible to modify credentials and have the effects of these modifications take effect in a reliable and timely manner throughout the federation.

Version 1 of the GENI Federation Clearinghouse will include a trust guard and a resource allocation guard.


Federation Services:Accountability

• The Federation provides a Logging Service that logs transactions (successful or failed) between experimenter tools and aggregates to support real-time and post-facto forensics and analytics

• Aggregates may use this logging service, or by mutual agreement, some other trusted logging service.

In the GENI Federation, all AM transactions must be logged, and all logs accessible to the GMOC• The GMOC logs provide the traceability between slivers and

slices. • The Slice Authority provides the link of slices to projects.• The Project Authority provides the link of projects to leads. • Together, these provide the ability to find the responsible party to

contact in case of problematic behavior on the part of an experiment


GENI Federation Schematic: Services and Internal Relationships

GENI Clearinghouse

Slice Authority

Project Authority

Identity Provider

Service Registry

Authorization Service

Logging Service

Credential Store

Transaction Store

Retrieve Credentials

Store, Retrieve Transaction Data

Update CredentialsIdentity

Certificates


Architecture Details:Federation Deployment Configurations [1]

• GENI reflects a belief in the autonomy of aggregates, and local decision and control regarding resource management and provision of services to clients. – While supporting federation-level authentication, authorization and

accountability• GENI is also explicitly designed to allow aggregates to participate in

more than one federation simultaneously. • The GENI architecture also reflects a similar hybrid philosophy

towards monitoring and maintenance– Federation services are informed by aggregates on the state they choose

to share, from which high-level views and decisions may be taken.

The GENI architecture reflects a hybrid approach towards federation.


Architecture Details:Federation Deployment Configurations [2]

• Local Trusted Services. An AM has its own aggregate management infrastructure and provides its own authorization and logging services.

• Federation Trusted Services. An AM uses the Clearinghouse Logging and Authorization services in the course of responding to any AM API request.

• Local Proxy Aggregate Manager. An AM acts as a pass-through wrapper for another AM, providing its own authorization and logging services.

• GENI Proxy Aggregate Manager. This configuration is much like the local proxy, with the difference that the proxy AM is provided by the GENI Federation and services multiple aggregates.

The GENI Federation will consist of a range of different aggregates with different approaches towards authorization, logging and resource management.

These approaches represent deployment decisions: the act of trusting an aggregate entails trusting the details and consequences of its deployment decisions.


GENI Federated Trusted Services Configuration

GMOC

ResearcherTool

Aggregate

IdentityProvider

ServiceAuthority AuthZ

Service

Slice Authority

LoggingService

GENI Clearinghouse

ProjectAuthority

Credential Store


Architecture Details:Trust Relationships

• The GENI Federation rests on trusted interactions among the different entities (people and the tools or services that represent them). There are essentially two kinds of trust statements required for these interactions:– Authentication: I trust that you are who you claim to be.– Authorization: I trust that you have the attributes (roles, privileges,

capabilities) you claim to have. • Trust within GENI is based on the exchange of PKI key

materials, and a trusted statement is one signed by a trusted entity with their private key. – If I have access to the public key of a trusted entity and can

decrypt a message signed by that entity with their private key, I can be assured that they signed (and thus believe or assert) that statement.


Architecture Details:Trust Relationships [2]

• From these trust foundations, we may establish chains of trust: if I trust any statement signed by a root, I may trust any statement signed by an entity with particular attributes asserted by that root, etc.

Every GENI federated AM must import the GENI root certificate and accept identity certificates signed by the GENI Identity Provider (IdP)


Architecture Details:Trust Relationships [3]

• Beyond trust of the GENI root, there are additional kinds of trust established between entities by which one entity (A) authorizes or permits another (B) to act:– Delegation: By delegating a privilege or right to entity B, entity A trusts B to perform

tasks that A is currently permitted to do. B is then free to act autonomously with this new privilege based on that trust.

– Representative: For more granular control, A can assert that B ‘speaks for’ A in a particular request. A must delegate to B the general privilege that he ‘may speak for’ A.

• A specific request, signed by B can be said to be made on A’s behalf. – Proxy: A tool or service may be provided with the private key of an entity and thus are

indistinguishable from that entity for purposes of trust and action within the federation.

The GENI Federation trusts:• People who have established their identity through the GENI IdP. • Project leads to manage the delegation of authority within their projects. • AM’s who have established their attributes and identity through the Service Registry. • Clearinghouse services.


GENI Federation Trust Structure

Researcher Tools Aggregates

GENI Trust Root

GENI Clearinghouse

Certificate Signed by IdP(Known)

Signs Credentials For (Trusts) Installs Root Cert From

(Trusts anyone trusted by Root)

Makes Authenticated Requests

Researchers

Holds Private Key for(Represents)

Checks Permission(Trusts)


Upcoming Architecture Topics

• Stitching: How to orchestrate construction of cross-aggregate topologies (particularly wrt. negotiating consistent VLAN ID’s)

• Experiment Management: How the GENI architecture might define open interfaces for the crafting, deployment, orchestration, instrumentation, measuring, and analysis of experiments and applications.

• Opt-in Users: How GENI can reliably and securely support experiments in which customers may opt-in (provide informed consent) to the use of their personal traffic by that service.

• Cross-Federation Interoperability: How to establish common trust and communications between GENI and other federations.

These will be discussed at the “Upcoming Architecture Topics” session today in R1 at 1600.

There are several critical topics to be considered next by the GENI Architecture team, including:

Documents

GENI Engineering Conference 13 Session The GENI Federation Software Architecture