The Aporeto team has been working hard on our open source Trireme Zero-Trust NetworkPolicy implementation for Kubernetes.
Trireme on Kubernetes has the explicit goal of decoupling NetworkPolicies implementation from your Network CNI plugin choice. This design allows you to secure your Kubernetes applications without any networking gymnastics; alternatively it gives you the freedom to chose whatever network backend that you want.
Next to a complete overhaul to support the GA NetworkPolicies that made it in Kubernetes r1.8, this new version introduces a Trireme-Kubernetes bundle with some optional functionalities:
- Trireme-Kubernetes: Provides the NetworkPolicy implementation for Kubernetes;
- Trireme-Statistics: Offers network flows information from inside your Kubernetes clusters;
- Trireme-CSR: Distributes a unique identity (certificate from a central authority) to authorized pods in your cluster.
The metrics service allows the administrator to get insights on connection patterns in your cluster.
Events are getting generated and stored for every flow and pod in the cluster:
- Flow: Amount of traffic between endpoints;
- Pods: Start and Stop events.
Those events are added to a standard InfluxDB. InfluxDB’s API allows the user to issue queries and highlight flows between specific endpoints.
To illustrate this, the metric framework ships by default with Chronograf and Grafana, two standard visualization front ends for InfluxDB.
“Visualisation for a simple two-tier app. frontend is allowed to communicate to backend, but external is rejected”
A graph reference implementation allows the user to visualize all the pods and every connection between them.
Specific use cases can be developed quickly by querying InfluxDB’s API directly.
Monitoring data flows inside a Kubernetes cluster has always been difficult. However, with this metrics framework, it is now easy to use a simple API to query for analytics and insights
All the details related to this metrics framework are on Github
The identity framework distributes a crypto token, trusted by a central authority, to establish the identity of your authorized pods. Trireme itself needs this functionality as its security implementation requires access to a certificate and key-value pair.
This identity service can be used by any other project with similar use cases. We built it using Kubernetes API extensibility framework, namely the custom resource definition.
The metrics and identity additions to Trireme-Kubernetes open the door to more use-cases.
To learn more, attend our webinar on Monday, 12/4, at 11 AM PST, 2 PM EST.