Azure has an active directory structure. The top level structure is the organization, and underneath the organization are the directories (also known as Azure tenants). Inside the directories, you can have one or more Azure subscriptions.

The relationship between certain Azure components is as follows:

Tenants > Subscriptions > Resource Groups > Resources

Where:

• One tenant can have multiple subscriptions, but each subscription can belong to only one tenant

• One subscription can have multiple resource groups, but each resource group can belong to only one subscription

• One resource group can have multiple resources, but each resource can belong to only one subscription

The following sections provide more detail about each of these components:

• Mapping Azure and Cloud APIC Components

• About Azure Subscriptions

• About Tenants and Identities

About Tenants and Identities

Following are the different types of tenants and identities available through Azure and Cloud APIC.

Note

For releases prior to release 5.2(1), only managed identity was supported as the access type for infra tenants, while both managed identity and service principal was supported as the access type for user tenants. Beginning with release 5.2(1), both managed identity and service principal is now supported as an access type for the infra tenants and the user tenants.

Managed Identity

Managed identities provide an identity for applications to use when connecting to resources that support Azure AD authentication. Applications can use the managed identity to obtain Azure AD tokens. For example, an application could use a managed identity to access resources like Azure Key Vault, where developers can store credentials in a secure manner or to access storage accounts.

Following are several benefits to using managed identities:

• You don't need to manage credentials, since credentials are not even accessible to you.

• You can use managed identities to authenticate to any resource that supports Azure AD authentication, including your own applications.

• Managed identities can be used without any additional cost.

For additional information on managed identities in Azure, see:

https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

If you are configuring tenants in the Cloud APIC using managed identity, then you will make the following configurations in the Azure portal and in the Cloud APIC:

1. In the Azure portal, you will add a role assignment for a virtual machine. You use this option when the Azure subscriptions are in the same Azure directory (of the same organization).

   Note

   If your Azure subscriptions are in different directories and you want to configure tenants using managed identity, you can go to the Azure console and click on each of the subscriptions and move the subscriptions under the same Azure directory. You can only do this if the directories (containing the different subscriptions) are a child of the same parent organization.

2. In the Cloud APIC, you will choose the Managed Identity option when configuring a tenant in Cloud APIC.

See Creating a Tenant Using the Cisco Cloud APIC GUI for more information on making these configurations.

Service Principal

An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. You would use the service principal identity when you want to configure tenants in different subscriptions. The subscriptions are either in different Azure directories (Azure tenants) in the same organization, or the subscriptions can be in different organizations.

If you are configuring tenants in the Cloud APIC using service principal, then you will make the following configurations in the Azure portal and in the Cloud APIC:

1. In the Azure portal, you will be adding a role assignment for an app, where the cloud resources will be managed through a specific application.

2. In the Cloud APIC, you will choose the Service Principal option when configuring a tenant in Cloud APIC. The subscriptions that you enter in this page can be in different Azure directories (Azure tenants) in the same organization, or the subscriptions can be in different organizations.

See Creating a Tenant Using the Cisco Cloud APIC GUI for more information on making these configurations.

Shared Tenant

You will choose this option when you have already associated Azure subscriptions with either of the two methods above and want to create more tenants in that subscription.

If you are configuring a tenant in the Cloud APIC as shared tenant, then you will make the following configurations in the Azure portal and in the Cloud APIC:

1. You do not have to make any configurations in Azure specifically for a shared tenant, because you will have already associated Azure subscriptions with either of the two methods above. With the shared tenant, you will just create more tenants in that existing subscription.

2. In the Cloud APIC, you will choose the Shared option when configuring a tenant in Cloud APIC.

See Creating a Tenant Using the Cisco Cloud APIC GUI for more information on making these configurations.

The Cisco Cloud Services Router 1000V (CSR 1000V) is a virtual router that delivers comprehensive WAN gateway and network services into virtual and cloud environments. The CSR 1000V enables enterprises to extend their WANs into provider-hosted clouds. Two CSR 1000Vs are required for Cisco Cloud ACI solution.

For more information, see the Cisco CSR 1000v documentation.

