I have a Powershell script that I wrote that does a nifty job of setting changes in a JSON config file.
It would be more convenient as a runbook for SREs. So, Jane has a need to change a production setting in several places and uses the runbook to accomplish this.
The runbook is a script that points to a specific server where a specific service is running and whose config needs to be updated.
My thinking was to deploy the script to a single tentacle server called ABC. ABC runs under a Windows domain service account. That account would execute the script, which uses Invoke-Command on the target server where the configuration sits.
ABC server becomes a kind of de facto tentacle for doing targeted script-based chores.
However, I’ve discovered this doesn’t work in practice because of permission issues. Powershell running on ABC that uses an invocation on server XYZ gets access denied. (I am assuming that the service account under which the tentacle is running has local rights to XYZ, etc.)
I could create a bunch of roles for specific tasks and dole them out to servers, but this would be a real headache. I just want an ABC server that can execute Powershell scripts that can touch other machines for things like configuration updates, service stops/restarts, etc.
Is anyone out there doing this type of thing or am I just barking up the wrong tree?
To make sure that I’m on the same page, I would like to re-iterate the problem you are describing.
It sounds like what you’re trying to accomplish is creating a runbook that would run on a worker that executes a powershell script that uses Invoke-Command to run a command on another server that is hosting a specific service that needs its config updated. However, you are running into issues because the Windows domain service account that the task is executed with on the worker does not have permissions on the server with the service.
Unfortunately, the ability to run a runbook against any target in an environment irrespective of target roles is something that is not currently supported as a first-class feature of runbooks. As you stated, if you wanted to run the runbook on a specific target, you would have to create a role for each target
However, there are a couple of workarounds that might help you accomplish what you’re trying to do.
A couple of my teammates put together a powershell module that you can use in your scripts to impersonate another user. You could use this module in the script that your runbook executes to execute the Invoke-Command as a user with privileges on the remote machine. Details about the module and how to use it can be found in this KB article -> How can I run a deployment or a script as a different user?
You could utilize the built-in script console feature in Octopus instead of a runbook. You wouldn’t get all the nice features that runbooks provide, such as project variables, script modules, and user permission, but it would allow you to run ad-hoc scripts against specific targets. More about the script console can be found here -> Script Console - Octopus Deploy
I hope that this helps. Please feel free to reach out if you have any other questions or if you need further explanation of the things I’ve talked about here.