---
title: Authorization Policies
weight: 56
---
:icons: font
:sectlinks:
:linkattrs:

https://istio.io/latest/docs/concepts/security/[Security, window="_blank"] is one of the main pillars of Istio features.

The Istio https://istio.io/latest/docs/concepts/security/#high-level-architecture[Security High Level Architecture] provides a comprehensive solution to design and implement multiple security scenarios.

In this tutorial we will show how Kiali can use telemetry information to create security policies for the workloads deployed in a given namespace.

Istio telemetry aggregates the ServiceAccount information used in the workloads communication. This information can be used to define authorization policies that deny and allow actions on future live traffic communication status.

This step will show how we can define authorization policies for the *travel-agency* namespace in the Travel Demo application, for all existing traffic in a given time period.

Once authorization policies are defined, a new workload will be rejected if it doesn't match the security rules defined.

NOTE: *Step 1:* Undeploy the *loadtester* workload from *travel-portal* namespace

In this example we will use the *loadtester* workload as the "intruder" in our security rules.

If we have followed the previous tutorial steps, we need to undeploy it from the system.

[source,bash]
----
kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travel_loadtester.yaml) -n travel-portal
----

We should validate that telemetry has updated the *travel-portal* namespace and "Security" can be enabled in the Graph Display options.

++++
<a class="image-popup-fit-height" href="/images/tutorial/06-01-travel-portal-graph.png" title="Travel Portal Graph">
    <img src="/images/tutorial/06-01-travel-portal-graph.png" style="display:block;margin: 0 auto;" />
</a>
++++

NOTE: *Step 2:* Create Authorization Policies for current traffic for *travel-agency* namespace

Every workload in the cluster uses a https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/[Service Account, window="_blank"].

*travels.uk*, *viaggi.it* and *voyages.fr* workloads use the default *cluster.local/ns/travel-portal/sa/default* ServiceAccount defined automatically per namespace.

This information is propagated into the Istio Telemetry and Kiali can use it to define a set of AuthorizationPolicy rules using the "Create Traffic Policies" action located in the Overview page.

++++
<a class="image-popup-fit-height" href="/images/tutorial/06-01-create-traffic-policies.png" title="Create Traffic Policies">
    <img src="/images/tutorial/06-01-create-traffic-policies.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
This will generate a main DENY ALL rule to protect the whole namespace, and an individual ALLOW rule per workload identified in the telemetry.

++++
<a class="image-popup-fit-height" href="/images/tutorial/06-01-travel-agency-authorization-policies.png" title="Travel Agency Authorization Policies">
    <img src="/images/tutorial/06-01-travel-agency-authorization-policies.png" style="display:block;margin: 0 auto;" />
</a>
++++

NOTE: *Step 3:* Deploy the *loadtester* portal in the *travel-portal* namespace

If the *loadtester* workload uses a different ServiceAccount then, when it's deployed, it won't comply with the AuthorizationPolicy rules defined in the previous step.

[source,bash]
----
kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travel_loadtester.yaml) -n travel-portal
----

Now, *travels* workload will reject requests made by *loadtester* workload and that situation will be reflected in Graph:

++++
<a class="image-popup-fit-height" href="/images/tutorial/06-01-loadtester-denied.png" title="Loadtester Denied">
    <img src="/images/tutorial/06-01-loadtester-denied.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
This can also be verified in the details page using the Outbound Metrics tab grouped by response code.

++++
<a class="image-popup-fit-height" href="/images/tutorial/06-01-loadtester-denied-metrics.png" title="Loadtester Denied Metrics">
    <img src="/images/tutorial/06-01-loadtester-denied-metrics.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
Inspecting the Logs tab confirms that *loadtester* workload is getting a HTTP 403 Forbidden response from *travels* workloads, as expected.

++++
<a class="image-popup-fit-height" href="/images/tutorial/06-01-loadtester-logs.png" title="Loadtester Logs">
    <img src="/images/tutorial/06-01-loadtester-logs.png" style="display:block;margin: 0 auto;" />
</a>
++++

NOTE: *Step 4:* Update *travels-v1* AuthorizationPolicy to allow *loadtester* ServiceAccount

AuthorizationPolicy resources are defined per workload using matching selectors.

As part of the example, we can show how a ServiceAccount can be added into an existing rule to allow traffic from *loadtester* workload into the *travels-v1* workload only.

++++
<a class="image-popup-fit-height" href="/images/tutorial/06-01-authorizationpolicy-edit.png" title="AuthorizationPolicy Edit">
    <img src="/images/tutorial/06-01-authorizationpolicy-edit.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
As expected, now we can see that *travels-v1* workload accepts requests from all *travel-portal* namespace workloads, but *travels-v2* and *travels-v3* continue rejecting requests from *loadtester* source.
++++
<a class="image-popup-fit-height" href="/images/tutorial/06-01-travels-v1-authorizationpolicy.png" title="Travels v1 AuthorizationPolicy">
    <img src="/images/tutorial/06-01-travels-v1-authorizationpolicy.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
Using "Outbound Metrics" tab from the *loadtester* workload we can group per "Remote version" and "Response code" to get a detailed view of this AuthorizationPolicy change.

++++
<a class="image-popup-fit-height" href="/images/tutorial/06-01-loadtester-authorized-metrics.png" title="Travels v1 AuthorizationPolicy">
    <img src="/images/tutorial/06-01-loadtester-authorized-metrics.png" style="display:block;margin: 0 auto;" />
</a>
++++

NOTE: *Step 5:* Update or delete Istio Configuration

As part of this step you can update the AuthorizationPolicies generated for the *travel-agency* namespace, and experiment with more security rules, or you can delete the generated Istio config for the namespace.
