This document serves as an introduction to using Cilium to enforce policies
based on AWS instances metadata. It is a detailed walk-through of getting a
single-node Cilium environment running on your machine. It is designed to take
15-30 minutes with some experience running Kubernetes.

This guide will work with any approach to installing Cilium, including minikube,
as long as the cilium-operator pod in the deployment can reach the AWS API server
However, since the most common use of this mechanism is for Kubernetes clusters
running in AWS, we recommend trying it out along with the guide: Installation on AWS EKS .

Before installing Cilium, a new Kubernetes Secret with the AWS Tokens needs to
be added to your Kubernetes cluster. This Secret will allow Cilium to gather
information from the AWS API which is needed to implement ToGroups policies.

Once the secret has been created and validated, the cilium-operator pod must be
restarted in order to pick up the credentials in the secret.
To do this, identify and delete the existing cilium-operator pod, which will be
recreated automatically:

Cilium’s AWS Metadata filtering capability enables explicit whitelisting
of communication between a subset of pods (identified by Kubernetes labels)
with a set of destination EC2 VMs (identified by membership in an AWS security group).

In this example, the destination EC2 VMs are a member of a single AWS security
group (‘sg-0f2146100a88d03c3’) and pods with label class=xwing should
only be able to make connections outside the cluster to the destination
VMs in that security group.

To enable this, the VMs acting as Kubernetes worker nodes must be able to
send traffic to the destination VMs that are being accessed by pods. One approach
for achieving this is to put all Kubernetes worker VMs in a single ‘k8s-worker’
security group, and then ensure that any security group that is referenced in a
Cilium toGroups policy has an allow all ingress rule (all ports) for connections from the
‘k8s-worker’ security group. Cilium filtering will then ensure that the only pods allowed
by policy can reach the destination VMs.

In this case we’re going to use a demo application that is used in other guides.
These manifests will create three microservices applications: deathstar,
tiefighter, and xwing. In this case, we are only going to use our xwing
microservice to secure communications to existing AWS instances.

Kubernetes will deploy the pods and service in the background. Running kubectlgetpods,svc will inform you about the progress of the operation. Each pod
will go through several states until it reaches Running at which point the
pod is ready.

Every time that a new policy with ToGroups rules is added, an equivalent policy
(also called “derivative policy”), will be created. This policy will contain the
set of CIDRs that correspond to the specification in ToGroups, e.g., the IPs of
all instances that are part of a specified security group. The list of IPs will
be updated periodically.

$ kubectl get cnp
NAME AGE
to-groups-sample 11s
to-groups-sample-togroups-044ba7d1-f491-11e8-ad2e-080027d2d952 10s

Eventually, the derivative policy will contain IPs in the ToCIDR section: