Find out how to secure, manage and automate access to Datasentinel platform
How does Datasentinel secure user access to its platform and control who accesses monitored PostgreSQL instances?
For example, some users only need access to the activity statistics of the clusters attached to an application. Others only need access to non-production instances.
The selection criteria are limitless and completely customizable
This article describes How to manage Datasentinel users as well as its Role Based Access feature.
This feature is based on the association of tags with each monitored instance allowing them to be identified according to certain criteria
(See How to use TAGs efficiently)
The users
The platform is delivered with a default account named datasentinel. This account is an administrator of the platform and can therefore be used for the configuration of roles and users.
1. There are 2 user profiles, allowing access to certain dashboards to be restricted
Profile | Description |
---|---|
developer | Limited access to Top queries, Sessions Workload, Top tables / indexes dashboards as well as the corresponding reporting in PDF format |
data admin | Access to all dashboards as well as reporting in PDF format |
Default profile: data admin
2. There are 3 privileges:
Privilege | Description |
---|---|
read | Read only access to the platform |
read write | read privilege + possibility of kill sessions / backends from the GUI |
admin | read write privilege + platform administration |
Default privilege: admin
3. Accessibility to the Live360 feature (Direct access to instances) can also be configured. (Enabled by default).
User dashboard:
The roles
Roles are a collection of values associated with tags. You can create your own roles.
They allow you to limit access to certain PostgreSQL clusters from Datasentinel by associating them with users.
This role management can be done from the interface or via the available API, allowing you complete automation.
You can associate multiple tags to the same role and combine AND/OR conditions. See Documentation
If you want to create one or more roles from the GUI, the tags must already be present, i.e. already associated with monitored instances, unlike management via API
API management example
The example below creates a user with access only to Postgres instances associated with the sales application.
You must first generate an access token with an administrator account.
The access token is valid for 24 hours.
Shell example:
curl -sk -u datasentinel:$PASSWORD -X POST https://$DATASENTINEL_HOST/ds-api/user-token
# Answer
{
"user-token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2MjY3OTg1MjIsImlhdCI6MTYyNjcxMjExNywiZGF0YWJhc2UiOiJkcy1kYXRhIiwiZW1haWwiOiJjb250YWN0QGRhdGFzZW50aW5lbC5pbyIsInVzZXIiOiJkYXRhc2VudGluZWwifQ.YhKtqrx0O3_gw63dIFCW30ScI8yS-_QY1dss3rRNZNI"
}
Declaration of a Postgres instance to monitor.
The sales value is associated with the application tag in the tags property.
Shell example:
TMP_JSON_FILE=/tmp/connection.json
CONNECTION_NAME=pg-sales-production
cat > $TMP_JSON_FILE <<EOF
{
"host": "51.158.70.115",
"port": 9342,
"user": "datasentinel",
"password": "sentinel",
"tags": "application=sales"
}
EOF
curl -sk --header "user-token: $ACCESS_TOKEN" --header 'Content-Type: application/json' -X POST https://$DATASENTINEL_HOST/ds-api/pool/pg-instances/$CONNECTION_NAME -d @$TMP_JSON_FILE
# Answer
{
"status": "Connection created and connected!"
}
The example above involves managing the instance in Agentless mode .
If you are using local agents, the instance declaration is done at the agent level. (See Documentation)
Creating a role
The role sales-role is created with as filters a tag named application with the value sales.
For more complex management (for example associating several tags with a role), refer to the Documentation
Shell example:
TMP_JSON_FILE=/tmp/role.json
ROLE_NAME="sales-role"
cat > $TMP_JSON_FILE <<EOF
{
"access": [
{
"filters": [
{
"tag": "application",
"value": "sales"
}
]
}
]
}
EOF
curl -sk --header "user-token: $ACCESS_TOKEN" --header 'Content-Type: application/json' -X POST https://$DATASENTINEL_HOST/ds-api/roles/$ROLE_NAME -d @$TMP_JSON_FILE
# Answer
{
"status": "Role sales-role created successfully"
}
Creating a user with access restriction
The creation of a user is done with his email address.
The association of the role previously created will restrict access to instances whose property (or TAG) application is equal to sales.
For complete management, refer to the Documentation
Exemple shell:
TMP_JSON_FILE=/tmp/user.json
ROLE_NAME="sales-role"
USER_EMAIL="jean.lapioffe@company.com"
cat > $TMP_JSON_FILE <<EOF
{
"password": "myPassword",
"role": "$ROLE_NAME"
}
EOF
curl -sk --header "user-token: $ACCESS_TOKEN" --header 'Content-Type: application/json' -X POST https://$DATASENTINEL_HOST/ds-api/users/$USER_EMAIL -d @$TMP_JSON_FILE
# Answer
{
"status": "User with login jean.lapioffe created successfully"
}
The newly created user can now connect to the Datasentinel interface with his email address or with the login displayed.
This user only has access to instances whose tag application = sales
Datasentinel home pagel:
Find the complete API usage documentation. (See Documentation)
Full examples of API usage are also available. (Cf Datasentinel Toolkit)
Conclusion
Datasentinel allows nominative management of users with access restriction.
This platform access management can be done via an API allowing full automation.
Datasentinel unique features and the simplexity of its GUI allow a quick start to easily and precisely analyze the workload of all your Postgres instances, HA or not
Stay connected!
If you are an Amazon Web Services customer, Datasentinel is also present on the AWS marketplace allowing you to have a platform available in a few clicks