update getting started page
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Accounts"
|
||||
description: ""
|
||||
lead: ""
|
||||
date: 2020-10-06T08:49:31+00:00
|
||||
lastmod: 2020-10-06T08:49:31+00:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
vault:
|
||||
parent: "vault"
|
||||
weight: 306
|
||||
toc: true
|
||||
---
|
||||
|
||||
So just a short recap, an account allows something or someone to interact with Kerberos Vault, and store data in the authorized `Providers` and in a directory, the `Provider directory`, inside that `Provider`.
|
||||
|
||||
As explained before, you can choose in which directory, the `Provider directory`, an account can store the recordings. By defining a `Provider directory` you limit an account to have only access to this directory. On the other hand if you want to give an account more flexibility, and thus grant more access, you can use the `*` value for the `Provider directory` parameter. The latter will allow an account to write, in any subdirectory in the `Provider`.
|
||||
|
||||
Once an account is created it can be used in Kerberos Enterprise (and soon Kerberos Open Source) to persist your data from your Kerberos Enterprise agent into your own `Provider`.
|
||||
@@ -41,7 +41,7 @@ When installing Kerberos Vault in a cloud environment, following architecture ma
|
||||
|
||||
{{< figure src="vault-cloud-storage.svg" alt="Bring your own storage using Kerberos Vault" caption="Bring your own storage using Kerberos Vault" class="stretch">}}
|
||||
|
||||
On the other hand you could also have Kerberos Vault running at the edge, next to your Kubernetes Enterprise agents. This could be useful if you want to do processing or video analytics such as computer vision or machine learning at the edge.
|
||||
On the other hand you could also have Kerberos Vault running at the edge, next to your Kubernetes Enterprise agents. This could be useful if you want to do processing or video analytics such as computer vision or machine learning at the edge. Find more information about storage providers [on the providers page](/vault/providers).
|
||||
|
||||
{{< figure src="vault-edge-storage.svg" alt="Store your recordings at the edge with Kerberos Vault" caption="Store your recordings at the edge with Kerberos Vault" class="stretch">}}
|
||||
|
||||
@@ -56,9 +56,7 @@ Each time a Kerberos Agent sends a recording to Kerberos Vault, it is persisted
|
||||
- [Kerberos Hub](/hub/first-things-first/)
|
||||
- Kerberos Vault (remote forwarding)
|
||||
|
||||
Every time an event is delivered, it will be consumed by the configured integrations. For example in case of a Kafka integration, one can build a Kafka consumer with custom application logic; a notification manager, a machine learning service, etc.
|
||||
|
||||
Find more information about events and integrations on [the integrations page](/vault/integrations).
|
||||
Every time an event is delivered, it will be consumed by the configured integrations. For example in case of a Kafka integration, one can build a Kafka consumer with custom application logic; a notification manager, a machine learning service, etc. Find more information about events and integrations on [the integrations page](/vault/integrations).
|
||||
|
||||
{{< figure src="vault-integrations.svg" alt="Build integrations and create your own workflows using the event capability of Kerberos Vault." caption="Build integrations and create your own workflows using the event capability of Kerberos Vault." class="stretch">}}
|
||||
|
||||
@@ -80,7 +78,7 @@ Kerberos Vaults can be chained and configured in forwarding mode. This configura
|
||||
|
||||
{{< figure src="vault-forwarding-chaining.svg" alt="Synchronise recordings between multiple Kerberos Vault" caption="Synchronise recordings between multiple Kerberos Vault" class="stretch">}}
|
||||
|
||||
An example of remote forwarding is a machine learning filter. Recordings are stored in a Kerberos Vault at the edge, and are processed by a machine learning model. Every time the machine learning model finds a match, e.g. a pedestrian detected, it will forward the recording to Kerberos Vault in a cloud environment. By doing this you will send limited recordings (storage) into the cloud.
|
||||
An example of remote forwarding is a machine learning filter. Recordings are stored in a Kerberos Vault at the edge, and are processed by a machine learning model. Every time the machine learning model finds a match, e.g. a pedestrian detected, it will forward the recording to Kerberos Vault in a cloud environment. By doing this you will send limited recordings (storage) into the cloud. Find more information about forwarding on [the forwarding page](/vault/forwarding).
|
||||
|
||||
## Open API
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 417 KiB After Width: | Height: | Size: 417 KiB |
|
Before Width: | Height: | Size: 279 KiB After Width: | Height: | Size: 279 KiB |
|
Before Width: | Height: | Size: 279 KiB After Width: | Height: | Size: 279 KiB |
|
Before Width: | Height: | Size: 279 KiB After Width: | Height: | Size: 279 KiB |
|
Before Width: | Height: | Size: 303 KiB After Width: | Height: | Size: 303 KiB |
@@ -1,120 +0,0 @@
|
||||
---
|
||||
title: "Get Started"
|
||||
description: ""
|
||||
lead: ""
|
||||
date: 2020-10-06T08:49:31+00:00
|
||||
lastmod: 2020-10-06T08:49:31+00:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
vault:
|
||||
parent: "vault"
|
||||
weight: 301
|
||||
toc: true
|
||||
---
|
||||
|
||||
Once you've installed Kerberos Storage, you will have the Kerberos Storage web app running. This web app allows you to administrate Kerberos Storage. You can add storage providers, queues, accounts, and more from a single interface. Isn't that great.
|
||||
|
||||
Despite exposing a web app, Kerberos Storage also ships with a number of API's. These API's are exposed as, Swagger documentation, and can be used for extension and integration usecases. Think about following usecase..
|
||||
|
||||
> Having a couple of Kerberos Enterprise clusters installed, you could bring the recording of all your recordings at a single place. Next to that you would like to process every single recording being uploaded.
|
||||
|
||||
Having storage is just one thing, processing it with your own programming logical is what makes value.
|
||||
|
||||
> Using the concept of Queues, you could integrate with a Kafka queue, and receive real-time messages everytime a recording wa succesfully uploaded. Starting to process the different messages, you know which recordings were uploaded, and you can request the raw recording from Kerberos Storage, using one of it's API's. You could do with the recording what you want, in the programming language you prefer, and send the outcome of for example your highly customized machine learning algorithm to your own video analytics hub.
|
||||
|
||||
A [concrete tutorial can be found here](https://github.com/kerberos-io/storage/tree/master/examples/kafka-handler), it explains how to connect to Kerberos Storage, and run a color detection algorithm.
|
||||
|
||||
## Login page
|
||||
|
||||
Once you open a browser, and navigate to the Kerberos Storage web app (see installation for the URL), you will land on the login page.
|
||||
|
||||
{{< figure src="login.gif" alt="After successful installation you should be able to access the login page." caption="After successful installation you should be able to access the login page." class="stretch">}}
|
||||
|
||||
The default username and password of the Kerberos Storage app is:
|
||||
|
||||
- username: **root**
|
||||
- password: **kerberos**
|
||||
|
||||
> The username and password can be changed in the `deployment.yaml` file.
|
||||
|
||||
## License key
|
||||
|
||||
The first time you login you are asked for a license key, this can be obtained by sending a request to cedric@verstraeten.io, more information will be shared publicly soon. An example license key looks like this:
|
||||
|
||||
> -----BEGIN LICENSE KEY-----
|
||||
L/+DAwEBB2xpY2Vuc2UB/4QAAQIBB1BheWxvYWQBCgABCVNpZ25hdHVyZQEKAAAA
|
||||
/9z/hAFUPBAADG1haW4uTGljZW5zZf+BAwEBB0xpY2Vuc2UB/4IAAQIBB0NvbXBh
|
||||
bnkBDAABB0V4cFRpbWUBBAAAABb/ghMBCmtlcmJlcm9zaW8B/MC7ZzIAAf+AOaJ+
|
||||
8eU3OlZCphr4uJyH/PzfuDkMrqyfIsutc5kSz3rjsRtU4e6vETpHre8CPvFyx5w2
|
||||
0O8PKCIR4z1q28qJK2cvHQTK0/zf+KfYLilEcmNczLXgg+bnPvtA/bU/K8ZEwbnw
|
||||
Rta3+8zId+xtYQApdmHwo/Ih/vCN579iDeunwVQA
|
||||
-----END LICENSE KEY-----
|
||||
|
||||
{{< figure src="licensekey.gif" alt="Before you can access the Kerberos Vault system, you will need a license key." caption="Before you can access the Kerberos Vault system, you will need a license key." class="stretch">}}
|
||||
|
||||
Once you received a license key, and entered it into the web app you will be redirected to the login screen. Enter your credentials again, and you will land on the providers page (read more about it in the next chapter).
|
||||
|
||||
|
||||
## Providers
|
||||
|
||||
Providers are the actual datasource where you want to store your recordings. These providers could be a storage provider in the cloud or a storage provider on premise. By adding a provider, you have to provide credentials that allow Kerberos Storage to store recordings in that specific provider. Following provider are currently supported. You can choose from:
|
||||
|
||||
- [Google Cloud Platform Storage](https://cloud.google.com/storage)
|
||||
- [Microsoft Azure Storage](https://azure.microsoft.com/en-us/services/storage/)
|
||||
- [Amazon Web Services S3](https://aws.amazon.com/s3/)
|
||||
- [Minio](https://min.io/)
|
||||
|
||||
As explained before, for each provider, the appropriate security settings has to be filled in. For example for AWS you need to define the access and secret key, for GCP you need to define a service account.
|
||||
|
||||
A provider can be marked as temporary. This is helpful if you wish to store your recordings for a short period, and want to use it for processing purpose only. A benefit of doing this is reducing costs (if you host in the public cloud).
|
||||
|
||||
{{< figure src="provider.gif" alt="One or more providers can be configured to centralise your storage." caption="One or more providers can be configured to centralise your storage." class="stretch">}}
|
||||
|
||||
## Queues
|
||||
|
||||
Events or messages are generated each time a recording was uploaded to Kerberos Storage. These messages can be send to one ore more message brokers such as Apache Kafka or AWS SQS. From the interface you can setup the connection, and once configured events will flow to your predefined message brokers.
|
||||
|
||||
An example or usecase of Queues is already discussed at the beginning of this page. Another usecase is the development of our Kerberos Cloud offering. Each time a Kerberos Cloud customer is sending recordings to his or her Kerberos Cloud profile, it is stored inside Kerberos Storage, and [thus in one of our predefined providers](/storage/get-started#providers). After storing successfully, a real-time message is send into our private Kafka broker, which is starting a chain of processing in sequence but also in parallel:
|
||||
|
||||
- Metadata storage in MongoDB,
|
||||
- Notifications,
|
||||
- Classification with Tensorflow,
|
||||
- Counting algorithms,
|
||||
- and much more.
|
||||
|
||||
{{< figure src="queue.gif" alt="Kerberos Vault can be configured to send events to message brokers to create real-time apps of ML models." caption="Kerberos Vault can be configured to send events to message brokers to create real-time apps of ML models." class="stretch">}}
|
||||
|
||||
## Accounts
|
||||
|
||||
Having setup a `Provider` and a `Queue`, you also need to configure an account to interact with Kerberos Storage in a safe context. Creating an account allow you to do this. An account is the access point for end users to interact with your Kerberos Storage instance. On the Account page you can create one or more accounts and specify credentials for authentication and specific setting for authorization.
|
||||
|
||||
- Allowed providers,
|
||||
- Provider directory
|
||||
- Public Key,
|
||||
- Secret Key,
|
||||
- Day limit (the number of days a recording is stored.)
|
||||
|
||||
So just a short recap, an account allows something or someone to interact with Kerberos Storage, and store data in the authorized `Providers` and in an directory, the `Provider directory`, inside that `Provider`.
|
||||
|
||||
As explained before, you can choose in which directory, the `Provider directory`, an account can store the recordings. By defining a `Provider directory` you limit an account to have only access to this directory. On the other hand if you want to give an account more flexibility, and thus grant more access, you can use the `*` value for the `Provider directory` parameter. The latter will allow an account to write, in any subdirectory in the `Provider`.
|
||||
|
||||
Once an account is created it can be used in Kerberos Enterprise (and soon Kerberos Open Source) to persist your data from your Kerberos Enterprise agent into your own `Provider`.
|
||||
|
||||
{{< figure src="account.gif" alt="One or more accounts can be created to secure your storage access." caption="One or more accounts can be created to secure your storage access." class="stretch">}}
|
||||
|
||||
## Media
|
||||
|
||||
Once a recording is stored inside a specific `Provider` it will show up on the `Media` page. The `Media` page is an overview, list page, of all your recordings being uploaded to a `Provider`. It is used for quickly reviewing activity as for recycling, for the latter read more at the next paragraph.
|
||||
|
||||
{{< figure src="media.png" alt="All uploaded recordings are visualised through the media page." caption="All uploaded recordings are visualised through the media page." class="stretch">}}
|
||||
|
||||
## Recycle
|
||||
|
||||
Storing recordings in a `Provider` is one thing, making sure you manage the storage capacity of your `Provider` properly is also important. Storage might need to be recycled after a while because of several reasons:
|
||||
|
||||
- maybe the data is no longer relevant,
|
||||
- due to security or compliance,
|
||||
- reducing costs, etc.
|
||||
|
||||
To make this possible Kerberos Storage comes with a configurable recycle deployment, which you can run next to your Kerberos Storage deployment. [Learn more about recycling here](/storage/installation-recycle).
|
||||
|
After Width: | Height: | Size: 1.0 MiB |
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: "Getting Started"
|
||||
description: ""
|
||||
lead: ""
|
||||
date: 2020-10-06T08:49:31+00:00
|
||||
lastmod: 2020-10-06T08:49:31+00:00
|
||||
draft: false
|
||||
images: []
|
||||
menu:
|
||||
vault:
|
||||
parent: "vault"
|
||||
weight: 301
|
||||
toc: true
|
||||
---
|
||||
|
||||
Once you've installed Kerberos Vault, you should have access to the Kerberos Vault application. The application allows you to administrate Kerberos Vault, and more specifically create storage providers, integrations and accounts, through a single interface. Isn't that great.
|
||||
|
||||
Having a UI in place, it is important to note that Kerberos Vault also ships numerous APIs, that allow you to automate the configurations. The APIs are exposed as, Swagger documentation, and can be used for configuration of Kerberos Vault but also [integration](/vault/integration) and development of custom applications or business logic.
|
||||
|
||||
## Login page
|
||||
|
||||
Once you open a browser, and navigate to the Kerberos Vault web app (see installation for the URL), you will land on the login page.
|
||||
|
||||
{{< figure src="login.gif" alt="After successful installation you should be able to access the login page." caption="After successful installation you should be able to access the login page." class="stretch">}}
|
||||
|
||||
The default username and password of the Kerberos Vault app is:
|
||||
|
||||
- username: **root**
|
||||
- password: **kerberos**
|
||||
|
||||
> The username and password can be changed in the `deployment.yaml` file.
|
||||
|
||||
## Providers
|
||||
|
||||
Providers are the persistence layers, where you will store your recording in the edge or in a cloud environment. By adding a specific provider, credentials have to be provided to allow Kerberos Vault to store recordings in that specific provider. Following provider are currently supported. You can choose from:
|
||||
|
||||
- [Google Cloud Platform Storage](https://cloud.google.com/storage)
|
||||
- [Amazon Web Services S3](https://aws.amazon.com/s3/)
|
||||
- [Storj](https://storj.io/)
|
||||
- [Minio](https://min.io/)
|
||||
- [Ceph](https://ceph.io/)
|
||||
|
||||
As explained before, for each provider, the appropriate security settings has to be filled in. For example for AWS you need to define the access and secret key, for GCP you need to define a service account.
|
||||
|
||||
{{< figure src="provider.gif" alt="One or more providers can be configured to centralise your storage." caption="One or more providers can be configured to centralise your storage." class="stretch">}}
|
||||
|
||||
## Integrations
|
||||
|
||||
Events or messages are generated each time a recording was uploaded to Kerberos Vault, and are sent to one or more integrations. Those integrations are configured through the Kerberos Vault application. Each time a Kerberos Agent sends a recording to Kerberos Vault, it is persisted on a storage provider, and an event is triggered through one of the following integrations.
|
||||
|
||||
- [Apache Kafka](https://kafka.apache.org/)
|
||||
- [Amazon Web Services SQS](https://aws.amazon.com/sqs/)
|
||||
- [Kerberos Hub](/hub/first-things-first/)
|
||||
- Kerberos Vault (remote forwarding)
|
||||
|
||||
{{< figure src="integrations.gif" alt="Kerberos Vault can be configured to send events to message brokers to create real-time apps of ML models." caption="Kerberos Vault can be configured to send events to message brokers to create real-time apps of ML models." class="stretch">}}
|
||||
|
||||
The idea of an integration is that you can build your own applications and define custom business logic. Kerberos Agents and Kerberos Vault will make sure you have a scalable and high available backend, so you can focus on the business case and bring your own technologies (Python, Golang, etc). Examples of integrations are, but of course not limited too.
|
||||
|
||||
- Metadata storage in MongoDB,
|
||||
- Notifications,
|
||||
- Classification with Tensorflow,
|
||||
- Counting algorithms,
|
||||
- and much more.
|
||||
|
||||
## Accounts
|
||||
|
||||
Having setup `Providers` and `Integrations`, you need a secure way to interact with them through the creation of an account.
|
||||
|
||||
By creating an account you will receive credentials that give access to the Kerberos Vault's providers, integrations and APIs. Accounts credentials are being used by a Kerberos Agent to send recordings, and are used through API calls to download or forward recordings.
|
||||
|
||||
Next to credentials, there are a couple of other fields which are specified on account level.
|
||||
|
||||
- A provider,
|
||||
- the provider directory
|
||||
- a public key,
|
||||
- a secret Key,
|
||||
- a day limit (the number of days a recording is persisted),
|
||||
- cloud analysis,
|
||||
- edge analysis.
|
||||
|
||||
{{< figure src="account.gif" alt="One or more accounts can be created to secure your storage access." caption="One or more accounts can be created to secure your storage access." class="stretch">}}
|
||||
|
||||
## Media
|
||||
|
||||
Once a recording is stored inside a specific `Provider` it will show up on the `Media` page. The `Media` page is an overview, list page, of all your recordings being uploaded to a `Provider`. It is used for quickly reviewing activity.
|
||||
|
||||
{{< figure src="media.gif" alt="All uploaded recordings are visualised through the media page." caption="All uploaded recordings are visualised through the media page." class="stretch">}}
|
||||
|
||||
## Recycle
|
||||
|
||||
Storing recordings in a `Provider` is one thing, making sure you manage the storage capacity of your `Provider` properly is also important. Storage might need to be recycled after a while because of several reasons:
|
||||
|
||||
- maybe the data is no longer relevant,
|
||||
- due to security or compliance,
|
||||
- reducing costs, etc.
|
||||
|
||||
To make this possible Kerberos Vault comes with a configurable recycle deployment, which you can run next to your Kerberos Vault deployment. [Learn more about recycling here](/vault/recycle).
|
||||
|
After Width: | Height: | Size: 1012 KiB |
|
After Width: | Height: | Size: 456 KiB |
|
After Width: | Height: | Size: 3.5 MiB |
|
Before Width: | Height: | Size: 1.9 MiB After Width: | Height: | Size: 1.9 MiB |
|
Before Width: | Height: | Size: 3.4 MiB After Width: | Height: | Size: 3.4 MiB |
|
Before Width: | Height: | Size: 1.8 MiB After Width: | Height: | Size: 1.8 MiB |
|
Before Width: | Height: | Size: 934 KiB After Width: | Height: | Size: 934 KiB |
|
Before Width: | Height: | Size: 2.1 MiB After Width: | Height: | Size: 2.1 MiB |
|
Before Width: | Height: | Size: 1.5 MiB After Width: | Height: | Size: 1.5 MiB |
|
After Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 245 KiB After Width: | Height: | Size: 245 KiB |