Clear sensitive env variables before spawning tentacle process

[wlthomson]

Fixes FD-620.

Background

The octopusdeploy/tentacle Docker image accepts registration credentials (ServerApiKey, BearerToken, ServerUsername, ServerPassword) via environment variables which are used once by configure-tentacle.sh to register the machine with Octopus Server. As these variables are not unset before the entrypoint execs into the long-running Tentacle process, they currently persist in that process's environment (and /proc/1/environ) for the container's entire lifetime.

This has non-trivial security implications: any deployment or runbook script that runs on that target/worker inherits these variables as a child process of Tentacle, effectively exposing a full Octopus Server credential to anyone who can get a script executed on the machine, regardless of how narrowly their actual deployment permissions are scoped (e.g. a deploy-only user restricted to a single project can end up with a credential that reaches every space on the instance).

This is not just a theoretical vulnerability: during testing I was able to exploit this to succesfully perform a privilege escalation attack by using a script step to echo out the sensitive variables from /proc/1/environ.

Results

Each entrypoint now clears the credential variables after registration is complete and before handing off to the long-running Tentacle process:

• Linux: unset ServerApiKey BearerToken ServerUsername ServerPassword inserted between configure-tentacle.sh and exec run-tentacle.sh.
• Kubernetes Agent: same unset, inserted after the registration if/else block (covers both the "already registered" and "fresh registration" paths) and before the final exec tentacle agent.
• Windows: Remove-Item Env:\... for all four variables, inserted between configure-tentacle.ps1 and run-tentacle.ps1 .

Manually tested by rebuilding the Tentacle image and unsuccessfully attempting to replicate the same privilege escalation attack as described previously.

NOTE: sensitive variables remain exposed to anyone with access to the Tentacle container via docker inspect / docker exec / kubectl describe pod. Whether this is an issue, and how we plan to fix it, is deliberately left as out-of-scope here.

Pre-requisites

• I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
• I have considered informing or consulting the right people, according to the ownership map.
• I have considered appropriate testing for my change.