Protecting host with calico

1. Anirban Sen Chowdhary

2. Project Calico, a Tigera open-source project that provides a
layer 3 network implementation, aimed at scalable datacenter
deployments. Compared to traditional network overlays, Calico
provides a more efficient implementation with minimal packet
encapsulation. This allows better usage of node resources and a
simple yet powerful network stack for your infrastructure.

3. Calico is able to secure the network interfaces of the host itself with the security policy
model.
RHEL (7.1, 7.2, 7.3, 7.4)
Ubuntu (16.04, 17.04)
SLES (12, 12 SP1, 12 SP2)
It supports the same rich security policy model for host endpoints that it supports for
workload endpoints. It does not support setting IPs or policing MAC addresses for host
interfaces, it assumes that the interfaces are configured by the underlying network
fabric.

4. Build Calico components:
Calico components include calicoctl and calico/node .
There are two ways to build calicoctl: natively, and dockerized
calico/node can be regarded as a helper container that bundles together the
various components required for networking containers with Calico.

5. Project Calico defines endpoints as network interfaces.
Endpoints are generally two types: Host and Workload.
Host endpoints defines network interfaces that are static with respect to Calico’s
perspective.
Workload endpoints involves lifecycles that are managed by an orchestrator and are
typically created and destroyed in conjunction with scheduling and destroying
workloads.
Also, Calico distinguishes workload endpoints from host endpoints by a configurable
prefix.
As we know, within the Calico policy data model, both types of endpoints can be
associated with a set of labels, where the orchestrator supports the concept of labels,
such as Kubernetes, then these come from the orchestrator. Or else they can be
applied to the endpoint via Calico’s APIs.

6. Run Calico to Secure Host Interfaces:
After building calictoctl and calico-felix, it is ready to run as follows:
1) Creating basic connectivity and Calico policy
2) Creating host endpoint objects
3) Creating more security policy
All these 3 steps are defined in next slides.

7. 1) Creating basic connectivity and Calico policy:
At the beginning when a host endpoint is added, if there is no security policy for that
endpoint, so Calico will default to denying traffic to/from that endpoint.
Need to create a failsafe Calico security policy
Need to create a single policy resource, which can be applied to all known endpoints,
allows inbound ssh access from a defined “management” subnet, allows outbound
connectivity to etcd on a particular IP.
cat << EOF | calicoctl create -f - - apiVersion: v1 kind: policy metadata: name: failsafe
spec: selector: "all()" order: 0 ingress: - action: allow protocol: tcp source: nets: - "<your
management CIDR>" destination: ports: [22] - action: allow protocol: icmp egress: -
action: allow protocol: tcp destination: nets: - "<your etcd IP>/32" ports: [<your etcd
ports>] - action: allow protocol: udp destination: ports: [67] EOF

8. 2) Creating host endpoint objects:
For each host endpoint that we want Calico to secure, we’ll need to create a host
endpoint object in etcd. We can use the calicoctl create command to create a host
endpoint resource (hostEndpoint).
Generally, there will be 2 ways to specify the interface that a host endpoint should refer
to.
Specify
1) Name of the interface
2) Expected IP address.
In both the cases, we’ll also need to know the name given to the Calico node running on
the host that owns the interface; which in most cases this will be the same as the
hostname of the host.

9. If we take an example to secure the interface named eth2 with IP 10.0.0.3 on host my-
host, run the command below:
We need to remember while running this command to replace the bracket with
appropriate values for our deployment.
cat << EOF | calicoctl create -f - - apiVersion: v1 kind: hostEndpoint metadata: name:
<name of endpoint> node: <node name or hostname> labels: role: webserver
environment: production spec: interfaceName: eth2 profiles: [<list of profile IDs>]
expectedIPs: ["10.0.0.3"] EOF

10. 3) Creating more security policy:
selector-based security policy with bare-metal workloads should be used that allows
ordered policy to be applied to endpoints that match particular label selectors.
example, we could add a second policy for webserver access:
cat << EOF | dist/calicoctl create -f - - apiVersion: v1 kind: policy metadata: name:
webserver spec: selector: "role=="webserver"" order: 100 ingress: - action: allow
protocol: tcp destination: ports: [80] egress: - action: allow EOF

11. For more information visit
https://www.projectcalico.org/
https://docs.projectcalico.org/v2.6/introduction/
https://blog.tigera.io/tagged/calico