Docker Hub | Documentation | Website | View Demo
Kerberos Agent is an isolated and scalable video (surveillance) management agent made available as Open Source under the MIT License. This means that all the source code is available for you or your company, and you can use, transform and distribute the source code; as long you keep a reference of the original license. Kerberos Agent can be used for commercial usage (which was not the case for v2). Read more about the license here.
- An IP camera which supports a RTSP H264 encoded stream,
- (or) a USB camera, Raspberry Pi camera or other camera, that you can tranform to a valid RTSP stream.
- Any hardware that can run a container, for example: a Raspberry Pi, NVidia Jetson, Intel NUC, a VM, Bare metal machine or a full blown Kubernetes cluster.
There are a myriad of cameras out there (USB, IP and other cameras), and it might be daunting to know if Kerberos Agent will work for your camera. Therefore we are listing all the camera models that are acknowlegded by the community. Feel free to add your camera to the list as well!
- How to run and deploy a Kerberos Agent
- Access the Kerberos Agent
- Configure and persist with volume mounts
- Configure with environment variables
The easiest to get your Kerberos Agent up and running is to use our public image on Docker hub. Once you have selected a specific tag, run below docker command, which will open the web interface of your Kerberos agent on port 80, and off you go. For a more configurable and persistent deployment have a look at Running and automating a Kerberos Agent.
docker run -p 80:80 --name mycamera -d --restart=always kerberos/agent:latest
If you want to connect to an USB or Raspberry Pi camera, you'll need to run our side car container which proxy the camera to an RTSP stream. In that case you'll want to configure the Kerberos Agent container to run in the host network, so it can connect directly to the RTSP sidecar.
docker run --network=host --name mycamera -d --restart=always kerberos/agent:latest
Run Kerberos Agent with Balena super powers. Monitor your agent with seamless remote access, and an encrypted https endpoint. Checkout our fleet on Balena Hub, and add your agent.
Work In Progress - Currently we only support IP and USB Cameras, we have an approach for leveraging the Raspberry Pi camera, but this isn't working as expected with Balena. If you require this, you'll need to use the traditional Docker deployment with sidecar as mentioned above.
The Kerberos Agent is an isolated and scalable video (surveillance) management agent with a strong focus on user experience, scalability, resilience, extension and integration. Next to the Kerberos Agent, Kerberos.io provides many other tools such as Kerberos Factory, Kerberos Vault and Kerberos Hub to provide additional capabilities: bring your own cloud, bring your own storage, central overview, live streaming, machine learning etc.
As mentioned above Kerberos.io applies the concept of agents. An agent is running next to (or on) your camera, and is processing a single camera feed. It applies motion based or continuous recording and make those recordings available through a user friendly web interface. A Kerberos Agent allows you to connect to other cloud services or integrates with custom applications. Kerberos Agent is used for personal usage and scales to enterprise production level deployments.
This repository contains everything you'll need to know about our core product, Kerberos Agent. Below you'll find a brief list of features and functions.
- Low memory and CPU usage.
- Simplified and modern user interface.
- Multi architecture (ARMv7, ARMv8, amd64, etc).
- Multi camera support: IP Cameras (H264), USB cameras and Raspberry Pi Cameras through a RTSP proxy.
- Single camera per instance (e.g. oneå container per camera).
- Ability to specifiy conditions: motion region, time table, continuous recording, etc.
- Deploy where you want with the tools you use:
docker,docker compose,ansible,terraform,kubernetes, etc. - Cloud storage (Kerberos Hub, Kerberos Vault). WIP: Minio, Storj, etc.
- WIP: Integrations (Webhooks, MQTT, Script, etc).
- MIT License
As described before a Kerberos Agent is a container, which can be deployed through various ways and automation tools such as docker, docker compose, kubernetes and the list goes on. To simplify your life we have come with concrete and working examples of deployments to help you speed up your Kerberos.io journey.
We have documented the different deployment models in the deployments directory of this repository. There you'll learn and find how to deploy using:
By default your Kerberos Agents will store all its configuration and recordings inside the container. To help you automate and have a more consistent data governance, you can attach volumes to configure and persist data of your Kerberos Agents, and/or configure each Kerberos Agent through environment variables.
Once you have deployed the Kerberos Agent, using one of the deployment models described above, you will be able to access the Kerberos Agent user interface. A login page is presented asking for some credentials.
The default username and password for the Kerberos Agent is:
- Username:
root - Password:
root
Please note that you change the username and password for a final installation, see Configure with environment variables below.
An example of how to mount a host directory is shown below using docker, but is applicable for all the deployment models and tools described above.
You attach a volume to your container by leveraging the -v option. To mount your own configuration file and recordings folder, execute as following:
docker run -p 80:80 --name mycamera \
-v $(pwd)/agent/config:/home/agent/data/config \
-v $(pwd)/agent/recordings:/home/agent/data/recordings \
-d --restart=always kerberos/agent:latest
More example can be found in the deployment section for each deployment and automation tool.
Next to attaching the configuration file, it is also possible to override the configuration with environment variables. This makes deployments easier when leveraging docker compose or kubernetes deployments much easier and scalable. Using this approach we simplify automation through ansible and terraform.
docker run -p 80:80 --name mycamera \
-e AGENT_NAME=mycamera \
-e AGENT_TIMEZONE=Europe/Brussels \
-e AGENT_CAPTURE_IPCAMERA_RTSP=rtsp://fake.kerberos.io/stream \
-e AGENT_CAPTURE_CONTINUOUS=true \
-d --restart=always kerberos/agent:latest
| Name | Description | Default Value |
|---|---|---|
AGENT_USERNAME |
The username used to authenticate against the Kerberos Agent login page. | "root" |
AGENT_PASSWORD |
The password used to authenticate against the Kerberos Agent login page. | "root" |
AGENT_KEY |
A unique identifier for your Kerberos Agent, this is auto-generated but can be overriden. | "" |
AGENT_NAME |
The agent friendly-name. | "agent" |
AGENT_TIMEZONE |
Timezone which is used for converting time. | "Africa/Ceuta" |
AGENT_OFFLINE |
Makes sure no external connection is made. | "false" |
AGENT_AUTO_CLEAN |
Cleans up the recordings directory. | "true" |
AGENT_AUTO_CLEAN_MAX_SIZE |
If AUTO_CLEAN enabled, set the max size of the recordings directory in (MB). |
"100" |
AGENT_CAPTURE_IPCAMERA_RTSP |
Full-HD RTSP endpoint to the camera you're targetting. | "" |
AGENT_CAPTURE_IPCAMERA_SUB_RTSP |
Sub-stream RTSP endpoint used for livestreaming (WebRTC). | "" |
AGENT_CAPTURE_IPCAMERA_ONVIF |
Mark as a compliant ONVIF device. | "" |
AGENT_CAPTURE_IPCAMERA_ONVIF_XADDR |
ONVIF endpoint/address running on the camera. | "" |
AGENT_CAPTURE_IPCAMERA_ONVIF_USERNAME |
ONVIF username to authenticate against. | "" |
AGENT_CAPTURE_IPCAMERA_ONVIF_PASSWORD |
ONVIF password to authenticate against. | "" |
AGENT_CAPTURE_CONTINUOUS |
Toggle for enabling continuous or motion based recording. | "false" |
AGENT_CAPTURE_PRERECORDING |
If CONTINUOUS set to false, specify the recording time (seconds) before after motion event. |
"10" |
AGENT_CAPTURE_POSTRECORDING |
If CONTINUOUS set to false, specify the recording time (seconds) after motion event. |
"20" |
AGENT_CAPTURE_MAXLENGTH |
The maximum length of a single recording (seconds). | "30" |
AGENT_CAPTURE_PIXEL_CHANGE |
If CONTINUOUS set to false, the number of pixel require to change before motion triggers. |
"150" |
AGENT_CAPTURE_FRAGMENTED |
Set the format of the recorded MP4 to fragmented (suitable for HLS). | "false" |
AGENT_CAPTURE_FRAGMENTED_DURATION |
If AGENT_CAPTURE_FRAGMENTED set to true, define the duration (seconds) of a fragment. |
"8" |
AGENT_CLOUD |
Store recordings in a Kerberos Hub (s3) or your Kerberos Vault (kstorage). | "s3" |
AGENT_HUB_URI |
The Kerberos Hub API, defaults to our Kerberos Hub SAAS. | "https://api.cloud.kerberos.io" |
AGENT_HUB_KEY |
The access key linked to your account in Kerberos Hub. | "" |
AGENT_HUB_PRIVATE_KEY |
The secret access key linked to your account in Kerberos Hub. | "" |
AGENT_HUB_USERNAME |
Your Kerberos Hub username, which owns the above access and secret keys. | "" |
AGENT_HUB_SITE |
The site ID of a site you've created in your Kerberos Hub account. | "" |
AGENT_MQTT_URI |
A MQTT broker endpoint that is used for bi-directional communication (live view, onvif, etc) | "tcp://mqtt.kerberos.io:1883" |
AGENT_MQTT_USERNAME |
Username of the MQTT broker. | "" |
AGENT_MQTT_PASSWORD |
Password of the MQTT broker. | "" |
AGENT_STUN_URI |
When using WebRTC, you'll need to provide a STUN server. | "stun:turn.kerberos.io:8443" |
AGENT_TURN_URI |
When using WebRTC, you'll need to provide a TURN server. | "turn:turn.kerberos.io:8443" |
AGENT_TURN_USERNAME |
TURN username used for WebRTC. | "username1" |
AGENT_TURN_PASSWORD |
TURN password used for WebRTC. | "password1" |
AGENT_KERBEROSVAULT_URI |
The Kerberos Vault API url. | "" . |
AGENT_KERBEROSVAULT_ACCESS_KEY |
The access key of a Kerberos Vault account. | "" |
AGENT_KERBEROSVAULT_SECRET_KEY |
The secret key of a Kerberos Vault account. | "" |
AGENT_KERBEROSVAULT_PROVIDER |
A Kerberos Vault provider you have created (optional). | "" |
AGENT_KERBEROSVAULT_DIRECTORY |
The directory, in the provider, where the recordings will be stored in. | "" |
One of the major blockers for letting you contribute to an Open Source project is to setup your local development machine. Why? Because you might have already some tools and libraries installed that are used for other projects, and the libraries you would need for Kerberos Agent, for example FFmpeg, might require a different version. Welcome to the dependency hell..
By leveraging codespaces, which the Kerberos Agent repo supports, you will be able to setup the required development environment in a few minutes. By opening the <> Code tab on the top of the page, you will be able to create a codespace, using the Kerberos Devcontainer base image. This image requires all the relevant dependencies: FFmpeg, OpenCV, Golang, Node, Yarn, etc.
After a few minutes, you will see a beautiful Visual Studio Code shown in your browser, and you are ready to code!
Kerberos Agent is divided in two parts a machinery and web. Both parts live in this repository in their relative folders. For development or running the application on your local machine, you have to run both the machinery and the web as described below. When running in production everything is shipped as only one artifact, read more about this at Building for production.
The web is a React project which is the main entry point for an end user to view recordings, a livestream, and modify the configuration of the machinery.
git clone https://github.com/kerberos-io/agent
cd ui
yarn start
This will start a webserver and launches the web app on port 3000.
Once signed in you'll see the dashboard page showing up. After successfull configuration of your agent, you'll should see a live view and possible events recorded to disk.
The machinery is a Golang project which delivers two functions: it acts as the Kerberos Agent which is doing all the heavy lifting with camera processing and other kinds of logic, on the other hand it acts as a webserver (Rest API) that allows communication from the web (React) or any other custom application. The API is documented using swagger.
You can simply run the machinery using following commands.
git clone https://github.com/kerberos-io/agent
cd machinery
go run main.go run mycameraname 80
This will launch the Kerberos Agent and run a webserver on port 80. You can change the port by your own preference. We strongly support the usage of Goland or Visual Studio Code, as it comes with all the debugging and linting features builtin.
Running Kerberos Agent in production only require a single binary to run. Nevertheless, we have two parts, the machinery and the web, we merge them during build time. So this is what happens.
To build the Kerberos Agent web app, you simply have to run the build command of yarn. This will create a build directory inside the web directory, which contains a minified version of the React application. Other than that, we also move this build directory to the machinery directory.
cd ui
yarn build
Building the machinery is also super easy 🚀, by using go build you can create a single binary which ships it all; thank you Golang. After building you will endup with a binary called main, this is what contains everything you need to run Kerberos Agent.
Remember the build step of the web part, during build time we move the build directory to the machinery directory. Inside the machinery web server we reference the build directory. This makes it possible to just a have single web server that runs it all.
cd machinery
go build
Inside the root of this agent repository, you will find a Dockerfile. This file contains the instructions for building and shipping Kerberos Agent. Important to note is that start from a prebuild base image, kerberos/base:xxx.
This base image contains already a couple of tools, such as Golang, FFmpeg and OpenCV. We do this for faster compilation times.
By running the docker build command, you will create the Kerberos Agent Docker image. After building you can simply run the image as a Docker container.
docker build -t kerberos/agent .
If you like our product please feel free to execute an Ethereum donation. All donations will flow back and split to our Open Source contributors, as they are the heart of this community.
Ethereum Address: 0xf4a759C9436E2280Ea9cdd23d3144D95538fF4bE
This repository contains the next generation of Kerberos.io, Kerberos Agent (v3), and is the successor of the machinery and web repositories. A switch in technologies and architecture has been made. This version is still under active development and can be followed on the develop branch and project overview.
Read more about this at the FAQ below.
This project exists thanks to all the people who contribute.