Published
Your reporting dashboard needs to read the graph. Your application needs to update it. Neither needs to spend its afternoon creating administrators.
That is where role-based access control, or RBAC, comes in. Galactus DB lets you give people and applications the permissions they need through users and roles. It is a bit like handing out keys: the person checking the stockroom does not automatically need a key to every cupboard in the building.
A role for the job
Imagine a team working with an analytics database:
- The analyst explores connections and builds reports. Reading the graph is enough; accidentally editing it is not part of the job description.
- The application adds and updates data. It needs read and write access to its database, without permission to manage everyone's accounts.
- The administrator manages users, roles and access. Those responsibilities can stay separate from the accounts used by everyday applications.
A role groups permissions together. Assign it to the people who need it, and you can manage access without rebuilding the same collection of grants for every new teammate.
Give the analyst a key
Galactus DB uses a supported subset of Neo4j's security Cypher, so the commands
may already look familiar. Suppose you have a database called analytics and a
user called analyst. As an administrator, run these statements separately:
CREATE ROLE analytics_reader;
GRANT ACCESS ON DATABASE analytics TO analytics_reader;
GRANT MATCH {*} ON GRAPH analytics TO analytics_reader;
GRANT ROLE analytics_reader TO analyst;
The role lets the analyst connect to analytics and read its graph. It grants
no write access or access to other graphs. If the user already has other roles,
their grants also contribute to what that user can do; an applicable DENY
takes precedence.
For the full setup, including creating users and choosing a home database, follow the permissions guide.
Your graph, your boundaries
Permissions currently work at the whole-database and system levels. You can decide who reads or writes a database, who manages its indexes, and who manages users and roles across the server.
Label and property restrictions are for later. A read grant today covers the whole selected graph, so it is worth choosing your database boundaries with that in mind.
New users created through Cypher start without graph read or write privileges. You choose their access deliberately, rather than discovering that the new reporting account has been handed the master key.
Keep a key for yourself
Permissions are useful until somebody accidentally locks the entire team out. Galactus DB protects the last active security administrator from removing their final administration permissions. Self-deletion and self-suspension are blocked too. Even administrators have the occasional ambitious Friday afternoon.
Keep a second administrator and a recoverable backup anyway. A guardrail is helpful; a spare key is still a good idea.
Existing bootstrap and legacy-provisioned users retain full privileges when moving to RBAC. You can review those accounts and assign more focused roles as you go. Users, roles and grants persist across restarts on a durable instance; the upgrade notes cover the details for existing installations.
Start with the jobs your people and applications actually do, give each a role that fits, and leave the master key with the people who need it.