GENI Architecture Foundation

Abstract

The purpose of the GENI Architecture is to facilitate trusted exchange of resources.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

The purpose of the GENI Architecture is to facilitate trusted exchange of resources.

This description has the benefits of being concise and, perhaps, complete. But it raises some questions, which this chapter hopes to address:

• What objects and principals are involved in this exchange of resources?

• What makes an exchange trusted and why is this important?

• What does it mean to facilitate exchange?

1.1 Facilitating Trusted Exchange of Resources

When we speak of resources in a GENI context, we are referring to infrastructure or services that provide compute, storage and transport capabilities. These may be physical devices such as a PC, a hardware network switch or a disk, or virtual such as a VM, a software switch or a cloud-based storage service.

GENI seeks to mediate the desires of two communities with respect to such resources:

• Resource providers: People, organizations or institutions who own or manage available resources

• Resource consumers: Experimenters, educators, engineers who wish to use resources to perform research, classwork or development

Both providers and consumers have motivation to exchange, that is, to enter into agreements by which consumers may use the resources of providers. Consumers wish to have access to resources for their own purposes, while providers may be paid or otherwise incentivized to provide these resources [1].

Several barriers stand in the way of an efficient market for the exchange of resources. First, providers and consumers may not know each other or know how to find one another. Second, beyond incentives, the provider wants assurances that the consumer will use the resources in a responsible, safe manner, i.e. not bringing risk of damage to the underlying physical resources or the resources let to other consumers. Finally, the consumer wants assurances that the resources are reliable, secure and performant to advertised specifications.

Overcoming these barriers requires a trust on the part of the provider and consumers. At small scale (a small number of providers and consumers), this can be managed by relationships between individuals. However, as the number of providers and consumers grows, this approach becomes unscalable: there will be M * N relationships to be developed to support exchange between M providers and N consumers.

A trusted third party is thus required, one who is trusted by both provider and consumer and can vouch for the integrity of the other side. Such a third party needs to maintain only M + N such relationships. Finally, this third party can provide services to make the discovery, allocation, configuration, and return of resources possible in an efficient and uniform manner. Providing these services is what we mean by facilitating the exchange of resources (Fig. 1).

Fig. 1

A trusted third party such as a Clearinghouse manages the scalability of trust relationships required among resource providers and consumers

2 GENI Federation

The GENI Federation is the trusted third party required to enable reliable resource exchanges among large numbers of resource providers and consumers.

The exchange of resources, and the trust that enables such exchanges, are human activities. There are negotiations and agreements of terms and conditions, assurances, consequences and accountability. People and organizations enter into federations in order to facilitate these exchanges according to these terms.

In GENI [2], we have three sets of human parties that make up the federation, the resource providers, the resource users and the federation organization itself. These in turn, are represented in the federation architecture by software entities that represent their interests and act on their behalf to effect their desires.

A federation architecture is a set of software services that codify and enforce these agreements. These services are the Clearinghouse, the Aggregate Manager and Client Tools. Each of these will be described in greater detail later in the chapter but a brief introduction of terms is appropriate here:

• The Clearinghouse (CH) is a set of services representing the federation, establishing statements of trust, mutually recognized identity, policy-based authorization, and accountability.

• Aggregate Managers are services that represent the interests of different resource providers, providing access to resources to trusted requesting users.

• Client tools represent consumers who seek to access resources from federated services (Fig. 2).

  Fig. 2

  

  The GENI Federation consists of people and software that represent their interests

This architecture serves not only as the foundation for GENI, but is intended for and has been used in building other cyberinfrastructure federations. In fact, GENI was designed with the intent of federating independently owned and operated resources and testbeds, providing benefits to both resource providers by limiting their scope of responsibility and consumers by providing as broad a set of resources as possible.

3 Trust Foundation

The GENI Clearinghouse establishes a basis of mutual trust for Tools and Aggregate Managers to interact.

The interaction between client tools and Aggregate Managers must be made on a trusted basis. The Aggregate Manager wants a reliable sense of:

