Istio is a massive project with a wide range of capabilities and deployment options. We will learn about the Istio’s authorization policy with an example .
Before we directly jump into Istio's Authorization policies let's have a glance at Istio's Security architecture. The below diagram is directly referenced from Istio documentation. From the control plane, users can create things like authorization policies authentication policies, and policies will get translated into envoy config and streamed bent the varied proxies that form up the service mesh, on the information plane side there is east-west traffic from service b to c and also the actual communication takes place through sidecar proxies. If the traffic is entering it moves to the Ingress gateway and if it’s leaving it can attend the Egress gateway in between all this we will apply JWT enforcements.
In this example, we allow access to our service httpbin in namespace foo from any JWT (regardless of the principle) to use the GET method.
1apiVersion: "security.istio.io/v1beta1"2kind: "AuthorizationPolicy"3metadata:4 name: "allow-reads"5 namespace: foo6spec:7 selector:8 matchLabels:9 app: httpbin10 rules:11 - from:12 - source:13 principals: ["*"]14 to:15 - operation:16 methods: ["GET"]
There is some logic behind how authorization is set given defined AuthorizationPolicies. Below is that the flow as taken directly from the Istio documentation.
MeshMap is the world's only visual designer for Kubernetes and service mesh deployments. Have your cloud native deployments automatically diagrammed. Deployments configured and modeled in Designer mode, can be deployed into your environment and managed using Visualizer. Discover a catalog of best practice cloud native patterns.