GCE OAuth Integration

Use Case

  • User should be able to create clusters using GCE with minimal manual configuration steps.

Overview

Creating a cluster on GCE involves the following manual configuration steps that a user has to perform before using Coopr.

Current Flow

  1. Create GCE account, if required.
  2. Create a project in GCE console (usually requires payment information).
  3. Enable Compute API on the project in GCE console
  4. Create a network.
  5. Create a firewall.
  6. Create identity key for ssh.
  7. Finally, enter all the above information into Coopr, and create a cluster.

The goal is to minimize the number of manual steps as much as possible. GCE requires that 1, 2, and 3 need to be done from GCE console, so they cannot be automated. However, the rest of the steps can be automated.

Proposed Flow

  1. Create GCE account, if required.
  2. Create a project in GCE console (usually requires payment information).
  3. Enable Compute API access to the project.
  4. Coopr does OAuth and gets OAuth token.
  5. Coopr creates network, firewall, etc. using the OAuth token.

The number of manual steps required before using Coopr is now reduced to 3 from 5, and remains constant no matter the type of cluster being created. This also minimizes user error and documentation required for user to perform the manual steps.

Design

In addition to supporting OAuth authentication, Coopr will also need to implement generic entity types as discussed in Entity types in Coopr. This document will only discuss OAuth support in Coopr.

Provider Type

Provider type now includes a new sensitive user field called "oauth_token" with type "oauth".

{
  "description": "Google Compute Engine",
  "name": "coopr-google",
  "icon": "http://blog.qburst.com/wp-content/uploads/2012/08/google_compute_engine_logo1.jpg",
  "parameters": {
    "admin": {
        ...
    },
    "user": {
      "fields": {
        "oauth_token": {  // added new filed
          "type": "oauth",
          "sensitive": true
        },
        "google_client_email": {
          "label": "Service account email address",
          "tip": "Service account email address, should be of the form 123456789@developer.gserviceaccount.com",
          "type": "text"
        },
        "google_project": {
          "label": "Project ID",
          "tip": "Google Project ID",
          "type": "text"
        }
      },
      "required": [
        [
          "google_project",
          "google_client_email"
        ]
      ]
    }
  }
}

UI

When UI encounters a field of type oauth, the filed is not displayed to the user. Instead, when the user creates a cluster, UI does OAuth authentication for user, and passes on the OAuth token to the server. If the server already sends the oauth field populated, then the UI will make sure that the OAuth token is valid for a few more days. If not it does a refresh of the token, and sends the updated token to server.

Server

Server handles the oauth type fields as a sensitive field, and passes it onto the provisioner.

Provisioner

Using the oauth_token provided, the provisioner will create network, firewall, etc as described in Entity types in Coopr.