Nimbus

DEPRECATED: The most recent version is Nimbus TP2.1

Plugins

Current service plugins:

• Scheduling/resource management
• Networking leases
• Usage accounting
• Propagation
• Staging
• Detailed request authorization
• Initial request processing (advanced)
• VMM backend (advanced)

The defaults for all of these are distributed with the service. To develop new plugins, contact the workspace-dev mailing list (plugins are discovered via JNDI, see jndi-config.xml and the org.globus.workspace.Locator class).

As of TP1.3.1, the service supports and includes the workspace pilot resource management plugin. The pilot is a program the service will submit to a local site resource manager in order to obtain time on the VMM nodes. When not allocated to the workspace service, these nodes will be used for jobs as normal (the jobs run in normal system accounts in Xen domain 0 with no guest VMs running).

Using the pilot is optional. By default the service does not activate this plugin, it instead manages the nodes it is configured to manage in the resource pool settings.

As of TP1.2, the service supports staging plugins: RFT (see the downloads section) and HTTP pull (included in the service but not enabled by default). For more information on how it is invoked see the optional parameters interface description. For configuration, uncomment the example configuration in the service's jndi-config.xml configuration file.

Authorization

The Workspace Factory Service create operation, can be configured with any authorization plugin written for GT4 by virtue of it being a Java WSRF container based service. DENY responses from standard GT4 authorization modules mean that the factory service code was never even called, they "wrap" services at a higher layer.

The authorization callout plugin mentioned below allows for complicated policies concerning details of the request, rather than consideration of only the identity of the caller and the operation/service that was invoked.

Included in the service (but not activated by default) is the "groupauthz" plugin. This can be activated by uncommenting the configuration in the service's jndi-config.xml file.

The plugin can enforce the following policies. The request data to check is determined on a per-request, per-client basis. The limits are defined on a per group basis (every caller identity must be a part of a group).

• Maximum currently reserved minutes at one point in time. If the caller has two other workspaces with 10 hours scheduled for each, the value being checked against this policy would be 20 hours plus whatever time the current request is.
• Maximum elapsed and currently reserved minutes at one point in time. If the caller has one other workspace with 10 hours scheduled and 80 hours of recorded past usage, the value being checked against this policy would be 90 hours plus whatever time the current request is. This is the all-time maximum usage cap.
• Maximum number of running workspaces at one point in time.
• Maximum number of workspaces per request (the largest group request possible).
• The image node that must be specified.
• The image node base directory that must be specified.
• Support for identity-hash based image subdirectories (see the cloud setup documentation to understand this convention).

Each policy can be set to disabled/infinite for specific groups if you desire.

We also distribute a Python based authorization plugin (see the downloads section) that allows an administrator to provide only a simple Python script to express policies.

This plugin is compatible with both VOMS and GridShib attribute based authorization if either is enabled to protect the factory service create operation in the GT4 configuration.

Understanding the authorization possibilities requires some understanding of the factory service's create process, so the explanation below includes extra information that is not authorization related per se.

Default: gridmap setup

The default installation is configured with gridmap authorization, a DN access control list, that allows only clients in the gridmap file to call the factory create operation.

• If the client's DN is not in the grid-mapfile list, the operation will will return a fault with the authorization error explained.

The request is then validated and default values are filled in if not supplied by the client. This is also where network addresses are leased if necessary.

• If the request is simply invalid, it will be denied and a WorkspaceMetadataFault will be returned.
• If the request is asking for network allocations and there are not enough, the request will be denied and a WorkspaceResourceRequestDeniedFault will be returned.

Then the request is compared against the master policies configured in the factory.

• A violation will cause a WorkspaceResourceRequestDeniedFault to be returned.

Attribute based authorization

The VOMS and GridShib modules run before the Workspace Factory Service is ever invoked, just like the gridmap authorization:

As mentioned above there is a plugin interface for creation time authorization. All relevant information about the request is passed to the plugin including client identity and attributes (if available) as well as the workspace description and resource request. The callout to this plugin occurs after the validation process:

The supplied Python based plugin allows an administrator to configure a much richer policy than the factory policies allow for. For example, any arbitrary combination of resource allocation request (such as RAM), network settings, deployment duration, client DN, and client attributes can be taken into account.

This implementation of the authorization callout can present both VOMS credentials and SAML attributes (via GridShib) to the policy evaluation. But before they can be consulted, the "PIP" (Policy Information Point) portion of those modules must be configured. The PIP is what collects the attributes, the PDP (Policy Decision Point) is what enforces policy. This distinction is being mentioned because the PIP can be configured without the PDP in the VOMS and GridShib packages. Bear in mind that this might be an option if you are using the workspace authorization callout and want to handle all attribute policy there instead of before the factory service which is when the VOMS and GridShib modules are run. Thus, the PIP modules can collect the attributes about the client and then the detailed policy about those attributes can be expressed in the workspace creation time authorization callout.

Finally

In all cases, after the default policy check succeeds, the request is currently passed next to the scheduling/resource management plugin where problems will also lead to a WorkspaceResourceRequestDeniedFault.

After scheduling succeeds, the only thing stopping success at this point is an internal error (for example, a database connection problem).

Once deployed

Note: Once deployed, a workspace can be managed and inspected via Workspace Service or Workspace Group Service operations. Also, destruction may be run when using groups of groups, the Workspace Ensemble Service.

Currently, no matter what authorization scheme is in use, once a workspace (or group of them) is deployed, al lof these operations are protected by a DN access control list consisting of the creator DN. Only the deployer can remotely manage or inspect the workspace.