Azure Automation should support using pre-existing Service Principals for RunAs connections
Currently the only supported method for adding a RunAs connection to an Azure Automation account is to create a new Service Principal. By default the SP is created with Contributor access to the entire subscription.
This is not ideal for several reasons:
* Contributor access to a subscription is a relatively high level of access. I would like to ensure that my automation accounts are more tightly constrained.
* The auto-generated name for the SP can cause problems in accounts that have applied a naming standard/governance model to SP accounts.
* Since we are unable to reuse our existing SPs for managing resources, we are forced to manage duplicate access profiles for two SPs (one used for ARM deployments, one used in Automation Accounts).
While it is possible to create a RunAs connection with an existing SP via powershell, the process is finicky and I am being told by MS support that the result is considered an "unsupported configuration". I would like this configuration to be documented and supported.
For reference, I was able to successfully create a RunAs connection via powershell without creating a new SP if I made sure that the following were true:
* The connection is named "AzureRunAsConnection"
* The certificate is named "AzureRunAsCertificate"
* The connection object is created first and the certificate is created second

3 comments
-
Roberto Ferrer commented
That would be great! We are in the same situation, lack of permissions on AAD.
-
Steeve Roy commented
Is there any progress on this? We also have some restriction that prevent us to create RunAs account...
-
Eric Torbenson commented
Another reason for supporting this is that some environments lock down the creation of service principals. When you do that in AAD, you need to be a global admin in the AAD tenant, which most organizations won't allow developers/engineers to have.
If we had an easy way to reuse a service principal that was created when our subscription was created, or even have a script we can give to our AD global admins to run, this would encourage the use of Azure Automation.