<p>I’m new to Istio. I’m implementing Authorization with JWT. The DENY action is not reflected for a valid JWT token. I’ve added the JWT Payload and Authorization Policy for reference.
I’m using kubernetes version v1.18.3 and Istio 1.6.2. I’m running cluster on minikube.</p>
<p>I applied below rule on ingressgateway first:</p>
<pre><code>apiVersion: &quot;security.istio.io/v1beta1&quot;
kind: &quot;RequestAuthentication&quot;
metadata:
  name: ingress-auth-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: &quot;https://dev-n63ipah2.us.auth0.com/&quot;
    jwksUri: &quot;https://dev-n63ipah2.us.auth0.com/.well-known/jwks.json&quot;
    audiences: 
    - &quot;http://10.97.72.213/&quot;
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: ingress-authz
 namespace: istio-system
spec:
 selector:
   matchLabels:
     istio: ingressgateway
 action: ALLOW
 rules:
  - when:
    - key: request.auth.claims[iss]
      values: [&quot;https://dev-n63ipah2.us.auth0.com/&quot;]
</code></pre>
<p>After that I applied below policy for dex-ms-contact service</p>
<pre><code>JWT Payload:
{
  &quot;iss&quot;: &quot;https://dev-n63ipah2.us.auth0.com/&quot;,
  &quot;sub&quot;: &quot;sEbjHGBcZ16D0jk8wohIp7vPoT0MWTO0@clients&quot;,
  &quot;aud&quot;: &quot;http://10.97.72.213/&quot;,
  &quot;iat&quot;: 1594274641,
  &quot;exp&quot;: 1594361041,
  &quot;azp&quot;: &quot;sEbjHGBcZ16D0jk8wohIp7vPoT0MWTO0&quot;,
  &quot;gty&quot;: &quot;client-credentials&quot;
}
</code></pre>
<pre><code>RequestAuthentication:

apiVersion: &quot;security.istio.io/v1beta1&quot;
kind: &quot;RequestAuthentication&quot;
metadata:
  name: dex-ms-contact-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: dex-ms-contact
  jwtRules:
  - issuer: &quot;https://dev-n63ipah2.us.auth0.com/&quot;
    jwksUri: &quot;https://dev-n63ipah2.us.auth0.com/.well-known/jwks.json&quot;
    audiences: 
    - &quot;http://10.97.72.213/&quot;
---
apiVersion: &quot;security.istio.io/v1beta1&quot;
kind: &quot;AuthorizationPolicy&quot;
metadata:
  name: dex-ms-contact-require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: dex-ms-contact
  action: DENY
  rules:
  - when:
    - key: request.auth.claims[iss]
      values: [&quot;https://dev-n63ipah2.us.auth0.com/&quot;]
</code></pre>
<p>The ingressgateway policy works fine. However when I apply DENY policy on a dex-ms-contact service The DENY policy does not reflect with a valid JWT token. Ideally it should not allow me to access dex-ms-contact service right?</p>
<p>What is the expected behavior?</p>

Sweta Sharma
<p>According to istio <a href="https://istio.io/latest/docs/reference/config/security/authorization-policy/" rel="nofollow noreferrer">documentation</a>:</p>
<blockquote>
<p>Istio Authorization Policy enables access control on workloads in the mesh.</p>
<p>Authorization policy supports both allow and deny policies. When allow and deny policies are used for a workload at the same time, the deny policies are evaluated first. The evaluation is determined by the following rules:</p>
<ol>
<li>If there are any DENY policies that match the request, deny the request.</li>
<li>If there are no ALLOW policies for the workload, allow the request.</li>
<li>If any of the ALLOW policies match the request, allow the request.</li>
<li>Deny the request.</li>
</ol>
</blockquote>
<p>So taking into consideration that deny policies are evaluated first. Your request could have been first denied on workload policy and then allowed on gateway policy which resulted in overriding deny rule completely.</p>
<p>Considering the order of evaluation of policies being more specific what should get allowed in ALLOW policy would probably make Your permissions model possible.</p>
<p>Hope it helps.</p>
<hr />
<p>Edit:</p>
<p>According to istio <a href="https://istio.io/latest/docs/reference/glossary/#workload" rel="nofollow noreferrer">documentation</a>:</p>
<blockquote>
<p>WORKLOAD<a href="https://istio.io/latest/docs/reference/glossary/#workload" rel="nofollow noreferrer"></a></p>
<p>A binary deployed by  <a href="https://istio.io/latest/docs/reference/glossary/#operator" rel="nofollow noreferrer">operators</a>  to deliver some function of a service mesh application. Workloads have names, namespaces, and unique ids. These properties are available in policy and telemetry configuration using the following  <a href="https://istio.io/latest/docs/reference/glossary/#attribute" rel="nofollow noreferrer">attributes</a>:</p>
<ul>
<li><code>source.workload.name</code>,  <code>source.workload.namespace</code>,  <code>source.workload.uid</code></li>
<li><code>destination.workload.name</code>,  <code>destination.workload.namespace</code>,  <code>destination.workload.uid</code></li>
</ul>
<p>In Kubernetes, a workload typically corresponds to a Kubernetes deployment, while a  <a href="https://istio.io/latest/docs/reference/glossary/#workload-instance" rel="nofollow noreferrer">workload instance</a>  corresponds to an individual  <a href="https://istio.io/latest/docs/reference/glossary/#pod" rel="nofollow noreferrer">pod</a>  managed by the deployment.</p>
</blockquote>
<p>Sorry for late answer, I have been away for some time.</p>
