Support JupiterOne storage engine target

[austinkelleher]

Description

Currently we support uploading data collected by Starbase to Neo4j. It would be great if Starbase users could alternatively support JupiterOne as a storage target. This would allow JupiterOne users to run multiple integrations easily using a single tool.

Proposal

JupiterOne storage engine configuration may resemble the following:

type JupiterOneStorageEngineConfig = {
  /**
  * The JupiterOne API key to authenticate with
  */
  apiKey: string;
  /**
  * The JupiterOne account ID to target
  */
  accountId: string;
  /**
  * If provided this option specifies which base URL to use for synchronization (default: `https://api.us.jupiterone.io`)
  */
  apiBaseUrl?: string;
};

storage:
  engine: jupiterone
  config:
    apiKey: "..."
    accountId: "..."
    apiBaseUrl: "https://api.us.jupiterone.io"

[erichs]

One potential UX/data integrity issue arises if the user inputs an existing, but incorrect instanceId in their configuration, and uses a "global" user API token (which we want to support, perhaps in addition to integration-instance-specific tokens).

In this case, the sync api will validate the the integration instance id exists, and will happily attempt to sync data with the wrong instanceId. The persistence behavior at this point is undefined, but this will likely result in deleted/corrupt data (whatever was previously synced with the offending instanceId) and will result in a hard-to-clean-up mess.

NOTE: This problem will not occur if the user has configured an instance-specific API token (and configured it appropriately in their starbase config.yaml), as it is automatically bound to the correct instance scope, and will throw an error if there is an instanceId configuration problem in starbase.

Likely, we will want to do something like:

• retrieve the integration instance via API
• validate the instance config name matches the project name
• skip/exit early on validation failure