Manage Users and Role-Based Access
Datasentinel provides role-based access control (RBAC) to restrict user access to PostgreSQL instances based on tags.
Datasentinel secures access through a credential-based login process and supports LDAP and Active Directory integration for centralized authentication.
Using role-based access control (RBAC) combined with instance tags, administrators can precisely control user access based on organizational needs, such as application ownership, cluster scope, or environment type.
Users
Default Administrator Account
When Datasentinel is installed, a default administrator account named datasentinel is created. This account is granted full administrative privileges.
Administrators can use this account to:
Create and manage users
Define and assign roles
Configure access control settings
Profiles
Datasentinel provides two user profiles that control access to dashboards and reports.
developer
Limited access to the Top Queries, Session History, and Top Tables / Indexes dashboards, as well as the corresponding PDF reports
data admin
Full access to all dashboards and PDF reports
Default profile: data admin
Privileges
Privileges define the actions a user is allowed to perform on the platform.
read
Read-only access to the platform
read write
Read access plus the ability to terminate sessions or backends from the UI
admin
Read-write privileges plus full platform administration
Default privilege: admin
Live360 Access
Access to the Live360 feature (direct access to PostgreSQL instances) can be enabled or disabled per user.
Enabled by default
Can be restricted for security or operational reasons
User Dashboard
All user accounts and their associated profiles, privileges, roles, and Live360 access settings are managed from the Users dashboard.
Roles
A role in Datasentinel defines a set of access rules based on instance tags.
Roles are created by associating one or more tag keys with specific values. These tag-based rules determine which PostgreSQL clusters are accessible to users assigned to the role.
By associating roles with users, administrators can restrict access to specific clusters in Datasentinel without managing permissions on a per-instance basis.
When creating a role, each tag key/value pair used in the role definition must already exist on at least one monitored instance.
After a role is created, any new instance whose tags match the role rules is automatically included in the set of instances authorized by that role.
Role management is available through both the platform UI and the API.
You can associate multiple tags to the same role and combine AND/OR conditions
Associating Roles with Users
Once a role is defined, it can be associated with one or more users.
A user can have multiple roles
The user’s effective access is the union of all role scopes
Removing a role immediately revokes access to the corresponding instances
This model allows flexible access patterns without duplicating role definitions.
API-Based Configuration Example
This example shows how to configure access programmatically using the API.
The goal is to create a user who has access only to PostgreSQL instances associated with the sales application, based on tag-based role assignment.
Declare a PostgreSQL Instance
In this step, an instance is declared associated with tags at creation time.
Create the instance declaration payload
The instance is tagged with application=sales. This tag will later be used by role definitions to control user access.
Register the instance using the API
Response
Once registered, the instance is immediately available in Datasentinel and automatically included in any role whose tag rules match application=sales.
Agentless vs Agent-Based Monitoring
This example demonstrates agentless monitoring, where PostgreSQL instances are declared directly through the API and monitored by Datasentinel platform.
When using local agents, instance declaration and tag configuration are handled at the agent level. Refer to the documentation for details on agent-based configuration.
Create a Role
In this step, a role is created using the API. The role is defined using tag-based rules and will grant access only to PostgreSQL instances whose tags match those rules.
In this example, the role allows access to instances tagged with:
application=sales
Role definition payload
The tags section defines the role scope.
Only instances whose tags match defined conditions are included in the role.
Create the role using the API
Response
Once created, the role dynamically applies to:
All existing instances tagged with
application=salesAny future instance registered with the same tag
Create a User and Assign a Role
In this step, a user account is created through the API and associated with the role defined.
The user is identified by an email address and inherits access restrictions from the assigned role.
In this example, the user will have access only to PostgreSQL instances tagged with application=sales.
User definition payload
The role association in the payload determines the scope of instances visible to the user.
Create the user
Response
The user can sign in using the specified email address and will have access only to PostgreSQL instances tagged with application=sales.
When creating a role, the referenced tag key/value pairs must already exist on at least one monitored instance. After role creation, any new instance matching the role rules is automatically included in the role scope.
Common Use Cases
Development-only access
Grant developers access only to non-production environments.
Role definition:
environment=development
Result:
The user can view metrics, sessions, and queries only for development instances.
Application-based access
Restrict access to a specific application across all environments.
Role definition:
application=inventory
Result:
The user can access all PostgreSQL instances related to the inventory application.
Primary and replica visibility
Grant access to both a primary instance and its read-only replicas.
Role definition:
cluster=orders
Result:
The user can analyze the consolidated workload across the primary and replica instances.
Best Practices for Role-Based Access Control
Default RBAC BehaviorTo ensure secure and maintainable access control:
Define a standard tagging strategy (environment, application, owner, cluster)
Use tags as the single source of truth for access control
Review roles and user assignments regularly
Consistent tagging is essential for predictable RBAC behavior.
Conclusion
Datasentinel enables fine-grained control of user access to PostgreSQL instances through tag-based roles, configurable via both the UI and the API for automation.
Last updated