The datadog agent runs under the dd-agent user and dd-agent group. This prevents dd-agent accessing the logs in /var/log as they are only accessible by root (or a sudo admin).
Setting permissions using ACL's
In order to allow read only access for dd-agent only, create ACL's and modify logrotate to persist the permissions changes.
Verifying ACL's are enabled on your system
ACL's will need to be enabled on your file system to set permissions using the methods outlined in this article. You can verify ACL's are enabled by using the`getfacl` and `setfacl` commands to set permissions for the dd-agent user on a test directory. For example:
mkdir /var/log/test-dir
getfacl /var/log/test-dir/
setfacl -m u:dd-agent:rx /var/log/test-dir
getfacl /var/log/test-dir/
The permissions set for dd-agent will appear in the output of getfacl if ACL's are enabled.
For more information on enabling ACL's on your linux distribution please see the links at the bottom of this article.
Granting dd-agent read and execute permissions on log directories
Once you have verified ACL's are enabled, you can grant read and execute permissions for the dd-agent user on the appropriate directories for log collection. For example, if you wish to grant access to
/var/log/apache
, you would do so with the following command:
setfacl -m u:dd-agent:rx /var/log/apache
Setting permissions for log file rotation
Setting the permissions once will not persist for rotating logs, as logrotate will not re-apply the ACL setting. For a more permanent solution you can add a rule to logrotate to reset the ACL. You will need to create a new file:
sudo touch /etc/logrotate.d/dd-agent_ACLs
Example file:
{
postrotate
/usr/bin/setfacl -m g:dd-agent:rx /var/log/apache
/usr/bin/setfacl -m g:dd-agent:rx /var/log/nginx
/usr/bin/setfacl -m g:dd-agent:rx /var/log/myapp
endscript
}
Check the ACL status of a file with:
getfacl /var/log/<application-directory>
More information on ACL's
http://xmodulo.com/configure-access-control-lists-acls-linux.html
https://www.tecmint.com/secure-files-using-acls-in-linux/
Setting permissions when ACL's are not present
When ACLs are not present in a system, it may be possible to set permissions based on group access.
For instance, if your MySQL service is logging to the following locations:
/var/log/mysql/mysql_error.log
/var/log/mysql/mysql-slow.log
If we examine the permissions for the directory and files, you will find the permissions associated with user 'mysql' and the group 'mysql' by default. This logging scheme will deny access to the logs to any user not in the 'mysql' group. Typically you may see something like this:
$ ls -l /var/log | grep -i mysql
drwxr-x--- 2 mysql mysql 4096 Feb 20 06:25 mysql
The easiest path here is to associate the Datadog user 'dd-agent' with one of the administrative groups. By convetion, the 'adm' group is used for monitoring tasks. So the first step will be to add the users dd-agent and mysql to the adm groups.
$ sudo usermod -G dd-agent,adm dd-agent
$ sudo id dd-agent
uid=498(dd-agent) gid=498(dd-agent) groups=498(dd-agent), 4(adm)
And then we do the same with the mysql user:
$ sudo usermod -G mysql,adm mysql
$ sudo id mysql
uid=33(mysql) gid=33(mysql) groups=33(mysql), 4(adm)
Lastly, we modify the log rotation to ensure we write the subsequent logs appropriately. More specifically, in /etc/logrotate.d/mysql-server there should be something similar to:
/var/log/mysql/mysql_error.log /var/log/mysql/mysql-slow.log {
daily
rotate 7
missing ok
create 640 mysql adm
Compress
}
Each common-off-the-shelf application will follow a similar nomenclature. The advantage is that we avoid providing privileged access to an individual account and use a standardized practice. This will keep your audit rules in check.
The datadog agent runs under the dd-agent user and dd-agent group. This prevents dd-agent accessing the logs in /var/log as they are only accessible by root (or a sudo admin).
0 Comments