This was used in a presentation at All Things Open 2017 in Raleigh, NC. It describes the ability to manage microservices using the joint Istio project from IBM, Google, and Lyft. In this presentation we explore the overall value and architecture of Istio and walk through key mechanisms for using Istio to drive highly secure microservices.

1. Securing Microservices with Istio
Dan Berg
@dancberg
Lin Sun
@linsun_unc

2. 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.

3. http://istio.io
Introducing Istio

4. 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.

5. Resilience Across Languages and Platforms
Increase reliability by shielding
applications from flaky networks and
cascading failures in adverse conditions.

6. 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.

7. 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.

8. 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.

9. 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

10. 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

11. Istio - Security at Scale
spiffe.io

12. Resiliency
Istio 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

13. Resiliency Testing
Systematic fault injection to identify weaknesses in failure recovery policies
HTTP/gRPC error codes
Delay injection
svcA
Envoy
Service A
svcB
Envoy
Service B
svcC
Envoy
Service C
Timeout: 100ms
Retries: 3
300ms
Timeout: 200ms
Retries: 2
400ms

14. Traffic Splitting
svcA
Envoy
Pod
Service A
svcB
Envoy
ServiceB
http://serviceB.example
Pod Labels:
version: v1.5
env: 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.local
match:
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

15. svcA
Service A
svcB
Service B
version: v1
Pod 3
Pod 2
Pod 1
Content-based traffic steering
svcA
Service A
svcB
Service B
version: v1
Pod 3
Pod 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

16. Demo Time

17. Thank You!
RedHat
Pivotal
WeaveWorks
Tigera
Datawire
Scytale (SPIFFE)
MicroSoft
Uber (Jaeger)
… and you!
Community Partners