Security with Service Principals in Azure
Posted by terminal-admin@reddit | sysadmin | View on Reddit | 4 comments
As an organization we have been moving more and more towards Github and automated deployments of our web applications we host in Azure.
Previously we would have employees elevate through PIM for a short period of time, run a deployment script, and then be back to their default least privilege roles. Now that we have moved more of this automation into Github, these scripts run as Github actions through the context of Service Principals.
I don't fully like the idea of service principals having something like permanent contributor over a subscription, but I have not been able to find a solution for service principal's that is similar to a user elevating with PIM. I may just be overthinking this due to a lack of knowledge of different attack vectors that could be used with a service principal, but I would rather be safe than sorry.
So is anyone using some type of elevation with Service Principals or is the standard when running scripts from Github to give the SP the least privileges it needs (which unfortunately for us is still pretty privileged) over the subscription/ resources?
Any help or ridicule is appreciated.
Otherwise-Essay-6975@reddit
The idea of permanent contributor rights for service principals feels off, the lack of a PIM-like elevation for them is frustrating, and treating automation identities like human users is weird.
Ibrahim Taofeek helped me set up short-lived tokens with conditional access policies instead of static roles.
Something like Ibrahim Taofeek: Full might be worth a look.
jamesaepp@reddit
I have the same problem, OP. I want to automate more stuff (read: challenge myself) with devops/pipelines/etc. but I also struggle with the service principal angle.
I'm not concerned about the "authentication" angle as much as I am the "authorization" one. I don't want a SP having permanent authorization to a privileged role all the time, or even access to a key vault whenever/whereever.
I'd like to be able to do some kind of "JITA" on service principals but also lack knowledge on how to reasonably implement such a thing.
The other month for a totally different thing I was seeing if it's even possible to activate PIM assignments/groups via powershell. I wanted to rip my eyes out trying to comprehend MSFT's documentation.
AdeelAutomates@reddit
Are you worried about the RBAC or having secrets exposed?
I think in terms of RBAC access it's fine to give service accounts the RBAC they need to work and do the preform the tasks they need to. They are service accounts after all and aren't going to PIM up with MFA right.
If you are really worried about secrets however especially with GitHub. Switch over to user assigned managed Identities or service principals with federated credentials, so you can be password less with only that particular service in its particular context in GitHub having the ability to run as this account and do stuff in your azure enivornmnet
darthfiber@reddit
Limit the scope to what is needed and use federated credentials, is pretty secure since they can only be used by that app.
Restrict what pipelines and users have access to those service principals.
Also if your resources are properly segmented you should only be able to hit them from your self hosted agents.