Sidecar

What is a Sidecar?

A sidecar provides infrastructure services to an application service instance by intercepting its traffic. It is deployed adjacent to the application, like a sidecar attached to a motorcycle. 

Cloud-native applications are built using microservice as its composable unit using Docker as the defacto standard for implementing container technology. Communication between an often hundreds and thousands of these disaggregated microservices has resulted in an explosion in the east-west traffic, with no concrete perimeter to enforce security policies. Additionally, they lack any single ingress/egress point where typical traffic management related services such as load balancing, high availability, scalability, acceleration, etc. can be provided (in the traditional monolithic applications with only north-south traffic, reverse proxies provided most of these traffic management related services). 

Offloading such traffic management services outside the application code has many advantages – such as decoupling of application development and maintenance from the infrastructure services, polyglot development, smooth upgrades, etc. But because the traditional model of deploying a reverse proxy between the client and the application no longer works in the new cloud-native paradigm, service mesh architectures such as Linkerd and Istio were developed to solve this problem.  A service mesh acts as a unified data plane across all microservices, providing policy-based communication services to the workloads running in the mesh. 

A sidecar is injected for each application microservice instance and the connectivity mesh amongst the sidecars form the service mesh. The sidecar handles all ingress and egress traffic for the microservice providing services such as dynamic service discovery, load balancing, health checks, TLS termination, HTTP2 and gRPC proxying, staged rollouts and observability. Sidecars can implement any service that can be abstracted away from the individual application microservices.

What is the difference: Sidecar vs Reverse Proxy?

Unlike a traditional reverse proxy which is deployed close to the server, sidecar is deployed adjacent to the application service instances, implementing basically the same functionality as a reverse proxy does and mediating the ingress and egress traffic. 

Sidecars are transparent to the application service instances themselves. This is typically done using integration with container orchestration tools such as Kubernetes which can inject the sidecar in the same scheduling unit where the application service resides. Unlike traditional reverse proxies which are deployed independent of the application services, sidecars do not need to be aware of the topology of the application services.

This makes sidecars ideal for continuous deployment. They have a centralized control plane that supports declarative configuration and policies as code in JSON/YAML format supporting  Infrastructure as Code, integrates with orchestration tools such as Kubernetes, and CI/CD tools such as Spinnaker and Jenkins X. In contrast, reverse proxies must be deployed using a bolt-on approach to serve the applications.

What are the Key Characteristics of a Sidecar?

The key characteristics of a sidecar are:

1. Cloud Native

• Deployed using latest cloud orchestration platforms like Kubernetes
• Designed to be used with tools like Terraform, CloudFormation, etc. 
• Supports a modern mesh architecture rather than spoke and hub

2. Application Affinity

• Sidecars can reside in the same host, or a logical scheduling unit such as a pod in Kubernetes, as that where the service runs on
• Microservices are not sidecar aware, and traffic is routed to/from the microservices using iptable rules or BPF.

3. Function

• Traffic inspection
• Client-side load balancing
• Circuit breaker capability
• Automatic retries

4. Control Plane

• Centralized control plane to manage the distributed sidecars
• Declarative configuration and policies using JSON or YAML lending to the Infrastructure-as-Code
• Support for REST APIs or APIs over gRPC

5. Scalability

• Horizontal scaling and elasticity, integrates with container orchestration platforms such as Kubernetes 
• One less network hop in latency for traffic

6. Security

• TLS encryption/decryption
• Inbuilt identity protection using mTLS
• Provides native authentication and authorization capability

7. APIs

• API-first design
• Supports integration with DevOps tools such as Prometheus, Grafana, ElasticSearch, FluentD Kubernetes, for logging, monitoring, visualization, CI/CD, etc.

8. Telemetry

• Rich telemetry data with event logs, metrics and traces
• Identifying individual connections and transactions with focus on the four golden signals of latency, traffic, errors and saturation (e.g. transaction latency, query per second for traffic, errors for TCP connection resets, etc.)
• Advanced integration with logging and observability stack such as ELK, Prometheus and Grafana

9. Continuous Deployment

• Supports continuous deployment because it’s control plane can integrate with CI/CD tools, such as Jenkins X, Spinnaker, etc.

The Cyral Data Layer Sidecar 

Similar to deployment for application services, reverse proxies have also been deployed in front of database servers for improving visibility and monitoring. Database activity monitoring (DAM) products, when used in inline network mode, are essentially reverse proxies that monitor all activity on a database including administrator activity and SQL transactions, providing reporting and audit logs, and alerting on any unauthorized activity and policy violations. Database Firewalls, similarly when used as an inline service are reverse proxies, protect databases from threats and are used to control access to the database. 

In the new cloud native architecture, while the traditional DAM and database firewall products have become operationally infeasible, the sidecars of the service meshes aren’t designed to handle database protocols. This led Cyral to develop the Data Layer Sidecar, a stateless interception service for data endpoints, that can be deployed as part of typical modern cloud-native workflows by natively integrating with various service orchestration tools.

Cyral’s data layer sidecar essentially acts as a circuit breaker for the cloud native applications connecting to the modern data layer consisting of database, data warehouses and pipeline. These could include managed or hosted MySQL, PostgreSQL, or SaaS data services such as Confluent, Snowflake, BigQuery, Redshift, etc. Cyral sidecars can be deployed in customer’s  cloud or on-prem environment as a Kubernetes service, autoscaling group, cloud function or host-based install. All the data flows and sensitive information stays inside the customer’s environment where the sidecar is deployed, creating no risk of spillage.