7 Ways to Deploy Signal Sciences in Kubernetes

Sports coaches used to rely on paper playbooks to review strategy with their teams. Now, many leverage the innovation of tablet computers for their speed and flexibility in reviewing key plays and athlete performance. Likewise, DevOps teams adopt new tools and frameworks like application containers and Kubernetes, a container orchestration system, to more efficiently and quickly build and release applications.

Containers, like Docker, package together an application with everything it needs to run consistently in any environment, so developers can release code faster. With the rise of container usage, Kubernetes has become a popular means to automate the deployment and management of containerized applications at scale: 72% of enterprises use Kubernetes in production to remove the headaches and hurdles of rapid, automated software deployment.

At Signal Sciences, we recognized the need to provide flexible installation options to customers leveraging Kubernetes. In a prior blog post, we covered the first of seven ways to use Signal Sciences with Kubernetes to autoscale Layer 7 security for your web applications. In this post, we’ll outline the comprehensive list of ways to install Signal Sciences with Kubernetes.

First, a quick refresher guide to our software components: we built and patented communication between an agent and a module that operate on customers’ infrastructure and communicate with our Cloud Engine out of band to receive updated, enhanced intelligence. The module is not needed when Signal Sciences runs in Reverse Proxy mode, which you’ll read about below.

You can think of our deployment options in a 3x4 matrix: there are 3 “layers” where you can install Signal Sciences in Kubernetes, and 4 “methods” how you can deploy.

Layers

We’ll work our way from the top of the stack down to the application layer with reasons why you’d choose one versus the other based on how your unique organization manages software deployment.

At the top is the Kubernetes ingress controller. Key reasons for choosing this option are if you a) have an ingress controller and b) have a team that wants to centralize the security of all apps residing below/behind the ingress controller.

Second is the middle-tier or service layer, which you’d choose if you a) don’t have an ingress controller or b) are running another load balancer to front traffic but don’t want to install there for any given reason (even though Signal Sciences can install).

Third is the application layer which you’d choose in order to enable application teams to control the install themselves.

Methods

Within each of the layers described above, you can deploy Signal Sciences in conjunction with Kubernetes in any of the following four ways:

1. Run the module and agent in the same container.
2. Run the module and agent in separate sidecar containers.
3. Run the agent in reverse proxy mode in the same application container.
4. Run the agent in reverse proxy mode in a sidecar to the application container.

With three layers and four deployment methods, the flexibility that containers and Kubernetes offer becomes readily apparent with 12 install options. While Signal Sciences supports all 12 options, we highlight examples of the starred methods in the table below:

Method 1: Pod Container — Agent and Module

Here you can deploy the agent and module in the same Kubernetes pod container. The agent and module sit in line with the application.

Method 2: Multi-Container — Agent and Module

This option separates the module and agent. The module would be deployed with the app in a single container, and the agent is deployed in a separate container. Even though the module and agent are in different containers, they’re both in the same Kubernetes pod. The agent and module containers share a volume to communicate via domain socket.

Method 3: Pod Container — Agent in Reverse Proxy Mode

In the event the Signal Sciences agent runs in reverse proxy mode, it can sit in the same pod container as the application. Similar to option 1, Signal Sciences sits in line with the application, but the only difference is the module configuration.

Method 4: Pod Multi-Container — Agent in Reverse Proxy in Sidecar Container

Similar to Option 2, the agent is deployed in reverse proxy mode without a module. The difference is the agent is in a separate container from the application. The request will go through the agent container before allowing it to the application container. The agent and application containers co-exist in the same pod.

For layers 1 and 2, the ingress service is leveraged. Unlike traditional WAFs that require individual rule-tuning for each application that sits behind the ingress service, Signal Sciences requires none of that overhead due to our dynamic detections using our proprietary SmartParse methodology.

Layer 1 + Method 1: Ingress Pod Container — NGINX or HAProxy

This option allows for deploy the module and agent in the same container as the NGINX or HAProxy ingress pod. The module would sit on NGINX or HAProxy, while the agent is in the same container. All requests go through the ingress pod and autoscale as needed. The application pod exists behind the ingress pod.

Layer 1 + Method 2: Ingress Pod Multi-Container — NGINX or HAProxy

Similar to Option 6, with the only difference being that the module and agent are in separate containers within the same ingress pod. Just like Option 3, both the agent and module containers will have to share the domain socket volume. This deployment method protects Kubernetes clusters from exposure to the open internet.

Layer 2 + Method 4: Multi-Service — Agent in Reverse Proxy

This deployment option runs the agent in reverse proxy mode and in a separate pod from the application. The agent pod receives and inspects the request, and blocks or passes the request to the application pod. This allows for autoscaling the agent or application separately.

Ultimate Flexibility to Secure Applications and Microservices

With Signal Sciences, you have ultimate flexibility to secure your applications and microservices quickly no matter how your DevOps team leverages containers with Kubernetes. These installation examples allow our customers to protect their apps on day one while ensuring that their applications will remain secure in the future, even if their app deployments with Kubernetes change.

Top image credit: Michael Gaida / Pixabay.com

Originally published at labs.signalsciences.com.