Cloud Service Mesh authorization policy provides mesh-, namespace-, and workload-level access control for your workloads in the mesh. This page describes details about configuring Cloud Service Mesh authorization policy advanced features, including dry-run mode and denial logging. The features described on this page assume that you are familiar with the fundamental authorization policy concepts described in Authorization policy overview.
Dry-run mode
The Cloud Service Mesh authorization policy supports dry-run mode, which lets you to test an authorization policy with real production traffic without enforcing it. The dry-run mode allows you to better understand the effect of an authorization policy before enforcing it. This helps to reduce the risk of breaking the production traffic caused by an incorrect authorization policy.
You use the "istio.io/dry-run": "true"
annotation in the authorization policy
to change it to dry-run mode.
Dry-run mode example
The following example, deny-path-headers
, shows
a policy with the dry-run
annotation set to "true
. The authorization policy
denies requests to the path headers
and allows all other requests.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-path-headers
annotations:
"istio.io/dry-run": "true"
spec:
selector:
matchLabels:
app: httpbin
action: DENY
rules:
- to:
- operation:
paths: ["/headers"]
When you apply an authorization policy in dry-run mode, Cloud Service Mesh logs the enforcement result to Cloud Logging but doesn't enforce the policy. The request is always allowed, and you can check Logs Explorer to decide whether or not the authorization policy is working as expected.
Dry-run logging details
After applying an authorization policy in dry-run mode, you can see the results of the policy in Logs Explorer.
Go to Logs Explorer. In the following URL, replace
PROJECT_ID
with your project ID:https://console.cloud.google.com/logs/query?project=PROJECT_ID
In the Query-builder field, enter a query to find the dry-run mode authorization policy. In the following query, replace
NAMESPACE
with your namespace:logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
Click Run query.
Adjust the time range as needed.
The following screenshot shows the dry-run labels in the traffic log in
Logs Explorer after the example deny-path-headers
policy was applied:
The dry-run mode supports ALLOW
and DENY
authorization policies, in addition
to the
Istio dry-run results.
Cloud Service Mesh stores the dry-run results to Cloud Logging in the following
labels:
- dry_run_result: The dry-run result is either "AuthzAllowed" or "AuthzDenied".
- dry_run_policy_name: The namespace and name of the matched authorization policy making the dry-run decision.
- dry_run_policy_rule: The index of the matched authorization policy rule making the dry-run decision.
The following table shows the details that are logged for an authorization policy in dry-run mode:
Authorization policy applied in dry-run mode | Match result | Dry-run result | Cloud Logging |
---|---|---|---|
Only DENY policy |
Not Matched | allowed | dry_run_result: "AuthzAllowed" |
Matched | rejected | dry_run_result: "AuthzDenied" dry_run_policy_name: dry_run_policy_rule: |
|
Only ALLOW policy |
Not Matched | rejected | dry_run_result: "AuthzDenied" |
Matched | allowed | dry_run_result: "AuthzAllowed" dry_run_policy_name: dry_run_policy_rule: |
|
Both ALLOW and DENY policy |
Neither Matched | rejected | dry_run_result: "AuthzDenied" |
Only Matched DENY policy |
rejected | dry_run_result: "AuthzDenied" dry_run_policy_name: dry_run_policy_rule: |
|
Only Matched ALLOW policy |
allowed | dry_run_result: "AuthzAllowed" dry_run_policy_name: dry_run_policy_rule: |
|
Matched both policy | rejected | dry_run_result: "AuthzDenied" dry_run_policy_name: dry_run_policy_rule: |
When you are confident about the dry-run result, you can disable dry-run mode using one of the following approaches:
Remove the dry-run annotation completely; or
Change the value of the dry-run annotation to
false
.
After you apply the policy with dry-run mode disabled, Cloud Service Mesh enforces the 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 code 403. For non-HTTP protocols, the connection is terminated directly. The Cloud Logging traffic log includes additional information which is useful to understand why traffic is being denied. For example, the log indicates how many requests are denied by the authorization policy, which can help you determine which policy rule caused the denial versus denials from the backend application.
In the following example, the dry-run
annotation is set to "false
. When you
apply the DENY
authorization policy, Cloud Service Mesh enforces it.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-path-headers
annotations:
"istio.io/dry-run": "false"
spec:
selector:
matchLabels:
app: httpbin
action: DENY
rules:
- to:
- operation:
paths: ["/headers"]
After applying aDENY
authorization policy, you can see the results of the
policy in Logs Explorer.
Go to Logs Explorer. In the following URL, replace
PROJECT_ID
with your project ID:https://console.cloud.google.com/logs/query?project=PROJECT_ID
In the Query-builder field, enter a query to find the
DENY
authorization 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"
Click Run query.
Adjust the time range as needed.
The following screenshot shows a log entry in Logs Explorer after the
example deny-path-headers
policy was applied to enforce the policy. You can
tell that the authorization policy was responsible for the 403 by looking
at the labels:
The Logs Explorer traffic log includes the following labels for the authorization denial:
- response_details: Is set to "AuthzDenied" if the denial is caused by an authorization policy.
- policy_name: Contains the namespace and name of the authorization
DENY
policy causing the denial. The value is in the format of<Namespace>.<Name>
, for example,foo.deny-path-headers
means the authorization policydeny-path-headers
in thefoo
namespace. - policy_rule: Contains the index of the rule inside the authorization policy causing the denial, for example, 0 means the first rule inside 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 with
kubectl delete
:
kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME
For more information about how to get the traffic log, see Accessing logs in Cloud Logging.