Slide 1

Slide 1 text

A DEVOPS STATE OF MIND: CONTINUOUS SECURITY WITH KUBERNETES Chris Van Tuin
 Chief Technologist, NA West @chrisvantuin cvantuin@redhat.com https://speakerdeck.com/cvantuin/devopsdays-amsterdam-2019-continuous-security-with-kubernetes

Slide 2

Slide 2 text

ENABLING INNOVATION, WHILE EXECUTING AT SCALE Static &
 Planned Dynamic & 
 Policy Driven Execution Innovation Innovation Execution Old New

Slide 3

Slide 3 text

THE WORLD IS AUTOMATING Those who succeed in automation will win

Slide 4

Slide 4 text

DEV QA OPS THE AVERAGE ENTERPRISE 
 DOES DEPLOYMENTS EVERY 6 TO 9 MONTHS. Walled off people, walled off processes, walled off technologies with surprisingly little to no automation

Slide 5

Slide 5 text

I.T. MUST EVOLVE & KEEP UP

Slide 6

Slide 6 text

BARE METAL VIRTUAL PRIVATE CLOUD OFF-PREMISE ON-PREMISE PUBLIC CLOUD DATA DATA MICROSERVICES: DISTRBUTED SERVICES ACROSS NETWORK B B B B

Slide 7

Slide 7 text

DEVOPS: INCREASED SPEED & FREQUENCY Empowered organization Speed Up 
 Innovation Time Change Move Fast, Break Things Culture of experimentation A 20% vs. 25% Shorten the Feedback Loop Real-time data-driven intelligence & personalization AI /
 ML Data, Data, Data B

Slide 8

Slide 8 text

BARE METAL PRIVATE CLOUD PUBLIC CLOUD VIRTUAL PRODUCTION DEV/TEST HYBRID/MULTI CLOUD: DISSOLVING SECURITY PERIMETER, CONSUMPTION BASED COSTS

Slide 9

Slide 9 text

MULTI-TENANCY: SHARED INFRASTRUCTURE

Slide 10

Slide 10 text

DEVSECOPS

Slide 11

Slide 11 text

DEV QA OPS SECURITY IS AN AFTERTHOUGHT | SECURITY | “Patch? The servers are behind the firewall.” - Anonymous (far too many to name), 2005 - … SECURITY IS AN AFTERTHOUGHT | Security |

Slide 12

Slide 12 text

DEVSECOPS + + DEV QA OPS Culture Process Automation Technology Linux + Containers IaaS Orchestration CI/CD Source Control Management Collaboration Build and Artifact Management Testing Frameworks Hybrid/Multi Cloud Collaborative Transparent Open Agile, Iterative, Automated, Infrastructure as Code Cloud Native INTO AN INNOVATION CENTER Powered by DevOps + Automation + + DEV QA OPS Culture Process 
 Automation Technology Linux + Containers IaaS Orchestration CI/CD Source Control Management Collaboration Build and Artifact Management Testing Frameworks Cloud Native Applications Hybrid Cloud Open Source Agile, Iterative, Continuous, Infrastructure as Code Collaborative Transparent Open

Slide 13

Slide 13 text

DEVSECOPS Shift left: End to end security Reduce Risks, Lower Costs, Speed Delivery, Speed Reaction DEV QA OPS SECURITY IS AN AFTERTHOUGHT | SECURITY | “Patch? The servers are behind the firewall.” - Anonymous (far too many to name), 2005 - … Continuous feedback & improvement Secure coding Everything as code Automation Continuous security testing

Slide 14

Slide 14 text

CONTAINERS ENABLE DEVSECOPS

Slide 15

Slide 15 text

CONTAINERS Software packaging concept that typically includes an application and all of its runtime dependencies CONTAINER CONTAINER APP LIBS HOST OS SERVER APP LIBS DEVSECOPS BENEFITS • Security: bare minimum image, reduce attack surface • Agility: lightweight, quick deployment • Quality: self contained, immutable, no environment diffs • Portability: build once, deploy anywhere

Slide 16

Slide 16 text

