Some of the services we'll leverage such as MongoDB or Minio require storage, to persist their data safely. In a managed Kubernetes cluster, the relevant cloud provider will allocate storage automatically for you, as you might expect this is not the case for a self-hosted cluster.

Therefore we will need to prepare some storage or persistent volume. To simplify this we can leverage the OpenEBS storage solution, which can automatically provision PV (Persistent volumes) for us.

Let us start with installing the OpenEBS operator. Please note that you might need to change the mount folder. Download the openebs-operator.yaml.

wget https://openebs.github.io/charts/openebs-operator.yaml

Scroll to the bottom, until you hit the StorageClass section. Modify the BasePath value to the destination (external mount) you prefer.

#Specify the location (directory) where
# where PV(volume) data will be saved.
# A sub-directory with pv-name will be
# created. When the volume is deleted,
# the PV sub-directory will be deleted.
#Default value is /var/openebs/local
- name: BasePath
  value: "/var/openebs/local/"

Once you are ok with the BasePath go ahead and apply the operator.

kubectl apply -f openebs-operator.yaml

Once done it should start installing several resources in the openebs namespace. If all resources are created successfully we can launch the helm install for MongoDB.

MongoDB

When using Kerberos Vault, it will persist references to the recordings stored in your storage provider in a MongoDB database. As used before, we are using helm to install MongoDB in our Kubernetes cluster. Within the Kerberos Vault project we are using the latest official mongodb driver, so we support all major MongoDB versions (4.x, 5.x, 6.x, 7.x).

Have a look into the ./mongodb/values.yaml file, you will find plenty of configurations for the MongoDB helm chart. To change the username and password of the MongoDB instance, go ahead and find the attribute where you can change the root password. Please note that we are using the official Bitnami Mongodb helm chart, so please use their repository for more indepth configuration.

Next to that you might also consider a SaaS MongoDB deployment using MongoDB Atlas or using a managed cloud like AWS, GCP, Azure or Alibaba cloud. A managed service takes away a lot of management and maintenance from your side (backups, security, sharing, etc). If you do want to install MongoDB in your own cluster then please continue with this tutorial.

helm repo add bitnami https://charts.bitnami.com/bitnami
kubectl create namespace mongodb

Note: If you are installing a self-hosted Kubernetes cluster, we recommend using openebs. Therefore make sure to uncomment the global.storageClass attribute, and make sure it's using openebs-hostpath instead.

helm install mongodb -n mongodb bitnami/mongodb --values ./mongodb-values.yaml

Once installed successfully, we should verify if the password has been set correctly. Print out the password using echo $MONGODB_ROOT_PASSWORD and confirm the password is what you've specified in the values.yaml file.

export MONGODB_ROOT_PASSWORD=$(kubectl get secret -n mongodb mongodb -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)
echo $MONGODB_ROOT_PASSWORD

Config Map

Kerberos Vault requires a configuration to connect to the MongoDB instance. To handle this configmap map is created in the ./mongodb/mongodb.config.yaml file. However you might also use the environment variables within the ./kerberos-vault/deployment.yaml file to configure the mongodb connection.

Modify the MongoDB credentials in the ./mongodb/mongodb.config.yaml, and make sure they match the credentials of your MongoDB instance, as described above. There are two ways of configuring the mongodb connection, either you provide a MONGODB_URI or you specify the individual variables MONGODB_USERNAME, MONGODB_PASSWORD, etc.

As mentioned above a managed MongoDB is easier to setup and manage, for example for MongoDB Atlas, you will get a MongoDB URI in the form of "mongodb+srv://xx:xx@kerberos-hub.xxx.mongodb.net/?retryWrites=true&w=majority&appName=xxx". By applying this value into the MONGODB_URI field, you will have setup your MongoDB connection successfully.

    - name: MONGODB_URI
      value: "mongodb+srv://xx:xx@kerberos-hub.xxx.mongodb.net/?retryWrites=true&w=majority&appName=xxx"

Once you applied this value, the other values like MONGODB_USERNAME, MONGODB_PASSWORD and others will be ignored. If you don't like the MONGODB_URI format you can still use the old way of defining the MongoDB connection by providing the different values.

    - name: MONGODB_USERNAME
      value: "root"
    - name: MONGODB_PASSWORD
-->   value: "yourmongodbpassword"

Create the config map in the kerberos-vault namespace.

kubectl create namespace kerberos-vault
kubectl apply -f ./mongodb-config.yaml -n kerberos-vault

Deployment

To install the Kerberos Vault web app inside your cluster, simply execute below kubectl command. This will create the deployment for us with the necessary configurations, and exposed it on internal/external IP address, thanks to our LoadBalancer MetalLB or cloud provider.

kubectl apply -f ./kerberos-vault-deployment.yaml -n kerberos-vault

Access the Kerberos Vault

If you have chosen to use the NodePort configuration you should be able to reach the Kerberos Vault using the http://localhost:30080 endpoint in your browser. However if you have a server installation without a GUI, you might choose to do a reverse proxy so you can open the browser on your local machine.

ssh -L 8080:localhost:30080 user@server-ip -p 22

MinIO storage provider

kubectl create namespace minio-tenant

kubectl apply -f minio-storageclass.yaml

# This will create the operator
kubectl kustomize github.com/minio/operator?ref=v6.0.1 | kubectl apply -f -

# Install the tenants
kubectl apply -f tenant-base.yaml

# Watch the tenant creation
watch kubectl get all -n minio-tenant

Configure the Kerberos Vault

..... (should be done through env files so we do not need to get in the UI)

README.md

Edge deployment on k8s

Kerberos Vault

OpenEBS