Channels
announcements
automation-api
aws
azure
blog-posts
built-with-pulumi
cloudengineering
cloudengineering-support
content-share
contribex
contribute
docs
dotnet
finops
general
getting-started
gitlab
golang
google-cloud
hackathon-03-19-2020
hacktoberfest
install
java
jobs
kubernetes
learn-pulumi-events
linen
localstack
multi-language-hackathon
office-hours
oracle-cloud-infrastructure
plugin-framework
pulumi-ai
pulumi-cdk
pulumi-cloud
pulumi-crosscode
pulumi-deployments
pulumi-kubernetes-operator
pulumiverse
python
registry
status
testingtesting123
testingtesting321
typescript
welcome
workshops
yaml
Title
m
millions-journalist-34868
04/27/2020, 2:21 PMWhat are the recommanded roles / permissions to give to the azure service principal that needs to be created to deploy azure ressources with Pulumi ? I was using my administrator account with az cli for pulumi deployments until now but now that I am using Azure DevOps, I had to create a Service Principal. However there are some permissions missing for my Service Principal.
As my ressource group is created through pulumi, I had to give the contributor role on my subscription to the SP. However it seems it's not enough for creating an app registration in AD.
b
better-rainbow-14549
04/27/2020, 3:11 PM'contributor' can do anything except change permissions, 'owner' can do that
and yeah it's a question we're worrying about also, we have segregated CI service principals for pulumi to act as but they can't even really create a resource group so its a chicken and egg situation
we're leaning towards having one stack which creates all the resource groups and gives another service principal owner over them individually
then the actual resource stacks act on one resource group alone
m
millions-journalist-34868
04/28/2020, 7:18 AMI see, interesting way of handling this. However, it has some limitations, for instance when I think of projects where ressources for one environment are split in multiple ressource groups, I don't want one SP by RG. And I don't want all my projects for different clients to be in the same global stack.
I ended up giving the permission that was missing ("Azure Active Directory : Application.ReadWrite.") to my SP and letting him the Contributor role on my subscription. It seemed to be the easiest for me if I want it to be able to create and populate my RG.