https://medium.com/@bibryam/cloud-native-container-design-principles-144ceaa98dba CLOUD NATIVE CONTAINER DESIGN PRINCIPLES: Build Time Does one thing well Built with dependencies, depends on Linux kernel Build once, deploy anywhere Single Concern Principle Self Containment Principle Image Immutability Principle

Slide 17

Slide 17 text

Process Dispensability Principle CLOUD NATIVE CONTAINER DESIGN PRINCIPLES: Runtime Ephemeral - short lived, replaceable Read & react to events APIs to obeserver & manage Resource requirements defined and restricted High Observability Principle Lifecycle Conformance Principle Runtime Confinement Principle

Slide 18

Slide 18 text

Image Format Distribution Spec Runtime Spec

Slide 19

Slide 19 text

DEVSECOPS AT SCALE

Slide 20

Slide 20 text

Scheduling Monitoring Persistence Discovery Lifecycle & health Scaling Aggregation Security MORE THAN CONTAINERS…

Slide 21

Slide 21 text

BARE METAL VIRTUAL PRIVATE CLOUD PUBLIC CLOUD Automated Software Factory
 Speed, Resiliency, Scalability, Security 
 BARE METAL VIRTUAL PRIVATE CLOUD PUBLIC CLOUD Automated Software Factory
 Speed, Resiliency, Scalability, Security 
 BARE METAL VIRTUAL PRIVATE CLOUD PUBLIC CLOUD Automated Software Factory
 Speed, Resiliency, Scalability, Security 
 Speed, Agility, Resiliency, Scalability, Efficiency, Security

Slide 22

Slide 22 text

SECURING CONTAINERS BEST PRACTICES Reduce Attack Surface Least Privilege Layered Security $ sudo Immutable

Slide 23

Slide 23 text

KUBERNETES AUTOMATION

Slide 24

Slide 24 text

DEMO APPLICATION Web App DEV QA OPS THE AVERAGE ENTERPRISE 
 DOES DEPLOYMENTS EVERY 6 TO 9 MONTHS. Walled off people, walled off processes, walled off technologies with surprisingly little to no automation DEV QA OPS THE AVERAGE ENTERPRISE 
 DOES DEPLOYMENTS EVERY 6 TO 9 MONTHS. Walled off people, walled off processes, walled off technologies with surprisingly little to no automation

Slide 25

Slide 25 text

Web Application ORCHESTRATION Speed, Agility Pods Nodes Controller Manager & Data Store (etcd) Ingress / Routes role: web role: app role: web replicas: 1, 
 role: app replicas: 2, 
 role: web Services

Slide 26

Slide 26 text

Pods Nodes Services Web Application role: web role: app role: web replicas: 1, 
 role: app replicas: 2, 
 role: web role: web Controller Manager & Data Store (etcd) Ingress / Routes Health Check HEALTH CHECK Resiliency

Slide 27

Slide 27 text

Web Application 80% CPU Pods Nodes Services role: web role: app role: web Controller Manager & Data Store (etcd) role: app Ingress / Routes replicas: 2 
 role: app replicas: 2, 
 role: web Readiness Probe e.g. tcp, http, script AUTO SCALE Scalability & Efficiency

Slide 28

Slide 28 text

CONTAINER IMAGES

Slide 29

Slide 29 text

docker.io Registry Private Registry FROM fedora:1.0 CMD echo “Hello” Build file Physical, Virtual, Cloud Container Image Container Instance Build Run Ship CONTAINERS ENABLE DEVOPS CONTAINERS ENABLE DEVSECOPS FROM registry.redhat.com/rhel7 RUN groupadd -g 999 appuser && \ useradd -r -u 999 -g appuser appuser USER appuser CMD echo “Hello”

Slide 30

Slide 30 text

CONTAINER IMAGE JAR CONTAINER IMAGE Application Application Language runtimes OS dependencies 1.2/latest 1.1

Slide 31

Slide 31 text

