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
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. There can be many contracts between
EPG 1 and EPG 2, there can be more than two EPGs that 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 are 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.
providing/consuming relationship is typically shown graphically with arrows
between the EPGs and the contract. Note the direction of the arrows shown
<-------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
Figure 6. Contract
The following figure
shows how contracts govern EPG communications.
Determine EPG to EPG Communications
For example, you may define a filter called HTTP that specifies TCP
port 80 and port 8080 and another filter called HTTPS that specifies TCP port
443. You might then create a contract called webCtrct that has two sets of
subjects. openProv and openCons are the subjects that contain the HTTP filter.
secureProv and secureCons are the subjects that contain the HTTPS filter. This
webCtrct contract can be used to allow both secure and non-secure web traffic
between EPGs that provide the web service and EPGs that contain endpoints that
want to consume that service.
These same constructs also apply for policies that govern virtual machine hypervisors. When an EPG is placed in a virtual machine manager (VMM) domain, the APIC downloads all of the policies that are associated with the EPG to the leaf switches with interfaces connecting to the VMM domain. For a full explanation of VMM domains, see the Virtual Machine Manager Domains chapter of Application Centric Infrastructure Fundamentals. When this policy is created, the APIC pushes it (pre-populates it) to a VMM domain that specifies which switches allow connectivity for the endpoints in the EPGs. The VMM domain defines the set of switches and ports that allow endpoints in an EPG to connect to. When an endpoint comes on-line, it is associated with the appropriate EPGs. When it sends a packet, the source EPG and destination EPG are derived from the packet and the policy defined by the corresponding contract is checked to see if the packet is allowed. If yes, the packet is forwarded. If no, the packet is dropped.
Contracts consist of 1 or more subjects. Each subject contains 1 or more filters. Each filter contains 1 or more entries. Each entry is equivalent to a line in an Access Control List (ACL) that is applied on the Leaf switch to which the endpoint within the endpoint group is attached.
In detail, contracts are comprised of the following items:
Name—All contracts that are consumed by a tenant must have different names (including contracts created under the common tenant or the tenant itself).
Subjects—A group of filters for a specific application or service.
Filters—Used to classify traffic based upon layer 2 to layer 4 attributes (such as Ethernet type, protocol type, TCP flags and ports).
Actions—Action 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 and regular contracts)
Aliases—(Optional) A changeable name for an object. Although the name of an object, once created, cannot be changed, the Alias is a property that can be changed.
Thus, the contract allows more complex actions than just allow or deny. The contract can specify that traffic that matches a given subject can be re-directed to a service, can be copied, or can have its QoS level modified. With pre-population of the access policy in the concrete model, endpoints can move, new ones can come on-line, and communication can occur even if the APIC is off-line or otherwise inaccessible. The APIC is removed from being a single point of failure for the network. Upon packet ingress to the ACI fabric, security policies are enforced by the concrete model running in the switch.