Basic Network Isolation
This guide provides a simple way to try out rkt network isolation with Calico.
It requires a cluster of nodes configured with Calico networking, and expects
that you have rkt
installed and calicoctl
configured to interact with the
cluster.
You can quickly and easily deploy such a cluster by following one of the getting started guides
For simplicity, we assume you have a two node cluster with the node names
calico-01
and calico-02
. If your nodes have different names, adjust the
instructions accordingly.
1. Verify Calico service is running
Your installation should have installed and started the Calico service on each node. You
can check that it’s running using sudo rkt list
.
$ sudo rkt list
UUID APP IMAGE NAME STATE CREATED STARTED NETWORKS
b52bba11 node quay.io/calico/node:v1.0.2 running 10 seconds ago 10 seconds ago
2. Create the networks
You can configure multiple networks when using rkt. Each network is represented by a configuration file in
/etc/rkt/net.d/
. By default, when using Calico CNI, connections to a given container are only allowed
from containers on the same network. This can be changed by applying additional Calico policy - which will
be discussed in advanced tutorials.
To define a rkt network for Calico, create a configuration file in /etc/rkt/net.d/
.
- Each network should be given a unique “name”.
- To use Calico networking, specify “type”: “calico”
- To use Calico IPAM, specify “type”: “calico-ipam” in the “ipam” section.
Calico will create an identically named profile for each Calico-rkt network, by default the policy specified in the profile allows full communication between containers within the same network (i.e. using the same profile) but prohibits ingress traffic from containers on other networks.
This worked example creates two rkt networks. Run these commands on both calico-01
and calico-02
cat >/etc/rkt/net.d/10-calico-network1.conf <<EOF
{
"name": "network1",
"type": "calico",
"ipam": {
"type": "calico-ipam"
}
}
EOF
cat >/etc/rkt/net.d/10-calico-network2.conf <<EOF
{
"name": "network2",
"type": "calico",
"ipam": {
"type": "calico-ipam"
}
}
EOF
3. Create test container
With the networks created, let’s start some containers. We’ll create a
container on calico-01
in network1
, and then create containers on calico-02
in each network to check connectivity to the first container. For this tutorial,
the container we create on calico-01
will be a busybox
image running a simple HTTP daemon httpd
serving up the containers local filesystem over HTTP.
On calico-01
Create the container in network1
. Note that we include a suffix :IP=192.168.0.0
, this
is used to pass the IP environment through to the network plugin which
Calico IPAM uses to assign a specific IP address. We use a fixed IP address to
simplify the steps in this tutorial, however if the suffix is omitted, Calico IPAM will
automatically select an IP address to use from it’s configured IP Pools.
sudo rkt run --net=network1:IP=192.168.0.0 docker://busybox --exec httpd -- -f -h / &
Use rkt list
to see the IP.
$ sudo rkt list
UUID APP IMAGE NAME STATE CREATED STARTED NETWORKS
6876aae5 busybox registry-1.docker.io/library/busybox:latest running 11 seconds ago 11 seconds ago network1:ip4=192.168.0.0, default-restricted:ip4=172.16.28.2
b52bba11 node quay.io/calico/node:v1.0.2 running 2 minutes ago 2 minutes ago
We now have a busybox
container running on the network network1
with an IP
address of 192.168.0.0
. You will see that rkt also creates a second network
called default-restricted
- this is used for communication with the rkt
metadata service running on the host and is discussed in the
rkt documentation.
4. Validate intra-network connectivity
Now that we have created the container on calico-01
and we know its IP address.
We can access it using wget
from containers running on
either host, as long as they are created in the same network.
e.g. On calico-02
use wget to access the container running on calico-01
sudo rkt run --net=network1 docker://busybox --exec=/bin/wget -- -T 3 192.168.0.0/etc/passwd 2>/dev/null
Expected output:
[ 576.042144] busybox[5]: Connecting to 192.168.0.0 (192.168.0.0:80)
[ 576.046836] busybox[5]: passwd 100% |*******************************| 334 0:00:00 ETA
This command runs the wget
command in a busybox container to fetch the passwd
file from our host.
‘-T 3’ tells wget to only wait for 3 seconds for a response. Stderr is redirected to /dev/null
as we’re
not interested in the logs from rkt
for this command.
You can repeat this command on calico-01
and check that access works the same
from any server in your cluster.
5. Checking inter-network isolation
Repeat the above command but try to access the container on calico-01
from network2.
Because we’ve not allowed access between these networks, the command will fail.
sudo rkt run --net=network2 docker://busybox --exec=/bin/wget -- -T 3 192.168.0.0/etc/passwd 2>/dev/null
Expected output:
[ 621.119210] busybox[5]: Connecting to 192.168.0.0 (192.168.0.0:80)
[ 624.120081] busybox[5]: wget: download timed out
6. Verify Calico profiles were created
You can use the calicoctl get profiles
command line tool to verify that the Calico CNI
plugin created two profiles, network1
and network2
:
$ calicoctl get profiles
NAME
network1
network2
7. Resetting/Cleanup
If you want to start again from the beginning, then run the following commands on both hosts to ensure that all the rkt containers are removed.
# Stop the network1/network2 containers
sudo rkt stop --force <Container_UUID>
# Remove the stopped containers
sudo rkt list --no-legend | cut -f1 | sudo xargs rkt rm