Getting Started

If you do not want to install at the suggested addresses, you need to update the service addresses in config files.

Installations

List of statically referenced services:

Service	IP	Port
redis	10.0.1.14	6379
openbao	10.0.1.95	31710

Openbao

See docs

An open source KMS solution.

For authentication, you can use app roles. Each app role can have access policies.

For secret mount name, you can use default /secret path. Then you can create policies for each environment.

Policy	Path	Permissions	Desc
dev_read_only	/secret/dev/*	read, list, scan	For read only permission on dev env
dev_rw	/secret/dev/*	create, read, update, patch, delete, list, scan	For read-write only permission on dev env
stage_read_only	/secret/stage/*	read, list, scan	For read only permission on stage env
stage_rw	/secret/stage/*	create, read, update, patch, delete, list, scan	For read-write only permission on stage env
prod_read_only	/secret/prod/*	read, list, scan	For read only permission on prod env
prod_rw	/secret/prod/*	create, read, update, patch, delete, list, scan	For read-write only permission on prod env

Then you can create app roles with some policies attached to them. After that you can create app role secret, secret will be exposed once and, you need to safely copy this information for later use.

It is recommended to separate stage and production environments and give read only permission if the service running in the server don't need to write anything to openbao. Servers must have the following environment variables added to their ~/.bashrc file.

Env variable	Desc
OPENBAO_APPROLE_ID	Openbao app role id
OPENBAO_APPROLE_SECRET_ID	Openbao app role secret id

Note: Add the custom environment variables to start of the ~/.bashrc file to load them properly on non-interactive shell sessions. Before the following lines to be exact.

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

If a service(almost all) needs some secret data(passwords, keys, tokens, etc.) to carry out its operations, it will load them from openbao on startup. The secrets are referenced with a specific format, see secret manager documentation for details. Secret manager will parse the config file any detect the strings with the matching format and load secrets from corresponding paths and replace the formatted secret manager strings with secret values.

You can insert the initial secrets(postgres, rabbitmq, etc.) to already referenced locations in openbao for quick start.

Redis

See docs

Pretty much plug and play. If you change the location of the service you need to update the config files.

RabbitMQ

See docs

Similar to redis, plug and play. But RabbitMQs' location and credentials are stored in openbao too. You can install it where ever you want as long as you insert the correct location info to openbao.

Postgres

See docs

Location and credentials are stored in openbao. You can install it where ever you want.

Dynamic Communication

For inter-service communication, services will either use redis channels or ZNS. ZNS is an in-memory nameserver-ish solution for dynamic communication. Service locations are loaded from database on startup and inter-service socket connections and HTTP requests are made with service codes instead of ip:port pairs. If a service needs to communicate with others it will load ZNS records from database to its memory on startup and if table gets updated it will automatically update in-memory records with live change relay updates.

ZNS will need service and load balancer records in zns table in database to properly function. Without this services won't be able to locate each other. See the implementation in core package for further details.