• Authentication: Who is making this request?

• Authorization: In what context should I allow access to my resources?

• Accountability: Who is responsible if something bad happens on my resources when they are used?

There are many possible software mechanisms to establish the trust to answer these questions and support the trust required to complete these transactions. GENI uses public key infrastructure (PKI), and specifically X.509 certificates and keys as the basis of authentication. Furthermore, SSL/TLS is used as the basis of trusted service interaction [3–5].

An SSL-based interaction requires that the initiator (the client tool) encrypt its transactions with its private key and pass its X.509 public cert (including its public key) along with its message. The receiver (the service provider) then checks that the certificate is in a trusted chain of certificates.

X.509 certificates and keys are provided by Clearinghouse services. The certificates are signed by the Clearinghouse authority’s private key, and assert some identifying data (an email address, a URN, a UUID) about the bearer of the certificate and associated private key.

The act of including the Clearinghouse authority’s root certificate in the trust bundle of the service is, therefore, a reflection of the human act of federation. An Aggregate Manager includes the set of Clearinghouses it trusts, and anyone bearing a certificate/key from any such Clearinghouse may speak to that Aggregate Manager.

An Aggregate Manager may belong to many Clearinghouses, and thus accept requests from users from different federations.

To be specific, while GENI is a Federation with its own Clearinghouse Authority services, so are Emulab [6], Fed4Fire [7] and several other comparable projects. Many Aggregates can and do chose to be members of one or many of these Federations.

In GENI, the act of providing a certificate to a user is not an automatic process but a human process, representing some degree of vetting and, implicitly, vouching that the user is who the user claims to be. GENI is entrusted by the National Science Foundation to support network and computer science research and education. To that end, GENI accepts requests from users with accounts at an academic institution participating in the InCommon federation. Additionally, GENI accepts requests from users to use GENI federated resources and one job of the GENI Federation staff is to check that the requesters are who they claim to be, that they are at a recognized academic institution and that they are in an appropriate research program or lab.

The question of authorization has elements that are both distributed and centralized. The Clearinghouse provides signed statements called Credentials that may be used by Aggregate Managers in their authorization decisions. These credentials are statements from the Clearinghouse indicating a set of roles or rights the Clearinghouse asserts the user has in a particular context. The Aggregate Manager will typically use these credentials as part of its authorization decision. That said, each Aggregate Manager is independent and autonomous, and can make whatever authorization decisions it chooses.

GENI supports two particular types of credentials:

• SFA Credential: These are credentials granting privilege or roles to a given user in a given context (typically a slice). This is an example of role-based access control (RBAC) and conforms to the SFA format [8].

• ABAC Credential: These are credentials asserting attributes about a given user (e.g. “X has admin privileges on slice Y” or, generally, “X is a member of the set Z”). This supports attribute-based access control by mixing ABAC assertion and policy statements and conforms to the standard ABAC format [9].

Accountability will be discussed below as we look at Federation Monitoring services.

4 GENI Concepts

Before we provide more detail on GENI Services, definitions of key GENI concepts are in order:

An Aggregate (or Aggregate Manager or AM) is a service representing a set of resources and the interests and policies of the provider of those resources. It provides services for allocating, deleting, configuring, renewing, and deleting resources using the GENI Aggregate Manager (AM) API, as will be discussed below.

An Authority is a Clearinghouse Service which generates statements (typically signed XML documents) that are trusted by Aggregates of the federation. Example authorities are the Slice Authority and Member Authority, as discussed below.

A Member is a registered GENI user, with an assigned certificate, UUID, URN at a given Member Authority.

A Sliver is a resource or set of resources provided by an Aggregate to requester through invocations of the AM API. These slivers may be a whole physical resource (e.g. a bare metal machine), or a virtualized piece of a physical resource (e.g. a virtual machine) or a combination of these.

A Slice is a collection of slivers in which resource requests are performed. The Slice is both an accounting mechanism for knowing what slivers where allocated to a given user at a given time, but also an isolation mechanism. That is, it is assumed that resources in the same slice have visibility to one another while slivers in different slices are logically (and, ideally, physically) isolated from one another.

