Istio Authorization Policy

Let’s see Istio’s Security Architecture

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.

Istio includes a high-level architecture that involves multiple factors such as:

• Certificate Authority for key and certificate management
• Sidecar and perimeter proxies work as Policy Enforcement Points to secure communication between the clients and servers.
• A set of Envoy proxy extensions is there to manage telemetry and auditing

Istio’s Authorization policies

• Workload-to-workload and end-user-to-workload authorization.
• A Simple API includes one single Authorization Policy, which is easy to use and maintain.
• Flexible semantics: operators can define custom conditions on Istio attributes, and use DENY and permit actions.
• High performance: Istio authorization gets enforced natively on the Envoy.
• High compatibility: supports gRPC, HTTP, HTTPS, and HTTP2 natively, additionaly as well as any plain TCP protocols.

Example Authorization Policy

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.

Copy
1apiVersion: "security.istio.io/v1beta1"
2kind: "AuthorizationPolicy"
3metadata:
4  name: "allow-reads"
5  namespace: foo
6spec:
7  selector:
8    matchLabels:
9      app: httpbin
10  rules:
11  - from:
12    - source:
13        principals: ["*"]
14    to:
15    - operation:
16        methods: ["GET"]

Access Flow with Auth Policies

There is some logic behind how authorization is set given defined AuthorizationPolicies. Below is that the flow as taken directly from the Istio documentation.

• If there are any CUSTOM policies that match the request, evaluate and deny the request if the evaluation result's is deny.
• If there are any DENY policies that match with the request, deny the request.
• If there are not any ALLOW policies for the workload, allow the request.
• If any of the ALLOW policies gets match with the request, allow the request.
• Deny the request.