Configuring audit policies for your services

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

This tutorial only supports the in-clustercontrol plane implementation.

An audit policy lets you audit data access to your services inCloud Service Mesh. Auditing your services helps you answer the questions"who did what, when, and possibly why." With an audit policy, you can specifywhen an audit log is created and the content of the logs. This guide explainshow to install Cloud Service Mesh so that you can use an audit policy.

Because you view the audit logs in theCloud Logging Logs Explorer in the Google Cloud console, auditpolicies are supported only on the following platforms:

• GKE on Google Cloud
• Google Distributed Cloud (software only) for VMware
• Google Distributed Cloud (software only) for bare metal

An audit policy extendsAuthorizationPolicyby adding anAUDIT action. It takes effect only in its target policy scope(which can be a workload, a namespace, or the entire mesh). The policies areORed together, that is, a request is logged if any policy says so. If no auditpolicy applies to a given workload, no audit log is generated for that workload.

Here is an example audit policy to audit all WRITE access to the/user/profile/* path inmyapi:

  apiVersion: security.istio.io/v1beta1  kind: AuthorizationPolicy  metadata:    namespace: ns1    name: anyname  spec:    selector:      matchLabels:        app: myapi    action: AUDIT    rules:- to:- operation:          methods: ["POST", "UPDATE", "DELETE"]          paths: ["/user/profile/*"]

Limitations

• There is no audit log on the ingress-gateway.
• The audit content isn't configurable.
• Currently, the Cloud Service Mesh audit logs have the same reliabilityproperty as normal access logs. For example, if a workload Pod is restarted,some audit logs for the workload, if not persisted, can be lost.

Before you begin

• Install required tools
• Downloadasmcli
• Grant cluster admin permissions
• Validate your project and cluster

Prepare gateway configuration

Cloud Service Mesh gives you the option to deploy and manage gateways as part of yourservice mesh. A gateway describes a load balancer operating at the edge of themesh receiving incoming or outgoing HTTP/TCP connections. Gateways are Envoyproxies that provide you with fine-grained control over traffic entering andleaving the mesh.

asmcli doesn't install theistio-ingressgateway. We recommend that youdeploy and manage the control plane and gateways separately. For moreinformation, seeInstalling and upgrading gateways.

Customizing the Cloud Service Mesh installation

To use an audit policy, customize the Cloud Service Mesh installation:

Using audit logging

This section uses the Bookinfo sample to demonstrate how to use audit logging.

1. Deploy theBookinfo sample application to thedefault namespace.

2. Get the external IP address of the ingress gateway, andsend requeststo the sample application to generate some traffic.

3. In the Google Cloud console, go to the navigation menumenu andselectLogging >Logs Explorer:
   

   Go to the Logs Explorer

4. Select a Google Cloud project.

5. Because you haven't deployed an audit policy yet, there won't be any auditlogs. Note that the audit log is different from the access log. Toseestackdriver access logs, enter the following query in theQuerybuilder field, and clickRun query:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"

   For more information on using Logs Explorer, seeLogs Explorer overview.

Configuring the audit policy and checking audit logs

This section provides several options for auditing the Bookinfo application.After you deploy the audit policy, you can send some requests and then check theaudit log in the Logs Explorer.

1. Enter the following command to getauthentication credentialsto interact with the cluster. This command also sets the current context forkubectl to the cluster.

   gcloud container clusters get-credentialsCLUSTER_NAME \    --project=PROJECT_ID \    --zone=CLUSTER_LOCATION

   Note: For regional cluster replace--region with--zone.

2. Apply the following audit policy to auditGET requests to the/productpage path:

   kubectl apply -f - << EOFapiVersion: "security.istio.io/v1beta1"kind: "AuthorizationPolicy"metadata:  name: "audit-productpage"  namespace: defaultspec:  action: AUDIT  rules:  - to:    - operation:        methods: ["GET"]        paths: ["/productpage"]EOF

3. Send some requests to Bookinfo.

4. In Logs Explorer, enter the following query in theQuery builder field,and clickRun query:

   logName="projects/PROJECT_ID/logs/server-istio-audit-log"

   The query returns logs similar to the following:

   

5. Apply the following policy to audit requests to thebookinfo-ratingsservice. The audit policies are additive. After applying the followingpolicy, you see audit logs for requests to both ProductPage and Ratings.

   kubectl apply -f - << EOFapiVersion: "security.istio.io/v1beta1"kind: "AuthorizationPolicy"metadata:  name: "audit-ratings"  namespace: defaultspec:  action: AUDIT  rules:  - from:    - source:        principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]    to:    - operation:        methods: ["GET"]EOF

   The new audit policy has to propagate first before it takes effect.

6. Send 10 or more requests to Bookinfo to make sure you hit the ratingsservice, and then check the audit log in Logs Explorer. The audit log lookssimilar to the following:

   

7. Apply the following policy to audit to all services in the defaultnamespace.

   kubectl apply -f - << EOFapiVersion: security.istio.io/v1beta1kind: AuthorizationPolicymetadata:  namespace: default  name: "audit-all"spec:  action: AUDIT  rules:    - {}EOF

8. Send some more requests to Bookinfo, and then check the audit log inLogs Explorer. The audit log now logs all requests:

   

9. If you want to restrict the audit policy back down to ProductPage andRatings, you can delete theaudit-all policy:

   kubectl delete authorizationpolicy audit-all -n default

Troubleshooting

If you don't see any audit logs after enabling an audit policy, here are a fewthings you can check:

1. Make sure there is traffic for the time period specified in Logs Explorer.If you are testing with Bookinfo, you can send requests by running thefollowing command several times:

   curl -s http://EXTERNAL_IP/productpage | grep Bookstore

2. Check if there is anAuthorizationPolicy on the ingress gateway thatblocks requests to the audited service.

3. Check thestackdriver access logs with the following filter in the LogsExplorer to verify if your requests have reached the application:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"

   

4. To make sure Stackdriver is configured and audit log is enabled,dump the configuration of current theistiod state.In theconfig_dump search forenable_audit_log and your audit policy'sname.

   istioctl dashboard envoyPOD_NAME.NAMESPACE

   

5. To make sure your requests are matched with audit policy rules, you cancheck role-based access control (RBAC) debug logs.Turn on RBAC debug logging with the following command:

   kubectl execPOD_NAME -nNAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'

6. Send some requests, and then check logs for the Pod with thekubectl logs command:

   kubectl logsPOD_NAME -nNAMESPACE -c istio-proxy

What's next

• Learn about security in Cloud Service Mesh