A Project is a grouping of Slices for a particular purpose. A Project is managed by a lead, typically a professor or head of a laboratory or equivalent, and all slices in a project are associated with some common research or educational goal.

5 GENI Services

This section details the specific services and interfaces that make up the different services provided in the context of a GENI federation.

5.1 Federation API

The Federation API [10] is an interface for defining federation services, commonly negotiated by representatives of GENI, Emulab and Fed4Fire in 2013. This section provides a high-level view of these services.¹

All Federation API calls are XMLRPC/SSL and thus require invocation with the invoking member’s private key and passing their certificate.

The Service Registry (SR) is a service providing a dictionary of services available in a given Federation Clearinghouse. The SR provides the following API:

Method	Arguments	Description
get_version	None	Return version of SR API including extensions and supported object model
lookup_member_authorities	Options: Query specifying which MA’s to match	Return list of MA’s with matching and filter criteria specified in options
lookup_slice_authorities	Options: Query specifying which SA’s to match	Return list of SA’s with matching and filter criteria specified in options
lookup_aggregates	Options: Query specifying which AM’s to match	Return list of aggregates with matching and filter criteria specified in options
get_trust_roots		Return list of trust roots trusted by authorities and aggregates of the federation associated with this Clearinghouse

The Member Authority (MA) is a service providing information for creating, modifying and looking up information about registered users at a given Federation CH. If not otherwise indicated, ‘member_urn’ is a unique identifier of a particular member, as is ‘member_uid’ (a unique identifier of a different non-human-readable form), ‘key_id’ is a unique identifier for an SSH key pair, and ‘options’ is the set of fields describing a given member or SSH key pair. The MA provides the following API:

Method	Arguments	Description
get_version	None	Return version of MA API including extensions and supported object model
create_member	Options: Member details (email, name, etc.)	Create new Member with given details
update_member_info	Member_urn, Options:	Update information associated with Member
lookup_member_info	Options:	Lookup information about member. Note: the members and specific details about the member will tend to be tightly controlled by authorization policy
get_credentials	None	Get credentials representing MA’s sense of roles and rights of members independent of slice context
create_key	Options	Create or upload SSH key pair for given member

1. (continued)

Method	Arguments	Description
delete_key	Key_id	Delete given SSH key pair from member
update_key	Key_id, Options:	Modify given SSH key pair info for given member
lookup_keys	Options:	Lookup SSH key pair information matching given query criteria
create_certificate	Options: CSR provided or not	Create an X.509 cert (and optionally private key if no CSR provided)
add_member_privilege	Member_uid, privilege	Add privilege to given member (e.g. LEAD, ADMIN)
revoke_member_privilege	Member_uid, privilege	Remove privilege from given member
add_member_attribute	Member_urn, attribute_name, attribute_value	Add attribute to given user
remove_member_attribute	Member_urn, attribute_name	Remove attribute from given user

The Slice Authority (SA) is a service providing information for creating, modifying, and looking up information about slices and projects. If not otherwise indicated, the ‘slice_urn’ argument is the unique identifier for a given slice (likewise for ‘sliver_urn’ and ‘project_urn’), ‘credentials’ represents the credentials provided from the MA indicating the good-standing and role of a given user, and ‘options’ provides details on the given slice, slice membership, sliver info, project, project_membership being created or updated. The SA provides the following API:

Method	Arguments	Description
get_version	None	Return version of SA API including extensions and supported object model
create_slice	Credentials, Options	Create a new slice in a given project
update_slice	Slice urn, credentials, Options	Update a given slice with new details specified by options
get_credentials	Slice_urn, credentials	Get credentials representing SA’s sense of roles and rights of members in slice context
modify_slice_membership	Slice_urn, credentials, options	Modify (add, change, delete) membership/role for members in a slice
lookup_slice_members	Slice_urn	Lookup members/roles of a given slice

1. (continued)

