Overview
The JupiterOne Collector enables you to ingest data from on-premise and self-hosted applications within your network, providing secure and flexible integration options. Collectors are deployed within your infrastructure and registered to JupiterOne, allowing you to control what resources are accessed and how data is transmitted.
Collector Overview
JupiterOne Collectors can be deployed in two primary ways:
- Docker-based Collector: Best for dedicated VMs or single-host deployments.
- Kubernetes-based Collector: Best for organizations already using Kubernetes.
Each collector instance is capable of running multiple integrations and can be managed centrally from the JupiterOne console.
Choosing a Deployment Option
| Feature | Docker-based Collector | Kubernetes-based Collector |
|---|---|---|
| Environment | Dedicated VM/host | Kubernetes cluster |
| Installation | Docker commands | Helm chart |
| Scalability | Single instance | Multiple pods/replicas |
| Management | Direct container management | Kubernetes-native (CRDs, operators) |
| Best for | Simple deployments, legacy systems | Cloud-native environments, multi-tenant |
| High Availability | Limited | Native Kubernetes HA features |
- If you want a simple, VM-based deployment, choose the Docker-based Collector.
- If you are running in a Kubernetes environment, choose the Kubernetes-based Collector.
Next Steps
For more information on architecture, security, and frequently asked questions, see the sections below.
Architecture Notes
The JupiterOne Collector is built as an extension of the JupiterOne platform, with configuration all managed from within the JupiterOne application. The Collector registers itself in your environment and will communicate with the JupiterOne platform to pull its configuration and job queue. There is no requirement for the JupiterOne cloud service to have access into your network, allowing for secure data collection.
Docker-based Architecture
The Docker-based collector orchestrates a container runtime environment for the workloads, with very straightforward installation requirements. It is a lightweight custom container orchestration tool, running the same integration workloads as in the JupiterOne cloud service.
Kubernetes-based Architecture
The Kubernetes Integration Operator leverages native Kubernetes features, using Custom Resource Definitions (CRDs) to manage integration workloads as standard Kubernetes pods. This approach provides better scalability and integrates seamlessly with existing Kubernetes tooling and practices.
In normal operation the JupiterOne collector will be:
- Sending regular heartbeats to the JupiterOne platform
- Reading from its dedicated job queue
Once an integration task is scheduled for a Collector to run it will appear on the Collectors job queue. This job will provide the collector with all the details required to configure and launch the integration task. This task will be created as a one-time container that will run the integration workload.
Security Considerations
By running JupiterOne Collectors in your own infrastructure, you are entering into a shared responsibility model for the security of that infrastructure. Whilst we at JupiterOne do everything we can to protect your data and configurations, it is the customer's responsibility to ensure that the collector host machine is secure.
The following recommendations should be reviewed and considered:
- Ensure that the host OS and container runtime are kept up to date.
- Ensure that access to the collector host machine is properly managed.
The collector stores the private key used for encryption of the job configs in /etc/.j1config/. This directory is set to be readable only by root, but depending on how you operate the container runtime these permissions should be reviewed.
If this key is accessed the integration jobs for the collector can be decrypted, potentially allowing the credentials used for the integrations to be read. It's important that all integration accounts are minimal read-only accounts where possible.
FAQ
Q: Can I run the Collector using EKS, ECS, or OpenShift?
Yes! The JupiterOne Integration Operator now supports running collectors in Kubernetes environments including EKS, ECS, and OpenShift. There are two deployment options:
- Kubernetes Integration Operator: Use the Helm chart to deploy the operator in your Kubernetes cluster. This is the recommended approach for Kubernetes environments.
- Docker-based Collector: For non-Kubernetes environments, use the traditional Docker-based collector on a dedicated VM.
Q: Does J1 Collector do network scanning?
No, the JupiterOne collector does not do any additional scanning in your environment. The JupiterOne Collector can only run integration jobs that already exist.
What the Collector does give is the ability for JupiterOne and the community to build new integration types that would not have been possible from a saas-only integration workload.
Q: The integration I want to configure doesn't have a collector option
Not all integrations are compatible with collectors, either because of the way they're built (e.g., the AWS integration and its use of AWS roles for authentication), or because the integration has not been packaged and tested yet.
If there is an integration that you would want to run on a collector that isn't currently compatible, please contact us.
Q: What network connectivity is required?
The collector needs to be able to reach the following domains:
ghcr.io,pkg-containers.githubusercontent.comandgithub.com. The GitHub package registry where the collector and integration images are hosted.*.jupiterone.io, where the collector registers, sends it heartbeats, reads the integration job queue, and finally sends the data collected by the integration jobs. This can be optionally restricted to the region specific instance, such as*.us.jupiterone.ioor*.eu.jupiterone.io.- Whatever domains the integration itself needs to connect to, for example your local vSphere instance.
Q: Do all features of all integration work?
No, there are some limitations when the integration is running on a JupiterOne collector, but generally these limitations don't impact real use cases. For example, you may find that some integrations offer the ability to "Test Credentials", this operation will only work if the integration target is reachable from the JupiterOne Cloud infrastructure, in which case you're probably not going to run that integration in a collector.
There may also be issues with some of the authentication methods, for example where the integration authenticates based on a shared trust between JupiterOne infrastructure and the target of the integration.
Q: Can I run the JIRA integration (e.g., create tickets)
No, the JupiterOne Collector only runs ingest based integration workloads, it does not include any action/alert based integrations at this time.
Q: I installed a J1 Collector but I don’t see it registered in my JupiterOne console
This indicates that the JupiterOne Collector was unable to start or register with JupiterOne. The first step is to review the logs produced by the JupiterOne collector components.
Running the command docker ps --all will show which containers ran (or are running). You can expect to find references to an "installer", "runner" and "daemon" containers. Please use docker logs <CONTAINER_ID> to retrieve the logs associated with the containers and review, attaching the logs to a support case, if required.
Please be sure to redact any sensitive details prior to sending.