Come for the traffic management, stay for the security
•Download as PPTX, PDF•
3 likes•728 views
Service mesh implementations help move critical application networking functionality out of the applications and into the infrastructure. With a service mesh like Istio, for example, you can move complicated traffic routing, resiliency aspects, and top-line metric collection out of the application code. This helps you build complicated distributed systems a bit more safely. But can Istio help with solving security issues? Christian Posta explores some of the ways Istio helps you build more secure systems with mutual TLS, OAuth 2.0, and JSON Web Token verification. Security starts with defining trust boundaries and establishing identities. Istio helps do this by leveraging SPIFEE to assign identity and lay the foundation for zero-trust application networking. Istio then leverages this identity to take over the issuance and management of workload identity documents (e.g., x509 certificates), which can then be used to provide client authentication and mTLS. Istio also helps with OAuth flows, JWT verification, RBAC/ABAC, and much more. You may be drawn into using Istio for its traffic management functionality, but most customers Christian works with find themselves much more interested in the security aspects once they learn what they can do with it. Join in to see for yourself.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Come for the traffic management, stay for the security
Similar to Come for the traffic management, stay for the security (20)
More from Christian Posta
More from Christian Posta (13)
Recently uploaded
Recently uploaded (20)
Come for the traffic management, stay for the security
- 1. COME FOR THE TRAFFIC ROUTING, STAY FOR THE SECURITY Christian Posta @christianposta Chief Architect, Red Hat
- 2. Christian Posta Chief Architect, cloud-native appdev Twitter: @christianposta Blog: http://blog.christianposta.com Email: christian@redhat.com Slides: http://slideshare.net/ceposta • Author “Microservices for Java developers” • Committer/contributor lots of open-source projects • Worked with large Microservices, web-scale, unicorn company • Blogger, speaker
- 4. New challenges in a cloudy, services world • Service discovery • Retries • Timeouts • Load balancing • Rate limiting • Thread bulk heading • Circuit breaking
- 5. …continued • Routing between services (adaptive, zone-aware) • Deadlines • Back pressure • Outlier detection • Health checking • Traffic shaping • Request shadowing
- 6. …continued • Edge/DMZ routing • Surgical / fine / per-request routing • A/B rollout • Internal releases / dark launches • Fault injection • Stats, metric, collection • Logging • Tracing
- 7. A service mesh is decentralized application- networking infrastructure between your services that provides resiliency, security, observability, and routing control. A service mesh allows your applications to function without having to know intimate details of underlying infrastructure, topology, and provider specifics. Time for definitions:
- 8. Meet Istio.io http://istio.io An open-source implementation of service mesh
- 11. Fine-grained traffic routing • Safely test new deployments in production with traffic mirroring and diff/compare tools • Controlled release strategy (decouple deployment and release) • Canary releases • Graduated releases • Build A/B testing on top
- 12. Fine-grained traffic routing • Low-risk monolith to microservices Part I/II/III • Traffic shadowing with Istio: reduce the risk of code release • Advanced traffic-shadowing patterns with Istio • http://blog.christianposta.com
- 13. So we asked some of our customers what features of Istio would be most desired/prioritized
- 15. Policy (server) and Destination Rule (client)
- 16. Policy (server) and Destination Rule (client)
- 17. Istio mutual TLS
- 18. Istio mutual TLS
- 19. Istio Mutual TLS What policy governs a service How do client’s call a service
- 20. Istio end-user identity verification
- 22. We are just scratching the surface!
- 23. Follow up links • http://istio.io • https://preliminary.istio.io • https://preliminary.istio.io/docs/concepts/security/ • https://preliminary.istio.io/docs/tasks/security/ • https://kiali.org • http://blog.christianposta.com
- 24. DEMO TIME!
Editor's Notes
- This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesn’t have this context. We have to make it explicit. And any context needs to have explicit boundaries. This model needs to be “useful” ie, it should be able to be implemented. Try to establish a model that’s both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose. Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesn’t bleed or force others to bleed definitions and semantics. Bounded context: within this space, this is the context of the language. This is what it means and it’s not ambiguous. Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries. Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries. Bounded contexts tend to be “self contained systems” themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.