ERGED SOFTWARE 
 UPPLY CHAIN TAINER IMAGE CONTAINER IMAGE Application Language runtimes OS dependencies 1.2/latest 1.1 TAINER IMAGE CONTAINER IMAGE Application Language runtimes OS dependencies 1.2/latest 1.1 TAINER IMAGE CONTAINER IMAGE Application Language runtimes OS dependencies 1.2/latest 1.1 SUPPLY CHAIN CONTAINER IMAGE JAR CONTAINER IMAGE Application Application Language runtimes OS dependencies 1.2/latest 1.1 CONVERGED SOFTWARE SUPPLY CHAIN Build file Container Image CONTAINER IMAGE JAR CONTAINER IMAGE Application Application Language runtimes OS dependencies Container Instance BARE METAL VIRTUAL PRIVATE CLOUD PUBLIC CLOUD Automated Software Factory
 Speed, Resiliency, Scalability, Security 
 Configs / Storage Developer Apps / DB Operations

Slide 32

Slide 32 text

Config Data Kubernetes configmaps secrets Container image Traditional 
 data services, Kubernetes 
 persistent volumes TREAT CONTAINERS AS IMMUTABLE To keep containerized apps portable Application Language runtimes OS dependencies

Slide 33

Slide 33 text

KUBERNETES CONFIGMAP Decouple configuration from container image Application Language runtimes OS dependencies Environment Variable or Volume/File CONTAINER INSTANCE key:value from directories, files, or values KUBERNETES
 CONFIGMAP APPLICATION CONFIG FILE Application Configuration File e.g. XML etcd Pod Source Code Repository EnvVar require pod restart Files refresh in time

Slide 34

Slide 34 text

• Treat build file as a Blueprint • Don’t login to build/configure • Version control build file • Be explicit with versions, not latest • Always list registry pulling FROM • Each Run creates a new layer • Specify USER, default is root • Sign and validate images BUILD FILE BEST PRACTICES FROM registry.redhat.com/rhel7 RUN groupadd -g 999 appuser && \ useradd -r -u 999 -g appuser appuser USER appuser CMD echo “Hello” Build file

Slide 35

Slide 35 text

CONTINUOUS BUILDS

Slide 36

Slide 36 text

CI/CD PIPELINE WITH KUBERNETES BARE METAL VIRTUAL PRIVATE CLOUD PUBLIC CLOUD CI/CD PIPELINE WITH KUBERNETES BARE METAL VIRTUAL PRIVATE CLOUD PUBLIC CLOUD Automated Software Factory
 Speed, Resiliency, Scalability, Security 


Slide 37

Slide 37 text

Java Build Environment Language runtimes OS dependencies Build Image Java Code Application Language runtimes OS dependencies Container Image Image Registry Source Repository Image Registry REPRODUCIBLE BUILDS Source to Image with Build Images Source v3.1 v1.0.1 v3.1 Java Build Environment Language runtimes OS dependencies Build Image Java Code Application Language runtimes OS dependencies Container Image Image Registry Source Repository Image Registry REPRODUCIBLE BUILDS Source to Image with Build Images Source v3.1 v1.0.1 v3.1 + REPRODUCIBLE BUILDS with build images

Slide 38

Slide 38 text

CUSTOM SUPPLY CHAIN CASCADING REBUILDS

Slide 39

Slide 39 text

CONTAINER REGISTRY & SCANNING

Slide 40

Slide 40 text

WHAT’S INSIDE MATTERS…

Slide 41

Slide 41 text

PRIVATE REGISTRY PRIVATE REGISTRY Trusted Content

Slide 42

Slide 42 text

Security CONTINUOUS INTEGRATION WITH SECURITY SCAN

Slide 43

Slide 43 text

AUTOMATED SECURITY SCANNING with OpenSCAP Reports & Remediation Scan SCAP Security Guide for RHEL CCE-27002-5 Set Password Minimum Length Content Scan physical servers, virtual machines, docker images and containers
 for Security Policy Compliance (CCEs) and known Security Vulnerabilities (CVEs)

Slide 44

Slide 44 text

CI/CD

Slide 45

Slide 45 text

CONTINUOUS DELIVERY WITH CONTAINERS CI/CD PIPELINE

Slide 46

Slide 46 text

