Network Policy


Rancher allows users to configure a network policy within an environment. A network policy allows you to define specific networking rules within the environment. By default, all containers are able to communicate with each other, but there may be restrictions that you want to place on your containers.

Launching the Network Policy Manager

When setting up an environment template, you can enable the Network Policy Manage item.

Alternatively, if you already have an environment set up, you can select and launch the Network Policy Manager from the Rancher catalog.

Note: Network Policy Manager is currently only compatible with an environment using the Cattle container orchestration. Environment templates will restrict which ones are compatible based on orchestration, but all options are available from the catalog.

Managing Network Policy Rules via API

In the network resource, there is a defaultPolicyAction and a policy field that define how the communication between containers work. The policy field is an ordered array of network policy rules. Using Rancher’s API, you can manage the network policy for the environment.

Finding the API Endpoint for the Network

In order to manage your network policy, you will need to find the Network resource. As a network is part of an environment, the endpoint to find networks will be:

http://<RANCHER_SERVER_IP>/v2-beta/projects/<PROJECT_ID>/networks/<NETWORK_ID>`

How to find the endpoint for your network:

  1. Click on API and expand the Advanced Options. In the Environment API Keys, click on the Endpoint (v2-beta).
    > Note: Environment in the UI is a project in the API.
  2. Search for networks in the list of links for the environment. Click on the link.
  3. Search for the name of the networking driver that you’ve launched for your environment. For example, it could be ipsec. Click on the self link for the network.
  4. On the right hand side under Operations, click on Edit for the network. In the defaultPolicyAction, you can change the default policy and in the policy field, you can manage your network policy rules.

Note: Support for managing network policy rules will be added to the UI.

Default Policy

By default, all containers are enabled and allowed to communicate with each other. In the API, you will see that the defaultPolicyAction has been set to allow.

To change the default policy to deny communication between all containers, you would need to edit the defaultPolicyAction to be deny.

Network Policy Rules

Network policy rules set container communication for specific sets of containers.

Containers within a Stack

To enable communication between containers only within the same stack:

{
  "within": "stack",
  "action": "allow"
}

To disable communication between containers within the same stack:

{
  "within": "stack",
  "action": "deny"
}

Containers based on Labels

To enable communication between containers based on their label values:

{
  "between": {
    "groupBy": "<KEY_OF_LABEL>"
  },
  "action": "allow"
}

To disable communication between containers based on their label values:

{
  "between": {
    "groupBy": "<KEY_OF_LABEL>"
  },
  "action": "deny"
}

Examples

Container Isolation

No containers can communicate with any other container in the environment.

  • Set the defaultActionPolicy to deny.

Stack Isolation

Containers within the same stack are only allowed to communicate with each other, but the container cannot communicate with any containers in other stacks.

  • Set the defaultActionPolicy to deny.
  • Add the rule to the policy:
{
  "within": "stack",
  "action": "allow"
}

Label Isolation

Containers with matching labels can communicate with other matching labels. The rule uses the key of the label to group which containers can communicate with each other.

Let’s assume we have the following set of stacks in the environment.

stack_one:
  service_one:
    label: com.rancher.department = qa
  service_two:
    label: com.rancher.department = engineering
  service_three:
    label: com.rancher.location = cupertino

stack_two:
  service_one:
    label: com.rancher.department = qa
  service_two:
    label: com.rancher.location = cupertino

stack_three:
  service_one:
    label: com.rancher.department = engineering
  service_two:
    label: com.rancher.location = phoenix

Communication between only containers of with the same com.rancher.department label.

  • Set the defaultActionPolicy to deny.
  • Add the rule to the policy:
{
  "between": {
    "groupBy": "com.rancher.department"
  },
  "action": "allow"
}

There are two distinct label pairs with the same key (i.e. com.rancher.department).

  • Containers with the com.rancher.department = engineering would be able to communicate with each other, but no other container. In our example, any containers from stack_one.service_two and stack_three.service_one would be able to communicate to each other, but no other containers.
  • Containers with the com.rancher.department = qa would be able to communicate with each other but no other container. In this example, any containers from stack_one.service_two and stack_two.service_two would be able to communicate with each other, but no other containers.
  • Containers without a label with a key com.rancher.department would not be able to communicate with any other containers.