Leveraging security to your service mesh

with Istio and Kiali

@xeviknal

@kialiProject

Xavier Canal

@xeviknal

@kialiProject

Agenda

  • New paradigm, new security concerns

  • Istio security features

    • Auto-discovery

    • Mutual TLS

    • RBAC

    • Audit

  • Q&A

@xeviknal

@kialiProject

Monolith to Microservices

@xeviknal

@kialiProject

NEW SECURITY CONCERNS

NEW PARADIGM

@xeviknal

@kialiProject

Target discovery

@xeviknal

@kialiProject

Lots of services to protect

Services are dynamic

Multiple workloads per service

Few components to protect

Pieces are very well-known

Almost static architecture

Impersonation

@xeviknal

@kialiProject

One point per service

Higher network usage

Few points to impersonate

Data protection

@xeviknal

@kialiProject

Each service receives and sends data

Higher network usage

Few components to protect

Access Control

@xeviknal

@kialiProject

Each service has at least one endpoint

Consumers need to be identified

Multiple workloads to protect

Few public points

Consumers are unknown

Audit

@xeviknal

@kialiProject

Each service may have unauthorized access

Few access points to log

ISTIO

PROTECTING

THE SERVICE MESH

@xeviknal

@kialiProject

WITH

SECURITY BY DEFAULT

No changes needed for application code and infrastructure

@xeviknal

@kialiProject

DEFENSE IN DEPTH

Integrate with existing security systems to provide multiple layers of defense

@xeviknal

@kialiProject

ZERO-TRUST NETWORK

Build security solutions on untrusted networks

@xeviknal

@kialiProject

HOW?

@xeviknal

@kialiProject

Auto-discovery

  • Discover all the pieces you have to protect
  • Almost real time discovery
  • Detect unexpected connections between services

@xeviknal

@kialiProject

SERVICE MESH

Demo

Deployment

apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookinfo-productpage
---
apiVersion: v1
kind: Service
metadata:
  name: productpage
  labels:
    app: productpage
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: productpage
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: productpage-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: productpage
        version: v1
    spec:
      serviceAccountName: bookinfo-productpage
      containers:
      - name: productpage
        image: istio/examples-bookinfo-productpage-v1:1.8.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080
  • Only Kubernetes entities
  • Needs Istio sidecar injection

istioctl kube-inject -f  step1.yaml |kubectl apply -f

@xeviknal

@kialiProject

auto-discovery

Strong Identity

  • Provide identity to each workload
  • Necessary for:
    • mTLS
    • RBAC
    • Secure naming

@xeviknal

@kialiProject

SPIFFE

  • Secure Production Identity Framework For Everyone
  • Creates a universal naming convention
  • How to encode that name in a X.509 file (SVID)
  • How a client validates a X.509 certificate to authenticate the SPIFFE identity

@xeviknal

@kialiProject

Strong Identity - how?

cat chain-example.pem | openssl x509 -noout -text

@xeviknal

@kialiProject

Mutual TLS Authentication

@xeviknal

@kialiProject

Are you who you say you are?

Mutual TLS Authentication

  • Ensure both ends of communications are legit
  • Encrypt service-to-service communications
  • Envoy and Pilot involved (secure naming)

@xeviknal

@kialiProject

Demo

Enabling mTLS

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "details-enable-mtls"
spec:
  host: details
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

Authentication methods accepted on workload(s) 

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
spec:
  peers:
  - mtls:
      mode: PERMISSIVE

Rules applied on client-side after routing

@xeviknal

@kialiProject

Policy

DestinationRule

kubectl apply -f step3.yaml -n bookinfo

@xeviknal

@kialiProject

service and namespace mTLS

@xeviknal

@kialiProject

Can ServiceA perform Action on ServiceB?

RBAC system

RBAC system

  • Fine-grained access policy
  • Consistent and homogeneous across the mesh
  • Talks about services and versions
    instead of pods, deployments
  • Strong identities needed

@xeviknal

@kialiProject

Demo

ServiceRole

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: details-reviews-viewer
  namespace: bookinfo
spec:
  rules:
  - services:
      - "details.bookinfo.svc.cluster.local"
      - "reviews.bookinfo.svc.cluster.local"
    methods: ["GET"]
    constraints:
      - key: "destination.labels[version]"
        values: ["v1"]

List of permissions:

  • Object: Service
  • Action: method + Path

@xeviknal

@kialiProject

ServiceRole

Binding

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
 name: bind-details-reviews
 namespace: bookinfo
spec:
 subjects:
 - user: "cluster.local/ns/bookinfo/sa/bookinfo-productpage"
 roleRef:
   kind: ServiceRole
   name: "details-reviews-viewer"

List of subjects attached to a role:

  • Authenticated SVC
  • Authenticated end-user

@xeviknal

@kialiProject

kubectl apply -f step5.yaml -n bookinfo

@xeviknal

@kialiProject

reviews and details v1 only

Auditing

  • Distributed traces
  • Logging

@xeviknal

@kialiProject

THE SERVICE MESH

Demo

@xeviknal

@kialiProject

Logs and traces

Leverage security with:

  • Auto-discovery
  • Mutual TLS
  • RBAC system
  • Distributed Tracing
  • Logging

@xeviknal

@kialiProject

THANKS

@xeviknal

@kialiProject

@twistlockteam

kubectl apply -f step4.yaml -n bookinfo

@xeviknal

@kialiProject

mesh-wide mTLS

Certificate rotation

  • TTL = 3600s (1h) to scope attacks
  • OR Attacker has to hack certificate rotation

@xeviknal

@kialiProject

THE SERVICE MESH

Lab