is ensured, altogether approximately less than 1ms. This can scale up to a situation where surgeons can perform remote surgeries over long distances using automated hardware and robotics, that will get as much resources as required due to priority, all in the same area where the soccer match is taking place.
2.5.2. SDN and NFV solutions, network overlay and underlay
To successfully connect remote workloads, a networking solution that can manage L3 and L2 operations is required, namely routing and switching. The actual devices that can perform these operations are hardware routers and switches. For the particular requirements of the mobile network infrastructure, the hardware usage feasibility is limited for a simple reason, which is virtualization of the networking function.
Specifically, a physical router cannot be virtualized without usage of a software-defined network. For the deployment of the mobile network and connecting the eNB base station to the virtualized Evolved Packet Core, the most appropriated SDN options are selected and consequently described. Each of these technologies have their own distinct features that can contribute to establishing a secure, trustable and fault-tolerant next-generation virtualized mobile infrastructure.
to configure access policy for that container. The Calico network plugin will automatically create the associated profile if it does not exist when the container is attached to the network. By default, the profile contains rules that allow full egress traffic but allow ingress traffic only from containers within the same network and no other source. Custom policy for a network can be configured by creating in advance, or editing, the profile associated with the Docker network (TIGERA INC., 2017).
There are two approaches by which the policy that defines the Docker network can be modified:
a) Modify the profile policy rules - This policy is applied directly to each container in the associated Docker network. This approach is simple, but not very flexible, as the profile must describe the full set of rules that apply to the containers in the network.
b) Assign labels to the profile and define global selector-based policy - The (Calico-specific) labels are assigned to containers in the associated Docker network. The globally defined policy uses selectors to determine which subset of the policy is applied to each container based on their labels.
This approach provides a powerful way to group together all of the particular network Policy, makes it easy to reuse policy in different networks, and makes it easier to define policy that extends across different orchestration systems that use Calico.
Managing Calico policy for a network
In both cases a Calico-Docker network is created and the “calicoctl” tool is used to achieve the required isolation. The following example denotes an isolation between a set of database containers and frontend containers:
Frontend containers can only access the Database containers over TCP to port 3306. At this point, it is assumed that no other connectivity is allowed to/from the frontend.
Database containers have no isolation between themselves (to handle synchronization within a cluster). This could be improved by locking down the port ranges and protocols, but for brevity a full access between database containers is allowed.
a) Policy applied directly by the profile
In the following example the policy for containers is applied in both networks with using profiles. Each network has associated an identically named profile that consists of a set of labels and policy rules. The labels and policy rules are set for each of the two network profiles to provide the required isolation.
Moreover, Docker networks are created by the following commands:
docker network create --driver calico --ipam-driver calico-ipam database docker network create --driver calico --ipam-driver calico-ipam frontend
After the creation of the networks, the profiles are added for each of the networks. The labels are set on each profile indicating the network role, and in this case frontend or database. Each profile also includes a set of ingress and egress rules and actions, where each rule can filter packets based on a variety of source or destination attributes (which includes selector-based filtering using label selection). The labels and rules are applied directly to each container in the corresponding network. The labels themselves are arbitrary key/value pairs, and their current purpose at this point is to use the key role showing the network role and a value of either frontend or database. Correspondingly, a profile will have the following form in YAML structure (see Appendix D) (TIGERA INC., 2017).
The profiles provide the required isolation between the frontend and database containers. This works as follows:
Containers in the “database” Docker network are assigned the “database” Calico profile.
Containers in the “frontend” Docker network are assigned the “frontend” Calico profile.
Each container in the “database” network inherits the label role = database from its profile.
Each container in the “frontend” network inherits the label role = frontend from its profile.
The “database” profile applies ingress and egress policy:
- An ingress rule to allow TCP traffic to port 3306 from endpoints that have the label role = frontend (i.e. from frontend containers since they are the only ones with the label role = frontend)
- An ingress and egress rule to allow all traffic from and to endpoints that have the label role
= database (i.e. from database containers).
The “frontend” profile applies a single egress rule to allow all TCP traffic to port 3306 on endpoints that have the label role = database (i.e. to database containers)
a) Global policy applied through label selection
The same example can be demonstrated using global selector-based policy. In this case, the network profiles are used to apply labels (as in the previous example), but additionally define a set of global policy resources that use selectors to determine which subset of the policy applies to each container based on the labels applied by the profile. After the creation of the Docker networks, the profiles for each of the networks are created accordingly (see Appendix E) (TIGERA INC., 2017).
The labels on each profile indicate the network role, and in this case frontend or database. The labels are applied directly to each container in the corresponding network. As with the previous example, the key role indicating the network role and a value of either frontend or database is used. Unlike the previous, no policy rules are defined within the profile. To enable the required network isolation, the global policy is created (policy resources are defined globally, and like profile includes a set of ingress and egress rules and actions, where each rule can filter packets based on a variety of source or destination attributes, which includes selector-based filtering using label selection). Each policy resource also has a “main” selector that is used to determine which endpoints the policy is applied to base on the labels applied by the network profiles (refer to Appendix F) (TIGERA INC., 2017).
Implementing Calico as a solution for securing host interfaces
It is feasible to use Calico for securing the host’s network interfaces (as opposed to those of any container/VM workloads that are present on the host). The host endpoints are distinguishable by workload endpoints by the role they play. The former are the physical host network endpoints, while the latter are referring to the ones of the virtual machines and containers. Calico supports the same rich security policy model for host endpoints that it supports for workload endpoints. Host endpoints can have labels, and their labels are in the same “namespace” as those of workload endpoints. This allows security rules for either type of endpoint to refer to the other type (or a mix of the two) using labels and selectors. Calico does not support setting IPs or policing MAC addresses for host interfaces, it assumes that the interfaces are configured by the underlying network fabric (this option is tested further on using VxLAN and MACVLAN for performance improvement and avoiding network overlay when possible). Calico distinguishes workload
informed about. Traffic to/from other interfaces is neglected. As of Calico v2.1.0, Calico applies host endpoint security policy both to traffic that is terminated locally, and to traffic that is forwarded between host endpoints. Previously, policy was only applied to traffic that was terminated locally. The change allows Calico to be used to secure a NAT gateway or router. Calico supports selector-based policy as normal when running on a gateway or router allowing for rich, dynamic security policy based on the labels attached to the workloads, as represented in Figure 49 (TIGERA INC., 2017).
Figure 49. Organization of Calico security endpoints to protect physical hosts