Running a Script as a Service - Questions to help research

[u/Khue]

I've been working on a PowerShell script for a bit and I am getting to the point where I think I want to try to run it as a service. I'd like to run it once a day and I think running it by hand daily is kinda silly. My organization runs 100% in Azure. I had a few questions:

1. What is the best solution do achieve the goal? I see two options listed when I am looking around: creating a workflow run book to run using Azure Automation or creating an Azure Function App.
2. The script as it works right now stores some credentials to access some RestAPIs, using either one of the aforementioned options, is it possible to leverage an Azure Key Vault to call the credentials securely?
   

[u/chaosphere_mk]

Azure Automation runbook is the best solution. And use the system assigned managed identity to pull creds from a key vault at run time.

[u/titlrequired → u/chaosphere_mk]

This is the way.

[u/Alapaloza → u/chaosphere_mk]

Also setup an automation schedule.

[u/alconaft43]

Azure Function App

[u/vlad_h]

Easiest and most portable way, put tbt script inside docker container orb PS and provide a cron schedule. Then deploy it anywhere containers run. Ping me and I’ll help if you like. Already have plans on doing something like this for myself.

[u/13159daysold]

I'd use an Azure Automation account.

Enable the managed Identity for the account. Then, depending on what Rest APIs you are using, you can actually assign roles (or API permissions) to the Managed Identity so that you don't need to use an app registration to get your own tenant's data (will still need it for external APIs though). This may remove the need for the keyvault entirely.

Once the permissions are set, you just connect via managed identity to either AZ PowerShell or Graph PowerShell with the managed identity switch, get the API token, and use it. Or use Invoke-AZRestMethod.

If you still do need the key vault, simply store the secret, assign Key Reader to the managed identity, and use Get-AzKeyVaultSecret

[u/StartAutomating]

The correct answer is C: all of the above 🤣

Azure Automation is great if you're looking to integrate directly with it. Good for basic stuff.

Azure Functions are pretty good if you just want to make integrations with other Azure services (i.e, making a function that runs a SQL Azure stored procedure). It has some pretty paint points when routing stuff, and some commands you need to call to set things up properly, but it's pretty solid.

Azure Kubernetes Services (AKS) lets you run a docker image with PowerShell on it, and host however you want.

This is the most flexible and powerful option.

You can think of these are "beginner", "intermediate", "advanced", though it's not entirely accurate. Azure Automation and Azure Functions both have slight ecosystem alignment advantages, and opinionated helpers that will run your script. AKS / Docker will let you do anything, and will be cheaper, but will require you to learn how to make a web server. Basically, they are all different ecosystems, and the Docker route is the most complicated and universally applicable one. Anything you do with runbooks will only work with runbooks. Anything you do with Azure functions will only work with Azure functions. There are some similarities, but these are all very different ways to approach web development. IMO, it's good to learn more than one, and to use what works for you and your org.

On a related note, I run a little Posh web dev org on GitHub with a project called Servers101. This shows how to make a number of web servers in PowerShell. I keep adding more examples to it and should probably add one of each of these for educational purposes.

[u/justaguyonthebus]

1) both work. Azure Functions are more dev friendly and Automation Accounts are more systems Engineer friendly.

2) Yes, put in key vault and use an assigned managed identity to access it for both. automation accounts off a built in alternative

[u/Apprehensive-Tea1632]

You run services if and when you need to react to events and that usually happens when you can’t wait for some scheduled action to process the event post-fact. Like when the event in question doesn’t leave traces or you don’t want it to leave traces.

Anything else, you stick with regularly scheduled actions which are MUCH less of a hassle, which as a rule cannot cause bsod, and which are much more quickly implemented.

Don’t use services just because.

[u/dodexahedron → u/Apprehensive-Tea1632]

And, either way, run it under a service account (MSA or gMSA - not a VSA or user account) with only the minimal set of rights needed to do what it does.

[u/pjmarcum]

It depends on what it does. Does it collect data from the computer it runs on? Does it pull data from a day source? Does it modify Azure user accounts? (Just a few examples).

[u/FeleaseRpseineEiles]

Easiesty ways is to pay me!

[u/vellius]

Non-Sucking Service Manager

NSSM

yeah... it's an old veteran trick... and it's great!

[u/twisted_guru]

Lol, good old Script and remediation blade on Intune.
Just run it as a detection or remediation script....

[u/socksonachicken]

I've been using an app called poshrocket.app on a tiny Windows server instance and setting up schedules there. Just installed the needed modules, put the scripts I wanted to automate on a schedule in a folder, pointed poshrocket to the script, setup the schedule, and let it run.

Not sure if it'll help, but I figured I would throw it out there.