Method	Arguments	Description
lookup_slices_for_member	Member_urn	Lookup slices to which a given member belongs
create_sliver_info	Options	Create a record of sliver info (sliver, slice, aggregate, time, expiration)
delete_sliver_info	Options	Delete a record of sliver info
update_sliver_info	Sliver_urn, options	Update sliver info record
create_project	Options, credentials	Create a new project (typically a privileged operation for members with “Project_Lead” privilege reflected in their credential)
modify_project_membership	Project_urn, options	Modify (add, delete, change) membership/role for members in an project
lookup_project_members	Project_urn	Lookup members/roles for a given project
lookup_projects_for_member	Member_urn	Lookup projects to which a given member belongs
lookup_project_attributes	Project_urn, options	Lookup attributes associated with given project
add_project_attribute	Project_urn, options	Add a given attribute to a given project
remove_project_attribute	Project_urn, options	Remove an attribute from a given project

5.2 Aggregate Manager (AM) API

The Aggregate Manager API [11] provides the interface by which client tools (representing users) can request, configure, renew and delete resources from an aggregate resource provider.

This section provides a high-level view of this API.² All calls take a list of credentials as an argument. These are typically a UserCredential provided by a previous call to the Clearinghouse Member Authority or a SliceCredential provided by a previous call to the Clearinghouse Slice Authority. Additionally, a dictionary of options is provided to most calls. These arguments are not included in the ‘Arguments’ table below.

AM API calls are made to a particular Aggregate Manager. They are XMLRPC/SSL calls and thus must be invoked by a user with a private key and a certificate generated by a CA trusted by the given AM.

Method (V2)	Method (V3)	Arguments	Description
GetVersion	GetVersion
ListResources	ListResources		This is the ‘no slice’ version of ListResources, providing an ‘advertisement RSpec’
CreateSliver	Allocation, Provision	Slice_urn: The slice into which to add slivers RSpec: The request RSpec indicating which resources to allocate Users: Information (SSH login info, e.g.) about users for created compute resources	Create a given resources specified in the request RSpec in the context of the given slice. Set up any compute accounts with specified user accounts. In V3, we separate this into an ‘allocate’ (prepare) and ‘provision’ (initialize and configure) calls
	Perform Operational Action	Slice_urn(v2)/urns(v3): List of sliver URNs (or slice URN) for which to perform action on slivers. Action: Type of action to perform (e.g.reboot, create_image)	Perform a sliver-specific action on a running sliver instance (V3 only)
SliverStatus	Status	slice_urn (V2)/urns (v3)	Retrieve current operational status for a given set of slivers or all slivers in a given slice at an AM
ListResources	Describe	slice_urn (V2)/urns (v3)	The slice-specific version of ListResources: provide a manifest RSpec with all resources associated with a given slice
RenewSliver	Renew	slice_urn (V2)/urns (v3) expiration_time	Renew lease on resources to given expiration time if possible
DeleteSliver	Delete	slice_urn (V2)/urns (v3) expiration_time	Delete resources associated with given slice (or specific sliver urn’s, in V3)
Shutdown	Shutdown	Slice_urn	Shutdown given slice and all associated slivers at this AM

We should note here that many features associated with allocated GENI topologies, e.g. Deep Programmability, Sliver isolation, cross-site stitching, are features provided by individual aggregates, or orchestrated by tools between aggregates. They are not, per se, features of the GENI Federation architecture and are not detailed in this chapter.

5.2.1 GENI Resource Specifications (RSpecs)

The GENI AM API requires three particular kinds of specifications to describe availability, requirements or descriptions of resources at an Aggregate Manager. RSpecs are XML documents that adhere to the http://www.geni.net/resources/rspec schema, plus recognized extensions.

These are described below.³ Examples are provided without XML preface and namespace detail for brevity and clarity.

Advertisement RSpec. A description of the available resources at an Aggregate. These are provided by a ListResources (no-slice) call. These may include bare-metal machines, virtual machines, IP address space, VLAN space, disk images and other compute or network specific resource features. The following is a simple advertisement RSpec, showing the availability of two (fake) compute nodes:

