Support deploying the sample when Azure OpenAI service is in a separate Subscription

[tijldullers]

Please provide us with the following information:

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [x ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

When trying to deploy the sample, there is no way of deploying it in a situation where the subscription to which you deploy the sample does not host (or cannot) the Open AI service. This happens often since a subscription is not enabled by default for OpenAI services. So, organizations often centralize the OpenAI service in a subscription, which is then used by multiple users that deploy their resources in a separate subscription.The feature request is to extend the sample provisioning logic to allow to use an OpenAI service in a separate subscription.

Any log messages given by the failure

In the current situation, the deployment script ( azd up) throw an error station that the Resource group specified for the Open AI service can't be found since it is looking in the wrong subscription.

Expected/desired behavior

The ability to specify the subscription for the OpenAI service that can be different from the subscription for the other services.

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?) N/A

azd version?

run azd version and copy paste here.

Versions

N/A

Mention any other details that might be useful

---

Thanks! We'll be in touch soon.

[pamelafox]

Thanks for filing! I do not have experience myself with doing Bicep-based deployments with resources across subscriptions. Have you been able to do that with other scenarios?

cc @jongio to comment on the feasability of doing this within azd.

[tijldullers]

Thanks for filing! I do not have experience myself with doing Bicep-based deployments with resources across subscriptions. Have you been able to do that with other scenarios?

cc @jongio to comment on the feasability of doing this within azd.

I think this can be achieved through BICEP by using modules and scoping:

The module has a scope property that you can reference the subscription + resource group that you want to deploy into.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules#configure-module-scopes

The resourcegroup() method can take the parameters for the subscription and the resourcegroup and can be used for the Scope property

resourceGroup(subscriptionId, resourceGroupName)

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-functions-scope#resourcegroup

[pamelafox]

That makes sense, I'm just not certain if the azd commands would have any interoperability issues with mixing the scopes like that, so I've asked them to comment. If you do tinker with it yourself and succeed, please share your Bicep changes.

[vhvb1989]

If the OpenAI service is already (within the same subscription or not), why would we want to add/reference it within bicep?

One answer could be, to pull a connection string, or the keys from the service and put it in the env for the application (feed the application config). For this case, would it make more sense to set the connection/key within a KeyVault secret and feed the application with that keyvault? The application would fetch the secret and connect.

Another answer could be, to grant read access to the services which will be calling the OpenAI service. Assuming both subscriptions are within the same Tenant (as rbac is limited per tenant), and that we only have contributor-access to one of the subscriptions (not to the OpenAI), we might not be able to do the role assignment from our side. Instead, we might need to ask the OpenAI-subscription owner to assign the roles.

[tijldullers]

The fetching the key from keyvault looks like a perfect solution!

[pamelafox]

I will actually be soon adding the logic/Bicep for keyvault for key storage, as that's the better approach for using non-Azure OpenAI. I'll try to do that this week.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this issue will be closed.

[tomitomasino]

hi @tijldullers - did you find a solution for the problem? I have exactly the same situation as you described. I tried modifying the bicep files by my own (not to create open AI related resources) and/or by setting env parameters to point existing open AI service, but no success till now.

[pamelafox]

To clarify the current status:
Today the sample assumes the Azure OpenAI resource is in the active subscription. While you can point to an existing resource via AZURE_OPENAI_* variables, the current Bicep/azd flow does not support cross-subscription scoping or role assignments.

A possible path forward is adding a subscriptionId parameter and using resourceGroup(subscriptionId, ...) or module scoping, and validating azd behavior across subscriptions. However, I have not done cross-subscription provisioning in any templates yet, so don't know if there would be issues with that there.

Contributions are welcome.