Enhancement Request: Allow Agent to generate symlinks for asset binaries on install.

[jspaleta]

Allow agent to create symlinks to asset binaries into a common directory at asset install time.

Motivation: Some common operations like filesystem or memory checks require privileged operation on linux systems, so its an existing common practice to run some sensu-plugins checks setuid or under sudo if needed. This is much harder to do with assets currently because the shasum is part of the binary path. Sudo rules would have to be updated in conjunction with asset updates.

Goal: Make it possible for operators to use assets in privileged operations using full path sudo rules to symlinked binary locations that will continue to work after asset upgrades.

Benefits:

• Agent generated symlinks would be usable sudo even across asset updates where the 512sum changes.

Limitations:

• Might not be a workable pattern for container workloads, this needs some discussion.
• Unclear if this pattern will work on WIndows, needs some discussion
• Potentially racy if operators have multiple assets in use with same binary names. Unlikely but possible.

Security Impact: Because the automatically generated symlinks are not privileged themselves, there is no additional impact on security footprint. The security impact is directly related to the sudo rules that the local operator must choose to create in order to enhance the privileges before making use of the symlinks in a check definition.

Strawman proposal(s):

1. Allow operators to configure agent to enable/disable asset symlinks, and optionally define a symlink directory to populate with symlinks for all downloaded asset binaries. Effectively 2 different agent config settings needed.

2. Allow operators to configure asset definitions with full path symlink directory to populate as am override on an asset by asset basis. This could be implemented as an asset annotation with no changes to current asset spec. Only used if agent has asset symlinks enabled. This helps mitigate potential of multiple assets with the same binary racing the generated symlink.

3. Forbid the asset specific symlink directory override annotation from being populated in any Bonsai generated configs. This should be an advanced local operator only feature.

4. Local admin is responsible to ensure symlink directories are writble by user running sensu-agent service. If symlink creation fails...report as new type of asset install error.

   Context

   Long discussion in Slack on how to use assets for privileged operations: https://sensucommunity.slack.com/archives/C9BB9AW7K/p1560289972066700

[calebhailey]

Related: https://github.com/sensu/sensu-go/issues/2315

[sensu-discourse]

This issue has been mentioned on Sensu Community. There might be relevant details there:

https://discourse.sensu.io/t/sensu-go-plugin-distribution-model/1724/10

[jspaleta]

Update on this... If we implement binary executable symlinks we should probably have the symlink directory encode the namespace in which the asset resource exists.

Rationale:

1. Backends are inherently multi-namespaced and we don't want handlers from different namespaces clobbering each other's symlinks.
2. Agents are probably going to grow multiple namespace capability at some point, so lets plan for that now.

Updated Straw Proposal

1. have backend and agent configuration allow for boolean to enable/disable asset binary symlinks.
2. have symlink directory structure exist inside the cache directory for backend/agent.. default for agent would look like this: /var/cache/sensu/sensu-agent/asset-exec-symlinks/<namespace>/ default for backend would look like this: /var/cache/sensu/sensu-backend/asset-exec-symlinks/<namespace>/
3. This would allow operators to configure there sudoers file to include a sacure_path to include each namespace they want to support.

[tarcinil]

I am seeing issues with this as well.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.