CI/CD DEPLOYMENT STRATEGIES
 Automate and reduce deployment risk Each container/pod is updated one by one Version 1.2 50% Version 1 V1 V1.2 Rolling Update Recreate Version 1 Version 1 Version 1 Version 1.2 ` Tests / CI RECREATE WITH DOWNTIME BLUE GREEN Version 1 Version 2 Ingress e.g haproxy BLUE / GREEN DEPLOYMENT Using Ingress 100% Blue / Green 25% Conversion Rate 30% Conversion Rate 75% 25% Version B Version A Ingress CANARY DEPLOYMENTS A/B testing with Canaries

Slide 47

Slide 47 text

A/B TESTING WITH CANARIES

Slide 48

Slide 48 text

”only about 1/3 of ideas improve the metrics 
 they were designed to improve.”
 Ronny Kohavi, Microsoft (Amazon) MICROSERVICES RAPID INNNOVATION & EXPERIMENTATION

Slide 49

Slide 49 text

A/B TESTING USING CANARY DEPLOYMENTS

Slide 50

Slide 50 text

25% Conversion Rate ?! Conversion Rate 100% Version B Version A Ingress CANARY DEPLOYMENTS Tests / CI CANARY DEPLOYMENTS
 Build confidence in new version Service
 selector:
 app=demo version=A label:
 app=demo
 version=A 25% Conversion Rate ??% Conversion Rate

Slide 51

Slide 51 text

25% Conversion Rate 30% Conversion Rate 75% 25% Version B Version A Ingress CANARY DEPLOYMENTS CANARY DEPLOYMENTS
 Requires app to support side-by-side version Deploy new version and wait until it’s ready… Health Check: readiness probe e.g. tcp, http, script Version 1 Version 1 Version 
 1.2 Version 1 Rollingupdate
 maxUnavailable=0 maxSurge=1 Service Service
 selector:
 app=demo label:
 app=demo
 version=A 25% Conversion Rate ??% Conversion Rate label:
 app=demo
 version=B

Slide 52

Slide 52 text

CANARY DEPLOYMENTS
 Requires app to support side-by-side version Service label:
 app=demo
 version=A 25% Conversion Rate 30% Conversion Rate label:
 app=demo
 version=B 25% Conversion Rate 30% Conversion Rate 75% 25% Version B Version A Ingress CANARY DEPLOYMENTS Service
 selector:
 app=demo

Slide 53

Slide 53 text

25% Conversion Rate 30% Conversion Rate 100% Version B Version A Ingress CANARY DEPLOYMENTS Service
 selector:
 app=demo version=B label:
 app=demo
 version=A 25% Conversion Rate 30% Conversion Rate label:
 app=demo
 version=B

Slide 54

Slide 54 text

EXTERNAL SERVICES

Slide 55

Slide 55 text

EXTERNAL SERVICES Database outside cluster with IP address External Mongo Database Service External Mongo Database Service Development Production IP=10.200.0.2 port=27017 IP=10.100.0.9 port=27017

Slide 56

Slide 56 text

EXTERNAL SERVICES Database outside cluster with IP address Pods Nodes Services WebApp role=webapp replicas=2, 
 role=webapp External Mongo Database Service IP=10.200.0.2 port=27017 Network External Mongo Database Service IP=10.100.0.9 port=27017

Slide 57

Slide 57 text

EXTERNAL SERVICES Database outside cluster with IP address Pods Nodes Services WebApp role=webapp replicas=2, 
 role=webapp External Mongo Database Service IP=10.200.0.2 port=27017 Network External Mongo Database Service IP=10.100.0.9 port=27017 Database name=mongo port=27017 targetport=27017 Endpoint IP=10.200.0.2 port=27017 Database kind=Service type=ClusterIP name=mongo port=27017 targetport=27017

Slide 58

Slide 58 text

EXTERNAL SERVICES Database outside cluster with IP address Pods Nodes Services WebApp role=webapp replicas=2, 
 role=webapp External Mongo Database Service IP=10.200.0.2 port=27017 Network External Mongo Database Service IP=10.100.0.9 port=27017 Database name=mongo port=27017 targetport=27017 Endpoint IP=10.200.0.2 port=27017 Connect with mongodb://mongo Database kind=Service type=ClusterIP name=mongo port=27017 targetport=27017 kind=Endpoints name=mongo ip=10.200.0.2 port=27017

Slide 59

Slide 59 text

EXTERNAL SERVICES Database outside cluster with IP address Pods Nodes Services WebApp role=webapp replicas=2, 
 role=webapp External Mongo Database Service IP=10.200.0.2 port=27017 Network External Mongo Database Service IP=10.100.0.9 port=27017 Database name=mongo port=27017 targetport=27017 Endpoint IP=10.100.0.9 port=27017 kind=Service type=ClusterIP name=mongo port=27017 targetport=27017 kind=Endpoints name=mongo ip=10.200.0.9 port=27017 Connect with mongodb://mongo Database

Slide 60

Slide 60 text

Pods Nodes Services Database name: mongo type: ExternalName externalName: mongo52101.domain,.name EXTERNAL SERVICES Using CNAME redirection mongodb://
 :
 
 @mongo:/dev 
 mongodb://:
 @mongo52101.domain.name:52101/dev Cloud Mongo Database Service WebApp role=webapp replicas=2, 
 role=webapp .name EXTERNAL SERVICE Remotely hosted database with URI

Slide 61

Slide 61 text

DATABASE MIGRATIONS

Slide 62

Slide 62 text

Application v3 Development Application V2 Test Application v1 Production DB v1 DB v2 DB v3 CI/CD PIPELINE Version control database updates, ex: flyway V3__add_table_scooter.sql V2__add_table_truck.sql V1__add_table_car.sql

Slide 63

Slide 63 text

DATABASE MIGRATIONS Version control database updates with Containers CONTAINER IMAGE CONTAINER BUILD FILE SQL MIGRATION SCRIPT Source Code Repository V2__add_table.sql Source Code Repository V2__add_table.sql /var/flyway/data Flyway flyway-mydb:v2.0.0 Registry + Dockerfile

Slide 64

Slide 64 text

Nodes Pods Services postgresql-0 Persistent Volume A B D C PostgreSQL StatefulSet replicas=1 role=postgresq pvcl DATABASE MIGRATION StatefulSet deployment with headless Service v1

Slide 65

Slide 65 text

Nodes Pods Services postgresql-0 Persistent Volume A B D C PostgreSQL StatefulSet replicas=1 role=postgresql Pvc DATABASE MIGRATIONS Create a Job for Flyway Flyway Job Secrets = Database Connection Info v1 flyway-mydb:v2.0.0 Image Registry Flyway

Slide 66

Slide 66 text

role=postgressql type=primary Nodes Pods Services postgresql-0 Persistent Volume A B D C PostgreSQL StatefulSet replicas=1 role=postgresql pvc DATABASE MIGRATIONS Apply schema changes to database Flyway Job Secrets = Database Connection Info V2 flyway-mydb:v2.0.0 Flyway

Slide 67

Slide 67 text

role=postgresql type=primary Nodes Pods Services postgresql-0 Persistent Volume A B D C PostgreSQL StatefulSet replicas=1 role=postgresql Pvc DATABASE MIGRATIONS Version control for database with Kubernetes V2

Slide 68

Slide 68 text

CONTINUOUS FEEDBACK

Slide 69

Slide 69 text

MONITORING CONSIDERATIONS Kubernetes* Container* Host Cluster services, services, pods, 
 deployments metrics Container native metrics Traditional resource metrics - cpu, memory, network, storage prometheus + grafana kubernetes-state-metrics probes Stack Metrics Tool node-exporter Kubernetes metrics server: kubelet:cAdvisor Microservices Distributed applications - traditional app metrics - service discovery - distributed tracing prometheus + grafana jaeger tracing istio

Slide 70

Slide 70 text

KUBERNETES ARCHITECTURE

Slide 71

Slide 71 text

KUBERNETES ARCHITECTURE Authorization API Server Controller node, replication, endpoints, token, service account Scheduler etcd etcd etcd Kubernetes Master API UI CLI Node 3 Node 1 Node 2 Node 4 Cluster User TLS - encrypted traffic: users>api>kubelet>pods Pod Pod Pod kubelet kube- proxy container runtime Node

Slide 72

Slide 72 text

KUBERNETES ARCHITECTURE Authorization API Server Controller Scheduler etcd etcd etcd Kubernetes Master API UI CLI Node 3 Node 1 Node 2 Node 4 Cluster User Network, DNS Linux, Container Runtime Management, Monitoring, Logs, Security, Registry Storage Pod Pod Pod kubelet kube- proxy container runtime Node

Slide 73

Slide 73 text

NETWORKING

Slide 74

Slide 74 text

Kubernetes 
 Logical Network Model NETWORK SECURITY • Kubernetes uses a flat SDN model • All pods get IP from same CIDR • And live on same logical network • Assumes all nodes communicate
 Traditional 
 Physical Network Model • Each layer represents a Zone with
 increased trust - DMZ > App > DB,
 interzone flow generally one direction • Intrazone traffic generally unrestricted

Slide 75

Slide 75 text

NETWORK SECURITY MODELS Co-Existence Approaches One Cluster Multiple Zones Kubernete Cluster Physical Compute 
 isolation based on 
 Network Zones Kubernete Cluster One Cluster Per Zone Kubernete Cluster B Kubernete Cluster A Kubernetes Cluster B C D https://blog.openshift.com/openshift-and-network-security-zones-coexistence-approaches/

Slide 76

Slide 76 text

Network Namespace 
 provides resource isolation NETWORK ISOLATION Multi-Environment Multi-Tenant

Slide 77

Slide 77 text

NETWORK POLICY example: 
 all pods in namespace ‘project-a’ allow traffic 
 from any other pods in the same namespace.”

Slide 78

Slide 78 text

NODES & PODS

Slide 79

Slide 79 text

Chris Van Tuin Chief Technologist, NA West / Silicon Valley cvantuin@redhat.co Be • Don’t ru • If you m limit Lin • Limit SS • Use nam • Define r • Enable • Apply S • Apply S and se • Run pro unprivile http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html Kernel Hardware (Intel, AMD) or Virtual Machine Containers Containers Containers Unit File Docker Image Container CLI SYSTEMD Cgroups Namespaces SELinux Drivers seccomp Read Only mounts Capabilities CONTAINER HOST SECURITY CONTAINERS ARE LINUX

Slide 80

Slide 80 text

KUBERNETES: POD SECURITY POLICIES Cluster level, Implemented as an Admission Controller apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: privileged annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' spec: privileged: true allowPrivilegeEscalation: true allowedCapabilities: - '*' volumes: - '*' hostNetwork: true hostPorts: - min: 0 max: 65535 hostIPC: true hostPID: true runAsUser: rule: 'RunAsAny' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'RunAsAny' apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted annotations: seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false # Required to prevent escalations to root. allowPrivilegeEscalation: false # This is redundant with non-root + disallow privilege escalation, # but we can provide it for defense in depth. requiredDropCapabilities: - ALL # Allow core volume types. volumes: - 'configMap' - 'secret'' # Assume that persistentVolumes set up by the cluster admin are safe to use. - 'persistentVolumeClaim' hostNetwork: false hostPID: false ...... Open Restrictive

Slide 81

Slide 81 text

CONTROLLING ACCESS TO KUBERNETES API Authorization User BLUE GREEN Version 1 Version 2 Ingress e.g haproxy BLUE / GREEN DEPLOYMENT Using Ingress 100% Pod (Service Account) etcd 1 Kubernetes API Server Authentication Authorization RBAC: role (pods: get, watch, list) & rolebinding (john, default) Admission Controller (mutate /validate) ex: AlwaysPullImage, PodSecurityPolicy 2 3 4 5

Slide 82

Slide 82 text

KUBERNETES NODE Network, DNS kube- proxy kubelet Kubernetes Master Linux, Container Runtime Management, Monitoring, Logs, Security, Registry Storage Chris Van Tuin Chief Technologist, NA West / Silicon Valley cvantuin@redhat.co Best Practices • Don’t run as root • If you must, 
 limit Linux Capabilities • Limit SSH Access • Use namespaces • Define resource quotas • Enable logging • Apply Security Errata • Apply Security Context and seccomp filters • Run production 
 unprivileged containers 
 as read-only http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html Kernel Hardware (Intel, AMD) or Virtual Machine Containers Containers Containers Unit File Docker Image Container CLI SYSTEMD Cgroups Namespaces SELinux Drivers seccomp Read Only mounts Capabilities CONTAINER HOST SECURITY

Slide 83

Slide 83 text

WHAT’S NEXT?

Slide 84

Slide 84 text

KUBERNETES NATIVE ADD-ONS kubevirt github.com/kubevirt operators coreos.com/operators knative github.com/knative istio istio.io Virtual Machines Day 2 Operations Server-
 less Service Mesh CI/CD tekton tekton.dev

Slide 85

Slide 85 text

SERVICE MESH

Slide 86

Slide 86 text

Traffic Control Service Resiliency Chaos Testing Observ- ability Security SERVICE MESH WITH ISTIO Dedicated infrastructure layer for making service-to-service communication 
 safe, fast, and reliable Deploy as a lightweight side-car network proxy

Slide 87

Slide 87 text

CONFIDENTIAL - FOR INTERNAL USE ONLY MICROSERVICES WITHOUT ISTIO Container JVM service A discovery load-balancer resiliency metrics tracing app logic JVM service B discovery load-balancer resiliency metrics tracing app logic Container JVM service C discovery load-balancer resiliency metrics tracing app logic

Slide 88

Slide 88 text

CONFIDENTIAL - FOR INTERNAL USE ONLY MICROSERVICES WITH ISTIO Container JVM service C app logic Pod Sidecar Container Envoy Container JVM service A app logic Pod Sidecar Container Envoy Container JVM service B app logic Pod Sidecar Container Envoy

Slide 89

Slide 89 text

ISTIO SERVICE MESH Envoy istio-ingress Envoy App A Envoy App B Envoy App C istio-pilot istio-mixer istio-auth HTTP Req/Resp Kubernetes Pods Istio Components Config to Envoy Access Control and Telemetry

Slide 90

Slide 90 text

24% 76% v1 v2 apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: recommendation-v1-v2 spec: destination: namespace: tutorial name: recommendation precedence: 5 route: - labels: version: v1 weight: 76 - labels: version: v2 weight: 24 CANARY RELEASE BY WEIGHT RouteRule #2: 
 Route 94% to v1 and 6% to v2

Slide 91

Slide 91 text

“.*Safari.*” Default v1 v2 apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: recommendation-safari spec: destination: namespace: tutorial name: recommendation precedence: 2 match: request: headers: user-agent: regex: ".*Safari.*" route: - labels: version: v2 ROUTING BY HEADER By Geography, Mobile Device, Browser, Customer, … RouteRule #3: 
 Route “Safari” to v2

Slide 92

Slide 92 text

v1 v2 apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: recommendation-mirror spec: destination: namespace: tutorial name: recommendation precedence: 2 route: - labels: version: v1 weight: 100 - labels: version: v2 weight: 0 mirror: namespace: tutorial name: recommendation labels: version: v2 DARK LAUNCH Mirror production traffic for pre-release testing RouteRule #3: 
 Route “Safari” to v2 Mirror Production Traffic To v2 100% 100% Test Production

Slide 93

Slide 93 text

apiVersion: config.istio.io/v1alpha2 kind: EgressRule metadata: name: httpbin-egress-rule spec: destination: service: httpbin.org ports: - port: 80 protocol: http SECURE BY DEFAULT Egress blocks all traffic unless unless whitelisted with EgressRule EgressRule: Allow httpbin.org:80 
 (http) role=web Pods Nodes http://httpbin.org Istio EgressRule

Slide 94

Slide 94 text

Deployment Frequency Lead Time Deployment
 Failure Rate Mean Time to Recover 99.999 Service Availability DEVSECOPS METRICS Compliance Score

Slide 95

Slide 95 text

THANK YOU linkedin: Chris Van Tuin email: cvantuin@redhat.com twitter: @chrisvantuin