Gurobi Instant Cloud

Security and Network Settings

Our goal is to provide a secure environment to our customers, and we are continuously monitoring and improving our architecture and processes. In this section, we will review the security features and the required network settings to operate Gurobi Instant Cloud.

Accessing the Cloud Manager

The Gurobi Instant Cloud Manager is designed to streamline the control of the Gurobi Optimizer on the Cloud. With the Gurobi Instant Cloud Manager, Gurobi manages AWS EC2 or Azure instances. The Instant Cloud Manager consists of the website cloud.gurobi.com and a REST APIs. The main functions of the Instant Cloud Manager are about configuring, controlling and monitoring Gurobi compute servers. No optimization model data is communicated with the Instant Cloud Manager.

When accessing the website, users must be authenticated with their Gurobi accounts. When using the REST API, the clients are authenticated with the API key and API secret related to a user account. The communication is secure using the HTTPS protocol (minimum of TLS 1.2) and the Cloud Manager database is encrypted at rest. Access to cloud.gurobi.com is also protected by a Web Application Firewall. For security purposes, Gurobi records and monitors the metadata of HTTPS communication.

For better availability and scalability, the Gurobi Cloud Manager is hosted in different regions of the world. The clients will be routed to the most appropriate available server using a latency based routing. Each region may also provide several instances of the servers. Clients should not hardcode IP addresses to access the Cloud Manager, and should always make sure to use the latest DNS resolution.

The Gurobi client (gurobi_cl, grbtune, Gurobi library...) will first connect to the Instant Cloud Manager using the secure REST API to check the pool status and launch the compute servers as necessary. In order to enable this connection, the client firewalls must be configured to open the standard HTTPS port 443 to host cloud.gurobi.com.

Accessing the Compute Servers

When a Compute Server is started, you get a new EC2 or Azure virtual machine that is not shared with any other Gurobi customers, it is always dedicated. Machine disks are also encrypted. When the machine is terminated, all optimization data are discarded from memory and disk.

Once the compute server has been launched, optimization commands are exchanged between the client and the server. The communication is secure using end-to-end encryption with HTTPS (minimum of TLS 1.2). The region router consists of a load balancer and a region router. The region router is a reverse proxy that will forward the communication to the appropriate compute server within the Gurobi virtual network. The load balancer, the region routers and the compute servers all use encrypted HTTPS communication.

The started machines are not accessible directly and passing through the region router is enforced. The client is authenticated using a machine password or an administrator password for administrative commands. The passwords are managed by the Instant Cloud Manager. The diagram below summarizes the architecture with AWS.

architecture

As shown below, each region provides a different URL address to its router. Clients should not hardcode IP addresses to access the region routers, and should always make sure to use the latest DNS resolution. In order to enable this connection, the client firewalls must be configured to open the standard HTTPS port 443 to the following hosts depending on the region.

Provider Region Router
AWS us-east-1 https://compute-us-east-1.gurobi.com
AWS us-west-1 https://compute-us-west-1.gurobi.com
AWS eu-central-1 https://compute-eu-central-1.gurobi.com
AWS ap-northeast-1 https://compute-ap-northeast-1.gurobi.com
AWS ap-southeast-2 https://compute-ap-southeast-2.gurobi.com
Azure eastus https://compute-eastus-azure.gurobi.com
Azure westus2 https://compute-westus2-azure.gurobi.com
Azure westeurope https://compute-westeurope-azure.gurobi.com

Managing API keys

The Cloud Manager website is the only place where the API keys can be generated and revealed. Multiple API keys can be generated so that keys can be replaced in case one of them has been compromised. Each key is owned by a user. Before disabling a user by contacting the Gurobi support or before deleting an API key, please make sure that you have migrated your applications to new API keys.

Billing Recording

While a compute server running, the machine reports to the Gurobi Billing system. The Gurobi billing system consists of a database that records the use of Gurobi Cloud. A machine reports when it starts and stops to a custom web service for this database. The machine also sends basic metadata including its instance type, location, IP address and machine ID. To prevent over-charging a customer in case of failure of a machine, the server sends a periodic ping to the billing database; the billing database assumes the server is shut down if this ping is not detected. Only computer metadata is sent to the billing database. No application data or user credentials are sent to the billing database. The machine communicates with the billing system over HTTPS.

Proxies

The architecture is compatible with standard proxy settings using environment variables HTTP_PROXY and HTTPS_PROXY. HTTPS_PROXY takes precedence over HTTP_PROXY for https requests. The values may be either a complete URL or a "host[:port]", in which case the "http" scheme is assumed.