Security Model¶
Isolation Levels¶
Concept¶
With the service interconnection fabric (SIF), organizations can divide application services distributed across private and public clouds into isolated domains without network configuration and irrespective of geographic location, virtualization platform, and IP/Ethernet addresses. Services may be running on physical servers or VMs or containers.
IT teams can explicitly define micorsegments (contracts), specifying interaction patterns, firewall rules, and data pathways. Each permission set within a contract is labeled as a distinct role. These roles, then, can be attached to any application service.
As an application service instance binds to an endpoint on a workload node, the endpoint dynamically obtains permissions based on the service role. In this way, the service instance will be able to establish authorized connectivity with the policy set not only at the network endpoint, but through the entire infrastructure.
When the service instance initiates a new flow, every processor en route verifies permissions linked to the service instance role before forwarding packets belonging to the flow. With the SIF, communication policy preserves uniformity over different virtualization environments and across private and public clouds while allowing for personalized forwarding, path protection, and load balancing down to the flow level.
The service-level segmentation is reinforced with the resource segmentation and separation of administration duties. As such, the SIF security model relies on three levels of isolation: fabric, domain, and contract.
Fabric-level Isolation¶
A fabric isolates all its resources in their own fault domain. Resources within a fabric share a policy controller—usually deployed for high-availability and scalability as a plurality of nodes—dedicated to that fabric. The policy controller does not communicate with resources outside of the fabric.
Domain-level Isolation¶
Within a fabric, administrative responsibilities are isolated from each other in domains. Multiple applications, for example, may be running on resources in a single fabric. However, the services and contracts for one application may be administratively isolated from the services and contracts for another application by placing them in distinct domains. By doing this, a unique administrative account manages services and contracts for its domain only.
Contract-level Isolation¶
Resources (workloads) for a given application (isolated within a domain) receive contracts from a policy controller (isolated within a fabric) that dictate allowed paths of communication. These contracts act as waypoints between service endpoints (application microservice instances) running on workloads that determine who can talk to whom. This level of micro-segmentation ensures that no data passes between workloads without authorization from the policy controller.
Isolation Topology¶
Fig. 7 graphically demonstrates the three levels of isolation as they relate to an application.
- Resource Graph: represents fabric-level isolation containing all workload nodes and processor nodes that are under the auspices of the same policy controller
- Service Graph: represents domain-level isolation containing services (service graph nodes) within an application that communicate with each other
- Flow Graph: represents contract-level isolation containing policy (service graph edges) that allows one service instance to communicate with another service instance
Fig. 7 Security Isolation Levels
Table 1 summarizes the relationship between the Fabric, Domain, and Contract abstraction layers, their graphical representation, and constituent elements.
| No. | Abstraction Layer | Representation | Node |
|---|---|---|---|
| 1 | Fabric | Resource graph | Resource |
| 2 | Domain | Service graph | Service |
| 3 | Contract | Flow graph | Endpoint |
Security Entities¶
Two APIs facilitate communication with the policy controller: Northbound API and Southbound API.
Northbound API¶
The Northbound API provides a mechanism for automation systems to interact with the policy controller. Tasks that can be performed via the policy controller GUI can also be performed programmatically through the Northbound API.
A user will typically use this interface extensively when automating tasks.
Southbound API¶
The Southbound API provides a mechanism for the policy engines and policy agents to communicate with the policy controller.
Communication on this interface is fully automated. A user will not directly interact with it.
As shown in figure below, there are four security entities: Administrator Credentials, Resource Certificate, Service Token, and Flow Signature.
Fig. 8 Security Model
Resource Certificate¶
Each virtual machine in a given fabric uses an X.509 certificate to verify identity within a fabric. Hence, a policy agent or policy engine can use credentials to establish communication with a policy controller only if the policy agent or policy engine is running on a virtual machine recognized by the policy controller via its X.509 certificate.
Once node identity is established, the X.509 certificate is used to
- create a secure communication control channel with the policy controller using mTLS
- create a secure communication data channel using IPsec
- find neighboring nodes using SeND (Secure Neighbor Discovery) protocol
- generate network endpoint identity using CGAs (Cryptographically Generated Addresses)
Service Token¶
If the Credential authorizes a policy agent to communicate with the policy controller and the Certificate establishes the identity of a node that can operate within a fabric, then a Token authorizes a service to run on an identified node with an authorized policy agent. When a service is authorized to run on a network endpoint, the corresponding policy agent creates one or more service endpoints.
The domain administrator assigns roles associated with one or more contracts to a service created at the policy controller. An authorized policy agent at a network endpoint creates a service endpoint for each role assigned by the domain administrator to that service.
The domain administrator generates a token at the policy controller for a given service. The token consists of a 128-bit key and a 128-bit value that form a key:value pair. The policy controller stores the key and a hash of the value only. The domain administrator then authorizes a service at a network endpoint by attaching the entire 256-bit key:value pair to a policy agent, which then queries the policy controller. If the policy controller recognizes the key:value pair, it passes contract role information to the policy agent to establish service endpoints. Recall that the contract role dictates how and to whom the service endpoint can communicate.
Best practices necessitate that administrators treat tokens as short-lived security entities, rotating them often and assigning them uniquely to service instances.
Flow Signature¶
Upon creating a service endpoint for a given contract role, the policy agent requests that the policy controller send the contract policy to the policy agent in the form of a microprogram. This microprogram is cryptographically bound to the service endpoint that is operating at the given network endpoint using an ECDSA signature that covers IPv6 control packet headers. The IPv6 control packet headers carry the microprogram in an extension header along with network endpoint (IPv6 SA), service endpoint (IPv6 FL), and contract ID (IPv6 DA). Policy engines within the fabric use the policy to create flow state to interconnect authorized service endpoints.
Summary¶
The security model of the service interconnection fabric relies on three levels of isolation and four security entities. Fabric-level isolation confines resources to a single policy controller; domain-level isolation provides for administrative isolation among applications; and contract-level isolation inserts policy waypoints along communication paths between service endpoints.
These isolation levels are enforced using credentials that authorize administrators or automation systems to communicate with the policy controller. Certificates corroborate the identity of nodes within a service interconnection fabric that ultimately provides for a secure control channel (mTLS), secure data channel (IPsec), secure neighbor discovery (SeND), and secure network endpoint identifiers (CGA). Tokens ensure that only authorized service endpoints communicate through contracts over the service interconnection fabric. Finally, ECDSA signatures provide for unaltered delivery of inband policy information to policy engines.