Arctic DBM Design Review Document

Context

For database access, there are three “planes” which you have to solve for:

• Dataplane - how we query and update the data itself
• Management - how we grant access on a granular level using RBAC
• Proxy - how we filter queries coming in based on the request itself and user authorization

There are few problems we are trying to solve here:

• Limiting database server nodes
• Limiting user access to a table and eventually on a column basis
• Try to filter out common SQL attacks before they even hit the database itself
• Allow microservices to talk on HTTP like they typically do with each other
• Make it easy to migrate from DB libraries to this with a client example and a legacy adapter

The idea came when there was two environments not directly connected which needed to talk to each other. Each environment only had a web reverse proxy.

Architecture

Data Flow Diagram

An optional LoadBalancer is called out here. For our main thoughts, ArticDBM would be in its own namespace within Kubernetes. Databases would be in a separate one which will only communicate with ArticDBM Namespace. This allows for monitoring in between namespaces to be available if necessary via network policies.

Arctic DBM Server

This is a server which tackles the API to DB and DB Proxy/Filtering.
It contains the mapping of DBs, users, application, etc. and makes DB connections more secure as well as web based.

Authentication

For MVP - authentication will be basic user authentication. On server standup, through environment variables, a root user will be created. It can then be used to create other users.

Roles

Administrator - Can update and user, database, etc.
Developer - Can create and update their own databases only
Reporter - Can query databases but not update nor create them

Arctic’s own DB Design

This is the design which ArticDB will use to store it’s own data, by default in SQLITE
Database: ArticDB

Table	Column	PyDAL Type	Notes
Admin	Username
	Password
	IP	str	CIDR format
	Permissions	RO / Limited / Admin
Databases	Name
	Type
	User
	options
Tables	Name
	Db
	User	if blank - default DB user
	columnDefs	dictionary/json
Hosts	dbHost	str
	dbPort	int
	dbType	str
	dbUser	str
	dbPassword	password
	dbTLS	boolean	FUTURE
	dbOptions	List: string	Any additional options for the DB (ie: ISO) - FUTURE

API Design

ADMIN

/admin/user/add (Adds or updates user)  
{ username, password, role }

/admin/user/del (deletes user)  
{ username }

DB

/db/add (Create/Update DB)  
{ dbname:str, dbType:str, user:liststr, options\*:json }

/db/del (delete DB)  
{ dbname:str }

/db/table/add (Create / update table)  
{dbName:str, tbName:str, columns:json{name:pydalType}, user\*:liststr }

DATA

/{{dbname}}/{tableName}/query (pull data)  
{columns:liststr, condition: str}

/{{dbname}}/{tableName}/update (Update existing)  
{columns:liststr, condition: str}

/{{dbname}}/{tableName}/insert  
Json{column:data…}

DBHOST

/host/add (Create and update)  
{dbFQDN, dbPort, dbUser, dbPass, dbPyDALType, dbTLS,}

/host/del (Delete)  
{dbFQDN}

ArticDBClient

This would be a python client which makes it easy to request data from databases using a simple yaml configuration file. These would utilize requests library.

There would be 3 clients in total:

• Embedded python library
• Legacy Network Adapter
• Initialization Client

Config Examples

Basic Config

---
ArticHost: somedomain.localnet  
ArticPort: 38306  
ArticDB: somedb  
API: REST

Initialization Config

---
ArticHost: somedomain.localnet
ArticPort: 38306
ArticDB: somedb
API: REST
Initialize:
  Tables:
    Sometable:
      Columns:
        - Name: str
        - Address: str
      Users:
        - Someuser
        - Someuser2

Future Vision

gRPC

Add an additional gRPC endpoint on the server and add it to the clients as preferred method. This will increase speed and somewhat protect the data across the wire better too.

Authentication

Eventually we want to allow for LDAP / SAML / OAUTH2. We also want to enable user filtering on a row and column basis