Breaking Bad Policies: Crafting Perfect Istio Authorization Policies and Ingress Authentication with Otterize
Learn Istio fundamentals for authorization policies and request authentication, and how Otterize automates application security and zero-trust.
In this article, we're going to learn about Istio AuthorizationPolicies. If you're new to Kubernetes but already somewhat familiar with NetworkPolicy resources, you'll feel right at home. Perhaps not necessarily in your own home, but maybe as comfortable as you can be in a neighbor’s home! However, don't be too intimidated by acronyms like mTLS, JWT, OAuth2, or JWKS. You'll need to understand what they mean sooner rather than later, but the dual purpose of this article is to introduce you to the basics of Istio authorization policies and how they function, as well as to propose an innovative approach using Otterize Intent-Based Access Control (IBAC) and client intents to configure them. In the context of Istio, Otterize can suggest and generate client intents by directly pulling connection metrics from Envoy proxies. What more could we do? Yes, I know! I’ll walk you through that in the second part of the article.
The Kubernetes networking model requires that pods can directly communicate with each other using their actual IP addresses. In other words, Kubernetes acts as an open bar once traffic enters the cluster, whether it’s directly routed via IP or encapsulated in the physical network. For security aficionados, that effectively means that Kubernetes is not secured by default and this is NOT the way, dear padawan! Luckily, Istio is coming to help, but the learning curve may be intimidating. Let’s break down the most common pitfalls and navigate through concrete use cases and explore how we can automate policies and leverage Envoy information for better visibility.
