Embed Size (px)
Citation preview
Securing Microservices with Istio
Dan Berg@dancberg
Lin Sun@linsun_unc
Problem Statement
IT’s shift to a modern distributed architecture has left enterprises unable to monitor, manage or secure their services in a consistent way.
Intelligent Routing and Load Balancing
Control traffic between services with dynamic
route configuration, conduct A/B tests, release
canaries, and gradually upgrade versions using
red/black deployments.
Resilience Across Languages and Platforms
Increase reliability by shielding
applications from flaky networks and
cascading failures in adverse conditions.
Secure Access with Fleet Wide Policy Enforcement
Apply organizational policy to
the interaction between services,
ensure access policies are
enforced and enable secure
communication between
services.
In-Depth Telemetry and Reporting
Understand the dependencies between services, the nature and flow of traffic between them and quickly identify issues with distributed tracing.
Components of Istio
1. Envoy proxy, to mediate all inbound and outbound traffic for all services in the service mesh. Leverages Envoy features such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC proxying, circuit breakers, health checks, staged rollouts with %-based traffic split, fault injection, and rich metrics.
2. Pilot: Programming envoys and responsible for service discovery, registration and load balancing
3. Istio-Auth provides strong service-to-service and end-user authentication using mutual TLS, with built-in identity and credential management
4. Mixer is responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the Envoy proxy and other services.
Our sidecar of choice - Envoy
A C++ based L4/L7 proxy
Low memory footprint
Battle-tested @ Lyft
100+ services
10,000+ VMs
2M req/s
Plus an awesome team willing to work with the community!
Goodies:❖ HTTP/2 & gRPC❖ Zone-aware load balancing w/ failover❖ Health checks, circuit breakers, timeouts, retry
budgets❖ No hot reloads - API driven config updates
Istio’s contributions:❖ Transparent proxying w/ SO_ORIGINAL_DST❖ Traffic routing and splitting❖ Request tracing using Zipkin❖ Fault injection
Putting it all together
svcA
Envoy
Pod
Service A
svcB
Envoy
Service B
Pilot
Control Plane API
Mixer
Discovery & Config data to Envoys
Policy checks, telemetry
Control flow during request processing Istio-Auth
TLS certs to Envoy
Traffic is transparently intercepted and proxied. App is
unaware of Envoy’s presence
HTTP/1.1, HTTP/2, gRPC, TCP with or without TLS
Envoy
HTTP/1.1, HTTP/2, gRPC, TCP with or
without TLS
Internet
Ingress gateway
ResiliencyIstio adds fault tolerance to your application without any changes to code
Resilience features❖ Timeouts❖ Retries with timeout budget❖ Circuit breakers❖ Health checks❖ AZ-aware load balancing w/
automatic failover❖ Control connection pool size and
request load
// Circuit breakers
destination: serviceB.example.cluster.local policy: - tags: version: v1 circuitBreaker: simpleCb: maxConnections: 100 httpMaxRequests: 1000 httpMaxRequestsPerConnection: 10 httpConsecutiveErrors: 7 sleepWindow: 15m httpDetectionInterval: 5m
Resiliency Testing
Systematic fault injection to identify weaknesses in failure recovery policiesHTTP/gRPC error codes
Delay injection
svcA
Envoy
Service A
svcB
Envoy
Service B
svcC
Envoy
Service C
Timeout: 100msRetries: 3300ms
Timeout: 200msRetries: 2400ms
Traffic Splitting
svcA
Envoy
Pod
Service A
svcB
Envoy
Serv
ice
B
http://serviceB.example
Pod Labels: version: v1.5env: us-prod
svcB
Envoy
Pod Labels:version: v2.0-alpha, env:us-staging
serviceB.example.cluster.local
Traffic routing rules
99%
1%
Rules API
Istio-Manager
Traffic control is decoupled from infrastructure scaling
// A simple traffic splitting rule
destination: serviceB.example.cluster.localmatch: source: serviceA.example.cluster.local route: - tags: version: v1.5 env: us-prod weight: 99- tags: version: v2.0-alpha env: us-staging weight: 1
svcA
Service AsvcB
Service Bversion: v1
Pod 3Pod 2
Pod 1
Content-based traffic steering
svcA
Service A
svcB
Service B
version: v1
Pod 3Pod 2
Pod 1
User-agent: *Android*
svcB’
version: canary
Pod 4
User-agent: *iPhone*
Traffic Steering// Content-based traffic steering rule
destination: serviceB.example.cluster.local match: httpHeaders: user-agent: regex: ^(.*?;)?(iPhone)(;.*)?$ precedence: 2 route: - tags: version: canary
Demo Time
Thank You!RedHat
Pivotal
WeaveWorks
Tigera
Datawire
Scytale (SPIFFE)
MicroSoft
Uber (Jaeger)
… and you!
Community Partners
