Kloudless API Guide

# Appendix A: Information Security

# Data

Kloudless Enterprise requires an external database to be configured to store the following information:

  • Developer accounts. e.g. email addresses, hashed passwords.
  • Kloudless Application data. e.g. name, descriptions, logos.
  • API and Developer Keys.
  • Service-specific configuration. e.g. for Box.
  • OAuth Client IDs and Secrets and related information.
  • Kloudless OAuth Tokens, Redirect URIs and related information.
  • Accounts connected by users, and their related OAuth tokens, passwords or other connection information.
  • Metadata on files and folders that need to be tracked to enable functionality.
  • Link data.
  • Multipart upload metadata.
  • File Picker data store location information.
  • Webhook notification configuration.
  • Event data.
  • "Kloudless Connect" proxy configuration information to connect to data stores in a private network behind a firewall.
  • Kloudless Property metadata information.

No file content is ever cached/stored. Downloads and uploads are streamed through the API server and/or nginx from their origin to the destination.

However, metadata may be stored depending on the service. Since event data needs to be generated by Kloudless through a variety of mechanisms depending on the service (polling, long-lived connections, webhooks, crawling, etc.), Kloudless performs these operations in the background and stores the results in the database for up to one week (configurable). This event data is then retrieved when the Events API is queried. Metadata on files is also stored to assist with checking for deleted files, modified links and other operations.

# Encryption

Secret data such as API Keys, OAuth Tokens and Client Secrets are encrypted with keys stored on the instance's file-system (data partition) prior to being stored to the database.

A 2048-bit RSA key-pair asymmetrically encrypts a 256-bit AES key using PKCS #1 with OAEP. The AES key is used in CBC mode with a random initialization vector to encrypt data. The key-pair is stored on the data partition with the public key accessible to the API service and the private key only accessible to worker processes. This is enforced with Unix file-system ACLs.

# AWS

It is possible to encrypt both the EBS boot volume as well as the data volume for Kloudless instances running in AWS. Kloudless does not automatically do this as it makes the AMI difficult to share with other AWS accounts.

To encrypt the EBS volumes, first create an AMI image of a launched Kloudless instance, including both the boot and data EBS volumes. Once the AMI is created, copy it as described in this blog post by AWS and enable encryption of EBS snapshots in the process. The new AMI can then be used moving forward.

# Data Transmitted to kloudless.com Servers

The Kloudless Enterprise servers transmit data periodically to the kloudless.com network for license validation and billing purposes. This data is described below. Additional information may be included as per your License Agreement.

# License validation

The following information is transmitted periodically to ensure the license is valid:

  • Kloudless version
  • Server network information: public IP, private IP, hostname.
  • License Key.

# Usage information - Standard

The following usage information is transmitted periodically:

  • Number of developer accounts
  • Whether external services like a DB or Redis are configured
  • Number of active/total admin/non-admin accounts per connector.

# Usage Information - Per-User Pricing

Deployments for customers with pricing structured around the number of end-users connecting accounts also transmits anonymized account metadata to Kloudless servers. This includes:

  • MD5 hashes of the following personally identifiable information (PII)*:
    • Account ID
    • Username
    • User ID
    • User domain
      *No PII is transmitted without being cryptographically hashed by default.
  • The account type: active/inactive, admin/non-admin, and the connector name.
  • The date of the last API request.
  • The date the account was connected and when it was last updated.
  • Whether the account is intended for internal development. Accounts, Applications, or Licenses can be marked as intended for internal development to waive usage fees associated with them. Please contact Kloudless to enable this capability. If enabled, the PII described above will be transmitted in plaintext and not be hashed. This enables our servers to confirm they can be excluded from billing calculations.

The usage information described above will be retained for 12 months and subsequently deleted.

# Operating without network access

If periodic pings to the Kloudless server are not preferable, please contact us to re-configure your appliance to opt-in to manual configuration updates and validation checks. This may be possible depending on the business agreement in place. If any configuration updates are required, or the license term nears expiration, ke_update_configuraton must be run manually to update the configuration and license information, in an environment with internet access.

The ke_manage_license_key and ke_update_configuration commands reach out to Kloudless cloud servers to fetch the latest configuration information. This means that the initial configuration of the instance must be done in an environment with internet access. Following this, no other pings will attempt to reach out.

# Policies

A summary of Kloudless’s Security Policy is available on request. More detailed information on specific information security policies and guidelines Kloudless maintains internally can also be provided.

← Appendix B: Container Deployment →