AMP Networking

This feature allows application designers to model their security requirements directly in blueprints, specifying the groups of “networks” to which entities belong, and the permitted access from network to network. AMP takes care of creating an implementation enforcing these restrictions using the mechanisms of the underlying cloud.

Table of Contents

• Installing How to use the features in amp-networking.
• Defining Networks Define the security of application components by specifying “network security groups” to which application entities belong.
• Permitting Access Restrict access to application components by specifying the connections that are allowed from other groups. Other access will be prohibited.
• Built-in Cluster Support AMP automatically manages the security constraints for dynamic clusters as nodes are added in response to scaling demands.
• Configuration Configuration can be done entirely in YAML.
• Visualizing Networks Show network security group membership in the application entity tree.
• Supported Clouds Currently supported on AWS and OpenStack.

AMP Network Security Reference

Security accessibility networking in AMP is a feature that enables the modelling of the permitted access to the components of an application. In other words, it allows blueprint authors to specify what connections are permitted between the elements of the application, and also between the application and its wider environment, including the public internet.

What this means in terms of how these restrictions are physically implemented on the underlying machines may vary from cloud to cloud. The desired restrictions may be achieved using concepts such as Security Groups on clouds that support this, or through IP network configuration, IPTables, or other means, or indeed a combination of the above. Therefore, when talking about security “networking” in AMP, the term “network” should be understood as a high level abstraction of the connections that may be made between hosts, rather than in the more narrowly specific sense of an IPv4 or v6 network or subnet defined by an address plus netmask.

A security “network”, then, is a named group of hosts that can share some particular configuration of security accessibility rules. There is built-in support for a “public” network representing the external internet, and for a “management” network to permit access from AMP.

Specifying Network Security

The security accessibility rules in AMP are defined on a per-application basis. A network name used in one application may also appear in another application, but each application has its own network of that name.

Two sets of rules are configurable on an entity:

1. The groups to which the entity belongs.
2. The ingress rules that define what access is permitted to that entity (to its host machine) from specific groups.

Network security configurations are applied to any of the entities of an application using the customizer NetworkSecurityCustomizer. (Note, it is intended to support in future the ability to configure the networks directly on the entities without having to add a customizer.)

Defining Networks

Networks are defined on an entity by using the networks specifier of the NetworkSecurityCustomizer, which declares a list of identifiers (network names):

brooklyn.initializers:
- type: io.cloudsoft.amp.networking.NetworkSecurityCustomizer
  brooklyn.config:
    networks:
      - my-network-1
      - my-network-2

The entity’s host is added to each named network. Each network named in the list is implicitly created, if not previously known. The special “well-known” network “management” is automatically added to every entity. By default this will permit access from the AMP node. (This can be changed as described in the section on configuration.)

Permitting Access

The networks-ingress rules on an entity declare what access is permitted to its host from other sources.

brooklyn.initializers:
- type: io.cloudsoft.amp.networking.NetworkSecurityCustomizer
  brooklyn.config:
    networks-ingress:
      - network: public
        exposing:
        - http.port
      - network: my-network-1
        exposing:
        - http.port
      - network: my-network-2
        exposing:
        - 22

Each element in the list is a map declaring a permitted access from some source to this entity’s host. The keys in the map are:

1. network: this defines the source from which access will be permitted.
2. exposing: this defines the ports and protocols which the source may use to access this entity’s host.

The network value is the name of a network security group defined in the blueprint for this application, either in some networks part of a NetworkSecurityCustomizer, or in an ingress rule. The special network public can be used as a network name to permit connections from the external internet on a specific port.

The exposing value indicates what port access will be permitted on. It can be specified in one of three ways, in order of preference:

1. A sensor name, e.g. http.port.
2. A configuration key, e.g. http.config.key.
3. A literal port value, e.g. 22.

Both single values and a list of values are accepted. AMP DSL is not supported. The port specified by the exposing value will be opened to hosts in the specified network. At present all TCP and UDP access is opened to the port. Additionally, ICMP traffic is permitted. In future this will support more precise specification.

Customizing Clusters

NetworkSecurityCustomizer may be applied to a DynamicCluster just as to any other entity, however, in the case of a cluster, its behaviour takes into account the requirements of a cluster. In particular, in the case of a cluster, the port values on which servers in the member entities listen may be taken from a port range. The rules created by the NetworkSecurityCustomizer take this into account. In the underlying cloud a separate security group (or equivalent) is created for each member of the cluster, and the specific port chosen from the range is used as the value in the accessibility rules created.

Configuration Keys

NetworkSecurityCustomizer has the following configuration keys:

The ‘enforcement’ policy key values are

Security groups specific configuration:

If the customizer detects that is not possible to immediately delete security groups when a host stops, it will keep trying to delete them for a short time afterwards. This timeout controls how long it will try for.

Azure specific configuration:

GCE specific configuration:

None.

Visualizing Network Security Groups

The project includes an experimental entity for visualizing the membership of network security groups. To enable it include an entity of type io.cloudsoft.amp.networking.entity.NetworkSecurityVisualizer as a child of the root application entity. It presents a group with members for each network security group created by NetworkSecurityCustomizer. Each group publishes a sensor named group.targets that contains the other entities and ports to which its members have been granted access.

Examples

A sample three-tier web application is provided at examples/riak-example.yaml.

Deployment Time

At present the implementation of network security is carried out using the mechanism of security groups where supported by jclouds. When the jclouds provider for the underlying cloud does not support the security groups abstraction AMP will refuse to provision blueprints containing network security configuration unless the enforcement parameter is explicitly set to disabled.

Supported Clouds

NetworkSecurityCustomizer has been tested against Amazon EC2, OpenStack Mitaka, Google Compute Engine and Azure ARM.

Amazon EC2 and OpenStack

One “marker” security group is created for each unique name in networks. The group is configured to allow TCP, UDP and ICMP traffic within the group and all outbound traffic. Each instance provisioned is attached to the marker groups on the corresponding entity and has a unique group defining inbound rules for access from other marker groups.

To ensure management access from AMP one final group is created allowing access on all ports from the set of AMP servers managing the corresponding entity within AMP. It is attached to all provisioned instances.

Azure ARM

Constraints on how security groups are used mean the implementation in Azure must differ slightly. In particular, VMs, subnets and NICs may only be associated with a single (Azure) network security group.

By default AMP creates:

• A resource group and virtual network for each AMP application
• A subnet permitting traffic on all ports from the set of AMP servers managing the application
• A subnet permitting traffic on all ports between its members for each unique group in networks
• An Azure network security group controlling ingress for each entity, including rules for public access.

Virtual machines have a network interface on each subnet its AMP entity references in networks.

The Azure ARM network security provider exposes additional configuration:

See also Azure documentation on:

• Network security groups
• Networking limits
• Address ranges applicable to VNets

High Availability

When high availability is enabled the ingress rules for the management network group are periodically refreshed to reflect the set of AMP servers in the cluster. The ingress group grants access to the public IP of each HA member and to other members of the management-<plane id> group. Administrators of the HA cluster are expected to set this second group on HA members.

Known Issues

• AMP 4.3: NetworkSecurityCustomizer is effectively unusable in OpenStack due to an inefficiency in the OpenStack Nova jclouds provider. See jclouds issue 1235 for details.

• AMP 4.3: The UI does not present group membership, which hobbles NetworkSecurityVisualizer. To work around this view the entity in the classic AMP UI.