Network and application security best practices are required to control traffic flows and permit specific traffic between two applications or devices. ACI contracts provide a way for the Cisco Application Centric Infrastructure (ACI) administrator to control traffic flow within the ACI fabric between endpoint groups (EPGs). These contracts are built using a provider-consumer model where one endpoint group provides the services it wants to offer, and another endpoint group consumes them. Contracts are assigned a scope of Global, Tenant, VRF, or Application Profile, which limit the accessibility of the contract (see Figure 18-8).
Figure 18-8 Contract Component
Contracts contain the following items:
Subjects: A group of filters for a specific application or service.
Filters: A technique to classify traffic based on Layer 2 to Layer 4 attributes (such as Ethernet type, protocol type, TCP flags, and ports).
Actions: Tasks to be taken on the filtered traffic. The following actions are supported:
Permit the traffic (regular contracts, only).
Mark the traffic (DSCP/CoS) (regular contracts, only).
Redirect the traffic (regular contracts, only, through a service graph).
Copy the traffic (regular contracts, only, through a service graph or SPAN).
Block the traffic (taboo contracts, only).
Log the traffic (taboo contracts, only).
Labels: (Optional) A method to group objects such as subjects and endpoint groups for the purpose of increasing granularity in policy enforcement.
In the ACI security model, contracts contain the policies that govern the communication between EPGs. The contract specifies what can be communicated, and the EPGs specify the source and destination of the communications. Contracts link EPGs, as shown here:
EPG 1 ————– CONTRACT ————– EPG 2
Endpoints in EPG 1 can communicate with endpoints in EPG 2 and vice versa if the contract allows it. This policy construct is very flexible. Many contracts can exist between EPG 1 and EPG 2, more than two EPGs can use a contract, and contracts can be reused across multiple sets of EPGs, and more.
There is also directionality in the relationship between EPGs and contracts. EPGs can either provide or consume a contract. An EPG that provides a contract is typically a set of endpoints that provide a service to a set of client devices. The protocols used by that service are defined in the contract. An EPG that consumes a contract is typically a set of endpoints that 848are clients of that service. When the client endpoint (consumer) tries to connect to a server endpoint (provider), the contract checks to see if that connection is allowed. Unless otherwise specified, that contract would not allow a server to initiate a connection to a client. However, another contract between the EPGs could easily allow a connection in that direction.
This providing/consuming relationship is typically shown graphically with arrows between the EPGs and the contract. Note the direction of the arrows shown here:
EPG 1 <——consumes——- CONTRACT <——provides——- EPG 2
The contract is constructed in a hierarchical manner. It consists of one or more subjects, each subject contains one or more filters, and each filter can define one or more protocols, as shown in Figure 18-9.
Figure 18-9 ACI Subjects and Contracts
While different endpoint groups can only communicate with other endpoint groups based on the contract rules defined, no contract is required for intra-endpoint group communication. Intra-endpoint group communication from endpoint to endpoint in the same endpoint group is allowed by default.
If a filter allows traffic from any consumer port to a provider port (such as 8080), and if reverse port filtering is enabled and the contract is applied in both directions (say for TCP traffic), either the consumer or the provider can initiate communication. The provider could open a TCP socket to the consumer using port 8080, whether the provider or consumer sent traffic first.