Kite Team Server: Security Model
Protecting your company’s data is critical to us. Source code is a precious asset and Kite protects it by keeping it private. Kite Pro does this by never transmitting code or derivatives of code off the end-user’s device. Kite Team Server extends the capabilities of Kite Pro by using a centralized deployment, but still ensures code stays private and secure by keeping it behind the firewall. Your code never leaves your network.
A Kite Team Server deployment has two components:
- The server, deployed in your cloud or data center.
- The client, running on each user’s local machine.
The server component is a containerized application with five sub-components:
- edge-ingress: An edge proxy for incoming requests. Can be used as the ingress, or can be behind another ingress.
- tunable-models: The models server and inference runtime.
- metadata: Settings service to provide configuration to the client.
- model-stats-proxy and models-ingress: Internal proxies for additional routing and logging.
The server runs on Linux, and is tested on Ubuntu and CentOS. Component images are available on Docker Hub and can be run with the container orchestration technology of your choice. The default setup scripts install and run a single-node cluster using Docker Swarm, and require outbound internet access to install packages and download the images. The scripts can be modified to support custom package environments such as private image repositories.
The client is a desktop application that runs on MacOS, Windows, and Linux. It consists of three components:
- IDE plugins, installed via each IDE’s plugin manager. The plugins are thin clients that delegate as much as possible to the Kite engine.
- Local Kite Engine: The main Kite process running on the end-user’s machine. IDE plugins request completions from the engine and the engine enriches the requests with context information before forwarding the request to the Kite Team Server backend. It also provides a basic version of the completions model as a fallback if the server is unreachable or experiencing high latency.
- Copilot: An Electron-powered companion app that provides contextual documentation and client configuration.
Users download the appropriate client for their OS from the Kite website (https://www.kite.com/download). The Kite client automatically installs application and security updates as needed.
Server Networking and User Authorization
Kite Team Server should be deployed in a private network environment. It defers user authorization to network firewalls, so integration with SSO or other authentication systems is not required.
Kite Team Server requires that the edge-ingress container be reachable by clients.
edge-ingress exposes the following ports:
- 8500 (HTTP1.1 & HTTP2 without TLS) – the primary application interface for use with a TLS-termination proxy.
- 9500 (HTTP1.1 & HTTP2 with TLS) – the primary application interface when used as client ingress.
- 8501 (HTTP1.1) – the custom model training API. Only needed for admins performing custom training operations. Not needed by application clients to use built-in or custom-trained models.
- 9901 (HTTP1.1) – the Envoy Proxy (https://www.envoyproxy.io/) admin interface. Not needed by application clients.
Application clients should use TLS to access the server, and you can choose whether to terminate TLS at edge-ingress, or via an additional terminating proxy. To make edge-ingress terminate TLS you must include a valid certificate and primary key while deploying Kite Team Server. To use a terminating proxy, set up that proxy in your data center or cloud provider (e.g. AWS Application Load Balancer) and configure the appropriate routes to edge-ingress.
Custom Model Fine-Tuning
Kite Team Server includes a general-purpose model, trained to perform well on a wide variety of codebases. It also includes the option to fine-tune the deployed model by training on additional source code files. All model training is done by the Kite Team Server running inside the private network. Source code never leaves the network.
Training is done by the custom model training API in Kite Team Server. Operators invoke the API using a provided CLI application to:
- Package and upload source code files to the server.
- Train models based on uploaded source code.
- Set the active model for use by application clients.
Operators invoke the API from any machine with access to the training port. Kite Team Server only accesses source code during scheduled training and does not read source code while serving completions to the client. The custom model has knowledge about textual patterns in your internal code, such as API names. It does not include the internal code itself, and it’s impossible to reverse-engineer the full internal code from the custom model. Uploaded code is stored on disk in the Kite Team Server until it is removed via the API.
Kite Team Server defers to network configuration for the authentication and authorization of all requests, including training requests. Networking configuration should control access to the training API port (8501) as appropriate. The training API exposes only limited information – the list of available and active models and code repositories – but allows users to upload code, train models, and set the active model.
External Network Access
The server components of Kite Team Server do not need external network access. The default installation script uses external network access to download packages and images, but it is also possible to use internal repositories and mirrors as required.
Future versions of Kite Team Server will include features to automatically update the server with new code and models. These features will require external network access but will be optional.
Data Model and Data Egress
The client component does not require external network access to operate, but does make a number of outbound connections as part of normal operation:
|Client Updates||Download new versions of the Kite client.||None||release.kite.com
|Remote control||Deliver remote configuration and push notifications to the client.||None||rc.kite.com|
|Telemetry||Send aggregated client telemetry to Kite.||Kite usage metrics Hardware configuration(See appendix)||t.kite.com|
|Auth||User identification for telemetry. Authorization for Kite Pro (not used with Kite Team Server).||Users optionally log in to Kite with an email address and password.||alpha.kite.com|
|Docs||Get documentation for display in Copilot.||None||alpha.kite.com|
|Error and crash reporting||Send error and crash reports.||Stacktraces and other details of unexpected Kite client errors.||alpha.kite.com
In no case does source code ever leave the network. Requests to Kite Team Server include a sample of source code taken from the user’s current context (before and after the cursor). These requests and responses are not stored in the client or server and never transmitted to outside the network or to anywhere controlled by Kite.
Appendix: Telemetry Data Description
- User ID: Kite-generated ID for the user. Stored on the user’s machine.
- IP Address: Collected by the telemetry server on telemetry requests
- Client machine MAC address
- Kite Pro license details (N/A to Kite Team Server)
Hardware & OS Profile:
- Client machine CPU clock speed
- Total system memory and available memory
- Machine OS and version
- Samples of client machine CPU utilization
- Whether the user is running on battery
- An estimate of how much the user’s fan is running
- An estimate of machine temperature
- Version of the Kite client
- Whether the user has Git CLI installed
- Versions of installed supported IDEs
- Versions of installed Kite IDE plugins
- Number of completions requested, shown and selected, partitioned by language and editor.
- Counts and timing of usage of various parts of the Copilot application.
- Number of requests and errors partitioned by code, and timings, of requests made to Kite Team Server.
- Counts of usage of various features specific to a single Kite IDE plugin.