A cloud service EPG, introduced in Release 5.1(2), is a managed object that is a named logical entity that contains a collection of cloud native or third-party service instances or endpoints. In this situation, an endpoint refers to a particular service instance. For example, an SQL server would be considered an endpoint, and a collection of SQL servers would form a service endpoint group. Other examples of service EPGs would be a collection of Storage Accounts, a collection of Key Vaults, and so on.

Service EPGs have several unique attributes:

• Service Type: This attribute indicates what type of cloud service is being grouped. Examples of available service types include Azure SQL, Azure Containter Registery, Azure ApiManagement Services, and so on. The service type Custom is used when configuring a third-party service EPG.

• Deployment Type: This attribute indicates how and where the service is deployed. Following are the available deployment types:

  • Cloud Native: In this type of deployment, the service is instantiated in the cloud provider's network and the user or applications consuming it have a handle to the service. For example, an Azure storage account might reside inside Azure's own VNet, and you would have a URL to access the storage contents.

  • Cloud Native Managed: In this type of deployment, the service is instantiated in your VNet or subnet (created through the Cisco Cloud APIC). For example, an Azure Kubernetes cluster (AKS) could be deployed in a subnet that is managed by the Cisco Cloud APIC.

  • Third-Party: This is a deployment where a third-party (not Azure) is providing services through the market place. Access to this service is provided through the private links feature.

• Access Type: This indicates how the service will be accessed. Following are the available access types:

  • Public: The service will be accessed using the public IP address assigned to it. Access to the public IP address range of a particular service is achieved using the Azure "Service Tags" in the NSG rules.

  • Private: The service will be accessed using a private IP address assigned to it. This assignment is done through the creation of private endpoints when the deployment is of type Cloud Native and Third-Party. In the case of a Cloud Native Managed deployment, the private IP is assigned by the service from the subnet IP space.

  Only certain deployment types, and certain access types within each deployment type, are supported for each service type, described in the previous bullets. The following table provides more information on the deployment types and access types that are supported for each service type.

  Service Type	Provider	Deployment Type/Access Type
  		Cloud Native	Cloud Native Managed	Third-Party
  Azure Storage Blob	Microsoft.Storage	Private	N/A	N/A
  Azure SQL	Microsoft.Sql	Public Private	N/A	N/A
  Azure Cosmos DB	Microsoft.DocumentDB	Public Private	N/A	N/A
  Azure Databricks	Microsoft.Databricks	Public	Private Public and Private	N/A
  Azure Storage	Microsoft.Storage	Public Private	N/A	N/A
  Azure Storage File	Microsoft.Storage	Private	N/A	N/A
  Azure Storage Queue	Microsoft.Storage	Private	N/A	N/A
  Azure Storage Table	Microsoft.Storage	Private	N/A	N/A
  Azure Kubernetes Services (AKS)	Microsoft.ContainerService	Private	Private Public and Private	N/A
  Azure Active Directory Domain Services	Microsoft.AAD	Public	Private Public and Private	N/A
  Azure Container Registry	Microsoft.ContainerRegistry	Public Private	N/A	N/A
  Azure ApiManagement Services	Microsoft.ApiManagement	Public	Private Public and Private	N/A
  Azure Key Vault	Microsoft.KeyVault	Public Private	N/A	N/A
  Redis Cache	Microsoft.Cache	N/A	Private Public and Private	N/A
  Custom Service		Public Private	N/A	Private

• Service Endpoint Selectors: Service endpoints can be selected using the existing selectors (used in the cloud EPG selection) as well as the new types of selectors listed below:

  • Resource Name: The service resource's name

  • Resource ID: The cloud provider's ID for the resource

  • URL: The alias or FQDN that identifies the service (the private link alias is used in Azure)

  The following table provides more information on the endpoint selectors that are supported for each deployment type.

  Note	Information for the Cloud Native (Public) deployment type is not provided in the following table because that deployment type does not support endpoint selectors.

  Deployment Type	Tags	Region	IP	Resource Name	Resource ID	URL
  Cloud Native (Private)	Y	Y	N	Y	Y	N
  Cloud Native Managed	N	N	Y	N	N	N
  Third-Party	N	N	N	N	N	Y (applicable only for private link connection)

After a contract is created, some of the rules defined in the contract are consolidated and displayed in Azure based on certain criteria. You can combine multiple ports and multiple IP addresses and ranges into a single, easy-to-understand rule. The criteria for consolidation of rules are:

