Configure authorization policy advanced features

Cloud Service Mesh authorization policy provides mesh-, namespace-, andworkload-level access control for your workloads in the mesh. This pagedescribes details about configuring Cloud Service Mesh authorization policy advancedfeatures, includingdry-run mode anddenial logging. The features describedon this page assume that you are familiar with the fundamental authorizationpolicy concepts described inAuthorization policy overview.

Dry-run mode

The Cloud Service Mesh authorization policy supports dry-run mode, which lets you totest an authorization policy with real production traffic without enforcing it.The dry-run mode allows you to better understand the effect of an authorizationpolicy before enforcing it. This helps to reduce the risk of breaking theproduction traffic caused by an incorrect authorization policy.

You use the"istio.io/dry-run": "true" annotation in the authorization policyto change it to dry-run mode.

Dry-run mode example

The following example,deny-path-headers, showsa policy with thedry-run annotation set to"true. The authorization policydenies requests to the pathheaders and allows all other requests.

apiVersion:security.istio.io/v1beta1kind:AuthorizationPolicymetadata:name:deny-path-headersannotations:"istio.io/dry-run":"true"spec:selector:matchLabels:app:httpbinaction:DENYrules:-to:-operation:paths:["/headers"]

When you apply an authorization policy in dry-run mode, Cloud Service Mesh logs theenforcement result toCloud Logging but doesn'tenforce the policy. The request is always allowed, and you can checkLogs Explorer to decide whether or not the authorization policy is workingas expected.

Dry-run logging details

After applying an authorization policy in dry-run mode, you can see theresults of the policy in Logs Explorer.

1. Go to Logs Explorer. In the following URL, replacePROJECT_ID with your project ID:

   https://console.cloud.google.com/logs/query?project=PROJECT_ID

2. In theQuery-builder field, enter a query to find the dry-run modeauthorization policy. In the following query, replaceNAMESPACE with your namespace:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"labels.destination_namespace="NAMESPACE"labels.dry_run_result="AuthzDenied"

3. ClickRun query.

4. Adjust the time range as needed.

The following screenshot shows the dry-run labels in the traffic log inLogs Explorer after the exampledeny-path-headers policy was applied:

The dry-run mode supportsALLOW andDENY authorization policies, in additionto theIstio dry-run results.Cloud Service Mesh stores the dry-run results to Cloud Logging in the followinglabels:

• dry_run_result: The dry-run result is either "AuthzAllowed" or"AuthzDenied".
• dry_run_policy_name: The namespace and name of the matched authorizationpolicy making the dry-run decision.
• dry_run_policy_rule: The index of the matched authorization policy rulemaking the dry-run decision.

The following table shows the details that are logged for an authorizationpolicy in dry-run mode:

When you are confident about the dry-run result, you can disable dry-run modeusing one of the following approaches:

• Remove the dry-run annotation completely; or

• Change the value of the dry-run annotation tofalse.

After you apply the policy with dry-run mode disabled, Cloud Service Mesh enforcesthe policy.

Denial logging

The authorization policy denies a request if it is not allowed by the policy.For HTTP (including gRPC) protocols, the request is denied with status code403. For non-HTTP protocols, the connection is terminated directly. TheCloud Logging traffic log includes additional information which is useful tounderstand why traffic is being denied. For example, the log indicates how manyrequests are denied by the authorization policy, which can help you determinewhich policy rule caused the denial versus denials from the backendapplication.

In the following example, thedry-run annotation is set to"false. When youapply theDENY authorization policy, Cloud Service Mesh enforces it.

apiVersion:security.istio.io/v1beta1kind:AuthorizationPolicymetadata:name:deny-path-headersannotations:"istio.io/dry-run":"false"spec:selector:matchLabels:app:httpbinaction:DENYrules:-to:-operation:paths:["/headers"]

After applying aDENY authorization policy, you can see the results of thepolicy in Logs Explorer.

1. Go to Logs Explorer. In the following URL, replacePROJECT_ID with your project ID:

   https://console.cloud.google.com/logs/query?project=PROJECT_ID

2. In theQuery-builder field, enter a query to find theDENYauthorization policy. In the following query, replaceNAMESPACE with your namespace:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"labels.destination_namespace="NAMESPACE"labels.response_details="AuthzDenied"

3. ClickRun query.

4. Adjust the time range as needed.

The following screenshot shows a log entry in Logs Explorer after theexampledeny-path-headers policy was applied to enforce the policy. You cantell that the authorization policy was responsible for the 403 by lookingat the labels:

The Logs Explorer traffic log includes the following labels for theauthorization denial:

• response_details: Is set to "AuthzDenied" if the denial is causedby an authorization policy.
• policy_name: Contains the namespace and name of the authorizationDENY policy causing the denial. The value is in the format of<Namespace>.<Name>, for example,foo.deny-path-headers means theauthorization policydeny-path-headers in thefoo namespace.
• policy_rule: Contains the index of the rule inside theauthorization policy causing the denial, for example, 0 means the first ruleinside the policy.

What's next?

For a list of all the authorization policies in the service mesh:

kubectl get authorizationpolicy --all-namespaces

If there is an authorization policy in force, you can delete it withkubectl delete:

kubectl delete authorizationpolicy -nNAMESPACEAUTH_POLICY_NAME

For more information about how to get the traffic log, seeAccess logs.