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.
A Secure and Reliable Document Management System is Essential.docx
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
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:
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
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.