• Rules are consolidated only within a contract. Two rules resulting from two different contracts are not consolidated in Azure.

• The source/ destination address prefixes and destination port(s) are consolidated.

• The conditions for multiple rules to get consolidated together in an NSG are:

  • Same contract

  • Same protocol (UDP, TCP,ICMP)

  • Same direction (inbound , outbound)

  • Same type (SG, IP)

• Overlapping port ranges for same protocol (TCP/UDP) in the same contract are consolidated to one range.

  For example, TCP ports 100-200, 150-250 are consolidated to 100-250.

• If 1.2.3.4/32 (any address prefixes) is allowed, and an ext EPG with 0.0.0.0/0 is added, then the allowed Source/Destination IP would be Any, not [1.2.3.4/32, 0.0.0.0/0].

Example below shows the EPG1 outbound rules and the consolidated EPG1 outbound rules, based on contracts C1 and C2.

Contract C1:
Consumer: EPG1 , Provider: EPG2
Filter: TCP  (ports 53)
Filter: UDP (port 53, 5000)

Contract C2:
Consumer: EPG1 , Provider: EPG2
Filter: TCP (ports 80, 8080)

EPG1 outbound rules:
EPG1 -> EPG2 		TCP 	80
EPG1 -> EPG2 		TCP 	8080
EPG1 -> EPG2 	      TCP        53
EPG1 -> EPG2 		UDP 	53
EPG1 -> EPG2 		UDP 	5000
EPG1 -> 1.1.1.1/32 	TCP 	80
EPG1 -> 1.1.1.1/32 	TCP 	8080
EPG1 -> 1.1.1.1/32 	TCP 	53
EPG1 -> 1.1.1.1/32 	UDP 	53
EPG1 -> 1.1.1.1/32 	UDP	5000
EPG1 -> 2.2.2.2/32 	TCP 	80
EPG1 -> 2.2.2.2/32 	TCP 	8080
EPG1 -> 2.2.2.2/32 	TCP       53
EPG1 -> 2.2.2.2/32 	UDP 	53
EPG1 -> 2.2.2.2/32 	UDP 	5000

Rules are consolidated by comma-separated filters (consolidated based on C1 and C2): 
EPG1 -> EPG2 				TCP	 80,8080  
EPG1 -> EPG2 				UDP 	53,5000  
EPG1 -> EPG2 				TCP	 53	
EPG1 -> 1.1.1.1/32, 2.2.2.2/32 	 TCP 	80,8080	
EPG1 -> 1.1.1.1/32, 2.2.2.2/32 	 UDP 	53,5000	
EPG1 -> 1.1.1.1/32, 2.2.2.2/32 	 TCP 	53		

Subject and filter managed-objects enable mixing and matching among cloud EPGs and contracts so as to satisfy various applications or service delivery requirements. The following figure shows the location of application subjects and filters in the management information tree (MIT) and their relation to other objects in the tenant.

Contracts can contain multiple communication rules and multiple cloud EPGs can both consume and provide multiple contracts. A policy designer can compactly represent complex communication policies and re-use these policies across multiple instances of an application.

Note	Subjects are hidden in Cisco Cloud APIC and not configurable. For rules installed in Azure, source port provided in the filter entry is not taken into account.

Subjects and filters define cloud EPG communications according to the following options:

• Filters are Layer 3 to Layer 4 fields, TCP/IP header fields such as Layer 3 protocol type, Layer 4 ports, and so forth. According to its related contract, a cloud EPG provider dictates the protocols and ports in both the in and out directions. Contract subjects contain associations to the filters (and their directions) that are applied between cloud EPGs that produce and consume the contract.

• Subjects are contained in contracts. A subject within a contract uses filters to specify the type of traffic that can be communicated and how it occurs. For example, for HTTPS messages, the subject specifies the direction and the filters that specify the IP address type (for example, IPv4), the HTTP protocol, and the ports allowed. Subjects determine if filters are unidirectional or bidirectional. A unidirectional filter is used in one direction. Unidirectional filters define in or out communications but not the same for both. Bidirectional filters are the same for both; they define both in and out communications.

• ACI contracts rendered in Azure constructs are always stateful, allowing return traffic.