Request RSpec . A set of requirements for resources to be created at a given AM. These are required to the CreateSliver (or Allocate in V3) call. This may include (compute) nodes of given types and images, links and interfaces and other extension-specific details. The following is a simple advertisement RSpec, requesting a single compute node:

Manifest RSpec. A description of all resources allocated at a given AM for a given Slice. This is returned from a CreateSliver (or Provision in V3) call or a ListResources (with slice_urn, or Describe in V3) call. This will include the content from the Request RSpec plus provision-specific details such as IP addresses, allocated VLANs and other extension-specific details. The following is a simple manifest RSpec showing the allocation of a single compute node:

5.3 Monitoring Services

The GENI Federation seeks to provide assurances to resource providers that their resources aren’t being ill-used, intentionally or otherwise. It also seeks to provide assurances to resource consumers that the resources they’ve been provided by Aggregate Managers will be reliable.

Towards these ends, GENI provides a set of services that engender trust on the part of users towards resources provided by GENI, and accountability of users for actions taken on these resources.

GENI requires that all Federation services, including Aggregate Managers, provide data to a central monitoring service. These data consist of health status and load information (on CPU, storage, network interfaces) as well as current topology information (which slivers are connected to which across aggregates).

In this way, the monitoring service can serve as the basis of an alerting mechanism (indicating resources that are experiencing abnormal loads or patterns). It can further be the source of forensics support, by which the person associated with a misbehaving sliver or slivers can be identified. It can support a slice shutdown service by which a given resource can be shutdown, nullifying its ongoing impact on other virtual or physical resources.

From there, Federation or Aggregate-local policy can take corrective action, ranging from a warning, to deleting the resources to revoking the credentials of the user or even those of the supervisor.

6 Tools

Of course, humans cannot directly invoke calls to the Federation of AM API’s: it requires software tools to invoke these calls on their behalf. Given that these calls use SSL as an authentication and encryption mechanism, callers must have access to their private key.

Good ‘key hygiene’ (keeping private materials private) requires that private keys stay on local machines and not transit the network. GENI therefore supports two kinds of tools that manage the problem of keeping private keys private in two different ways.

Desktop Tools. In this case, the tool is run locally on the user’s desktop. The tool is pointed to the user’s certificate and private key which reside locally. The cert is sent as part of the SSL handshake but the key is only used to sign/encrypt the message and never leaves the desktop. Examples of such tools include omni (a python command-line tool for invoking arbitrary Federation and AM API calls) and jFed (a Java application run on the user’s machine that provides graphical interfaces to create and view allocated topologies).

Hosted Tools. In this case, a tool runs remotely on web server. There are several ways to enable such a configuration:

• Providing the private key. While not recommended, a tool can require that the user upload (or cut-and-paste) their private key to the tool and then the tool may ‘speak as’ the user.

• Using the tool’s key. The tool may be configured with its own certificate and private key and ‘speak as’ the tool itself. This has the advantage of not requiring divulging the user’s private key. But it loses any sense of accountability.

• Using a speaks-for credential. GENI supports using a credential (an ABAC statement, in fact) signed by the user that a given tool may speak for the user, possibly limited to certain contexts. If the tool speaks with its own cert and key and such a credential is present in the list of credentials given to the API call, the Federation and AM services will authorize and account the call to the user, not the tool. This approach preserves accountability and private key security and is thus both a novel and preferred approach for supporting hosted tools (Fig. 3).

  Fig. 3

  

  Two kinds of tools for invoking Federation or Aggregate Manager APIs: desktop and hosted tools

6.1 The GENI Portal

The GENI Portal is an example of a hosted tool. The Portal supports a Shibboleth configuration that is federated with several Identity providers including those from the InCommon Federation, CAFé in Brazil and an IdP provided by the GENI Program Office. Users authenticate to the Portal through one of these Shibboleth IdPs to establish a single-sign-on (SSO) session [12].

The Portal can then operate on behalf of the user in one of two ways:

