User for Remote UNIX - what permissions?

[gchastne]

Has anyone done any testing on the level of permission that the user requires in standard Linux Repo, UNIX versions?

The documentation states: "A user with permission to connect and run the required commands" which is kind of obvious, and I can see that it's a challenge for different UNIX/Linux to try and define it from a standard view.

Hence my question?

[Peter_Youssef]

Hello @gchastne 

• It's better to have a root user permissions to avoid future errors.
• Sudo or Su to execute the commands.
• It's recommended in both scenarios either for Extensions and OA Deployments.
• If you're referring different technologies monitoring through Hub via extension it depends on the user permissions required if a dedicated user will be created with different permissions for example Oracle DB monitoring  

Regarding the remote Unix monitoring: 

• A user with permission to connect and run the required commands
• Either a valid password or key for authentication
  • Note: Kerberos authentication (e.g. Centrify) is not supported for password authentication. In these cases using a certificate is recommended.
  • for full info refer to https://www.dynatrace.com/hub/detail/remote-unix-monitoring-20/?query=remote+linux&filter=all

KR, 

Peter.

[Peter_Youssef]

Hi @gchastne 

• As per the actual use case and monitoring requirements, It's recommended to refer to the related documentations and published info through the hub as some customers are sticking to the official publications as a reference to document each activity during the implementation.

Hoping it adds value.

BR,

Peter.

[gchastne]

I'm trying to bridge a gap in the documentation.

Currently all the hub says is: "A user with permission to connect and run the required commands"

and then gives a list of commands that the extension runs.

In the spirit of least privilege the user that we use should only be a special user if it needs to be.

From my reading the Remote UNIX commands on a Debian Linux box don't require su, so could get away with a normal user. Hence I'm reaching out to the community to see if others have validated that situation and/or extended that understanding to the broader UNIX base where the permissoins models are similar but not the same.

Debian Based Linux (Generic Linux)

• vmstat - does not need any special user rights on RedHat
• w - does not generally require su
• df - does not generally require su
• cat - does not generally require su
• top - does not generally require su
• pgrep - does not generally require su
• iostat - does not generally require su
  • for Red Hat Enterprise Linux systems you may need to install the sysstat package to collect disk IO metrics. No alternatives that exist by default were found.
• ip or netstat - sometimes requires su, but those times are for configuration changes, but maybe...
  • older OSs don't have required stats in 'ip' command and will 'fall back' to netstat

[Peter_Youssef]

Hello @gchastne 

Thanks for you detailed explanation, agree with you.

[MostafaHussein · Accepted solution]

as the product base for example in Debian there's a list of commands that's being used by the extension to monitor it remotely as the following figure, so you can grant the user to only has permissions to run these commands

so you've to grant permission to this user group in `/etc/sudoers` as the below:

%monitoring_group ALL=(ALL) NOPASSWD: /usr/bin/vmstat
%monitoring_group ALL=(ALL) NOPASSWD: /usr/bin/w
%monitoring_group ALL=(ALL) NOPASSWD: /usr/bin/df
%monitoring_group ALL=(ALL) NOPASSWD: /usr/bin/cat
%monitoring_group ALL=(ALL) NOPASSWD: /usr/bin/top
%monitoring_group ALL=(ALL) NOPASSWD: /usr/bin/pgrep
%monitoring_group ALL=(ALL) NOPASSWD: /usr/bin/iostat

or you can make some exercise to make a sudoer user that has all permissions granted in sandbox linux (like Centos) and create configuration in dynatrace to this sandbox vm and use this user, once monitoring is successfully let it run for 1 - 2 hours then back to it and check this file to track footprint of extension to know what's the activities and commands has been executed by this user `cat /va/log/auth.log` then start track it line by line to know what's the exact permissions need to be granted to commands or directories in specific.

BR,
Mostafa Hussein.

[JamesKitson]

I will add a note to the Hub tile on this. As a security best-practice we advise against using the root user or a user with sudo priviledges. During development of this extension we made a point to not use any commands that require such privileges and so using a root/sudo user is an unnecessary risk.