This message was deleted.
# blog-posts
s
This message was deleted.
🚀 2
meow party 1
l
@millions-journalist-34868 This is a super-helpful article. Thanks for writing it. I've been wanting to move to the OIDC approach for Github Actions => Azure for a while. I think I finally understand it, but there's still some inertia in making it happen. Two things stood out as points that would be helpful. 1) This is minor, but you didn't mention Pulumi stack passphrases. I think those are important when using secrets in Pulumi stack configs. 2) This is more significant. You don't explain what permissions are required to run the initial
pulumi up
which creates the AAD application, service principal, and federated identity credential, along with the role assignment. It's not enough to be an "owner" on the subscription. There's a minimum level of permissions within AAD needed to create those objects. And I don't know what that minimum level is. In tenants that I initially created and am essentially "super admin" in AAD, I can do it. But in tenants created by others and where I'm just a guest in AAD, I can't. I'd love to know the minimum level of permissions needed so I could request them w/o requesting to be a "super admin". Anyway... Thanks again for the article. Big help.
m
Thanks for the kind comment ❤️. 1. I have used Pulumi Cloud, so secrets are automatically encrypted using Pulumi Cloud encryption provider. But that's true I did not cover how it would have been done using another encryption provider like passphrases or Azure Key Vault 2. That's a very good point and to be honest I don't know the needed permissions to create the different AAD objects. I don't think it's necessary to be a super admin at all, but that's something I'll have to look into.
👍 1