|
| 1 | +--- |
| 2 | +title: Azure Operator Nexus - Cross-subscription deployments and required permissions for Network Fabric |
| 3 | +description: Cross-subscription deployments and required permissions for Network Fabric |
| 4 | +author: sushantjrao |
| 5 | +ms.author: sushrao |
| 6 | +ms.service: azure-operator-nexus |
| 7 | +ms.topic: conceptual |
| 8 | +ms.date: 09/17/2024 |
| 9 | +ms.custom: template-concept |
| 10 | +--- |
| 11 | + |
| 12 | +# Cross-subscription deployments and required permissions for Network Fabric |
| 13 | + |
| 14 | +This article outlines the requirements and behaviors associated with managing Nexus Network Fabric (NNF) resources in Azure across multiple subscriptions, along with the implementation of the linked access check. This check ensures that the necessary permissions and access controls are in place when managing resources across different subscriptions. |
| 15 | + |
| 16 | +## Subscription context and user permissions |
| 17 | + |
| 18 | +Consider two Azure subscriptions, **Subscription A** and **Subscription B**, where users interact with NNF resources. The permissions assigned to users in each subscription determine their ability to manage these resources effectively. |
| 19 | + |
| 20 | +**Subscription A:** This subscription hosts the primary NNF resources. Depending on the user’s permissions, access levels can vary from read-only to full control. |
| 21 | + |
| 22 | +**Subscription B:** This subscription is used for creating and managing NNF resources that may reference resources from **Subscription A**. |
| 23 | + |
| 24 | +## Scenarios |
| 25 | + |
| 26 | +### Limited access in subscription |
| 27 | + |
| 28 | +In this scenario, the user has access to two subscriptions: **Subscription A** and **Subscription B**. In **Subscription A**, the user has only `Read` access to the Network Fabric (NNF) resources. |
| 29 | + |
| 30 | +**Outcome:** When the user tries to create or manage any NNF resource in **Subscription B** by referencing the NNF resource from **Subscription A**, the operation fails with a `LinkedAuthorizationFailed` error. This failure occurs because the user does not have the necessary `Join` access to the NNF resource. |
| 31 | + |
| 32 | +### Sufficient access in both subscriptions |
| 33 | + |
| 34 | +In this scenario, the user has access to both **Subscription A** and **Subscription B**, with either `Contributor` or `Owner` permissions in both subscriptions. |
| 35 | + |
| 36 | +**Outcome:** When the user tries to create or manage Network Fabric (NNF) resources in **Subscription B** by referencing NNF resources in **Subscription A**, the operation succeeds. This confirms that sufficient permissions enable successful resource management across subscriptions. |
| 37 | + |
| 38 | +### No access to subscription |
| 39 | + |
| 40 | +In this scenario, the user has no access to **Subscription A**, where the Network Fabric (NNF) resources are deployed, but has Contributor or Owner rights in **Subscription B**. |
| 41 | + |
| 42 | +**Outcome:** When the user tries to create or manage NNF resources in **Subscription B** by referencing NNF resources in **Subscription A**, the operation fails with an AuthorizationFailed error. This occurs because the user lacks either the required Read access to **Subscription A** along with Join access to the referenced resource, or Write access to **Subscription A** along with Join access to the referenced resource. |
| 43 | + |
| 44 | +>[!NOTE] |
| 45 | +>Network Fabric cannot be created in a different subscription than the referenced Network Fabric Controller (NFC). |
| 46 | +
|
| 47 | +## Key considerations |
| 48 | + |
| 49 | +To effectively manage NNF resources across Azure subscriptions, users must have the appropriate permissions. The following permissions are essential: |
| 50 | + |
| 51 | +### Permission management |
| 52 | + |
| 53 | +#### Subscription-level permissions |
| 54 | + |
| 55 | +- **Read access:** Users must have read access to view NNF resources within the subscription. |
| 56 | + |
| 57 | +- **Contributor access:** Users can create and manage resources, including configuring settings and deleting resources. |
| 58 | + |
| 59 | +- **Owner access:** Users have full control over the subscription, including the ability to manage permissions for other users. |
| 60 | + |
| 61 | +#### Resource-level permissions |
| 62 | + |
| 63 | +- **Join access:** Users must have Join access to the specific NNF resources they wish to reference. For example, when a user tries to create an L2 or L3 isolation domain in **Subscription B** while referencing an NNF resource in **Subscription A**, the user must have Join access on the NNF resource. |
| 64 | + |
| 65 | +### Resource management |
| 66 | + |
| 67 | +#### Resource creation |
| 68 | + |
| 69 | +- Ensure that users have the necessary subscription-level permissions before attempting to create NNF resources. |
| 70 | + |
| 71 | +- When referencing resources from another subscription, confirm that the user has both read access to that subscription and Join access to the specific NNF resource. |
| 72 | + |
| 73 | +#### Resource configuration |
| 74 | + |
| 75 | +- Users with 'Contributor` or `Owner` access can configure NNF resources. However, they must have the appropriate permissions for each specific configuration action. |
| 76 | + |
| 77 | +#### Resource deletion |
| 78 | + |
| 79 | +- Deleting NNF resources typically requires `Contributor`, `Owner` or `Delete` access on the resource. Users should be aware of any dependencies that may prevent deletion. |
| 80 | + |
| 81 | +### Cross-Subscription management |
| 82 | + |
| 83 | +- When managing NNF resources across multiple subscriptions, it’s crucial to maintain a clear understanding of the permissions structure to avoid `AuthorizationFailed` and `LinkedAuthorizationFailed` errors. |
0 commit comments