• Users that have created a speaks-for credential (i.e. a statement that the portal can speak for the user) store these credentials in the portal, and the portal retrieves these credentials in the context of a Shibboleth authenticated session. It can then use the speaks-for credential along with the Portal’s own cert and key to invoke Federation and AM API calls on the user’s behalf based on user interface actions.

• Users that have not created a speaks-for credential may allow the Portal to create a certificate and private key for that user which the Portal can extract from its own private database and use to ‘speak as’ the user. This mode is popular (and only recommended) for short-term engagements such as tutorials and users first getting acquainted to GENI.

7 Summary

We have described the pieces required to establish trusted resource exchange in GENI. In this section, we will put them together into a single scenario. We will note that some pieces are human activities required to establish trust; others are automated processes to preserve trust. Additionally, some of these steps are one-time “set-up” steps, and others are ongoing or repeated steps for each allocation request.

Resource Providers. To enable resources to be exchanged in a trusted manner, the resource provider needs to:

• 1. Stand up a GENI Aggregate Manager service. This is a one-time human activity: installing and configuring the GENI AM service and registering it with the GENI Service Registry.

• 2. Trust the GENI Clearinghouse. This is a one-time human activity: installing the GENI Certificate Authority (CA) root in the AM’s trust root bundle. In indicates that the AM will trust users invoking AM calls using a certificate issued by this CA.

• 3. Let the Aggregate Manager handle the Authentication, Authorization and Accountability of Resource consumers. The AM performs these tasks automatically, authenticating using SSL and PKI certificate validation, authorizing per AM-local policy using provided credentials, and using GENI monitoring services to detect and respond to potential misbehavior.

Resource Consumers. To enable access resources from GENI, the resource consumer needs to:

• 1. Become a member of the GENI Clearinghouse. This is a one-time human activity: a request (by web form or email) is made to the managers of the GENI Clearinghouse who vet that the member satisfies the policy requirements for GENI membership. If so, an account is created. In addition, an account at an academic institution participating in the InCommon Federation is sufficient to be given membership in GENI.

• 2. Acquire GENI-generated identity credentials. This is a one-time human activity: receiving the X.509 certificate and private key is an out-of-band process, often facilitated by tools such as the GENI Portal, that differs among GENI installations.

• 3. Gain membership to a GENI Project. This is a human process. If a GENI member wants to be a Project Lead (capable of creating a new project), a request is made and vetted by the managers of the GENI Clearinghouse. Otherwise, the member must find an existing project lead (typically a professor or lab manager) to add this member to an existing project.

• 4. Gain membership to a GENI Slice. Once a GENI member is a member of a project, that member may create a slice using GENI tools and Clearinghouse Slice Authority operations.

• 5. Use a GENI Tool to get a Slice Credential from GENI Clearinghouse. The Slice Authority service will provide a requesting authenticated tool with Slice Credentials to slice members, which indicate membership and role in a slice.

• 6. Use a GENI Tool to request resources from a GENI Federated Aggregate Manager. Using the AM API (using the private key and certificate plus Slice and perhaps other credentials), request resources of the Aggregate Manager. The request will succeed or fail based on the AM’s available resources and its local policies for authorization and quotas.

• 7. Use the resources. This step is rests above the GENI Architecture. The resources are the consumer’s to configure and use freely. That said, GENI is involved in at least two ways. First, the configuration of resources places SSH public keys and accounts on compute nodes allowing login to these resources. Second, GENI monitoring checks the resource consumption and traffic generation patterns to ensure against misbehaving software operating on the allocated slivers.

• 8. Cleanup. Use the AM API to renew slivers as needed, and then delete them at the Aggregate when done.

The following diagram summarizes these steps and the transactions with GENI services required to establish trusted resource exchange between resource providers and resource consumers. The providers and consumers do not need to know or trust one another: they merely need to mutually trust the GENI Clearinghouse (Fig. 4).

Fig. 4

Requesting resources from an Aggregate Manager requires passing a Slice Credential from the Clearinghouse Slice Authority from which the AM may make policy-based authorization decisions