yeah anything that requires sudo becomes difficult to recommand because there are so many trade-offs. I’m always wary about trying to automate solutions around sudo users and assets because inevitably it has security ramifications. So HUGE caveat on what I’m about to suggest.
Because of the way secure_path option works, it probably interferes with how sensu-agent updates the PATH. Assets are designed so that only the paths defined for the assets you need are prefixed into the default executable path. You definitely do not want to include all possible assets that are cached.
Instead of mucking with sudoers, try this workaround…
for example I’m able to run this check command using the system-profile-linux asset:
sudo PATH=$PATH bash -c "system-profile-linux"
All i had to do was give sensu user the agent is running as NOPASSWORD access to run commands, with no mucking with the secure-path
Now should this work? probably not this seems like a bug in the intent for secure_path, but it is what it is.
Now you may be able to go further and lock down that sensu user or group in sudoers further than I did, but the key is being able to pass the PATH the agent wants to run into the environment sudo is setting up that bash reads in. In fact there’s probably room to replace that bash call with a more restricted shell. Ultimately what is going on here is that sudo secure_path allows for bash to be run, and then the root user is just running commands under bash.
Like I said HUGE caveats here with regard to security. Once you let the sensu agent run bash under sudo you’ve got keys to the kingdom really you can basically run anything under bash like this. So please think this through and lock down the sensu user accordingly.