Stay organized with collections Save and categorize content based on your preferences.

Monitoring application security in Anthos

Google Cloud has powerful security features built in at every level that work separately and together to protect you from security issues, including both platform and application security. However, with defence in depth like this, it's not always easy to choose which features might benefit your particular application, or to assess how your security policies are working at runtime. To help you with this, the Anthos Security dashboard provides an at-a-glance view of your applications' current security features, as well as a more detailed policy audit view to show you where you can modify security configurations or workloads to improve your security posture.

This document gives platform and application operators an overview of Anthos application security monitoring. To find out more about each security feature and its monitoring, follow the links to the feature docs in What's next?

The Anthos Security dashboard currently monitors clusters on Google Cloud, VMware, and bare metal only.

Required roles

To get the permissions that you need to view and audit application security, ask your administrator to grant you the following IAM roles on the project:

  • roles/monitoring.viewer (Monitoring Viewer)
  • roles/logging.viewer (Logs Viewer)
  • roles/serviceusage.serviceUsageViewer (Service Usage Viewer)
  • roles/servicesecurityinsights.securityInsightsViewer (Security Insights Viewer)

For more information about granting roles, see Manage access.

These predefined roles contain the permissions required to view and audit application security. To see the exact permissions that are required, expand the Required permissions section:

Required permissions

The following permissions are required to view and audit application security:

  • resourcemanager.projects.get
  • opsconfigmonitoring.resourceMetadata.list
  • serviceusage.services.list
  • servicesecurityinsights.projectStates.get
  • To view your application security overview:
    • logging.logEntries.list
    • servicesecurityinsights.clusterSecurityInfo.list
  • To audit the current status for all monitored security features:
    • servicesecurityinsights.clusterSecurityInfo.list
    • servicesecurityinsights.securityViews.get
    • servicesecurityinsights.securityInfo.list
    • servicesecurityinsights.workloadPolicies.list
  • To view workload security details:
    • monitoring.timeSeries.list
    • logging.logEntries.list
    • servicesecurityinsights.clusterSecurityInfo.get
    • servicesecurityinsights.workloadSecurityInfo.get
    • servicesecurityinsights.securityViews.get
    • servicesecurityinsights.workloadPolicies.list

You might also be able to get these permissions with custom roles or other predefined roles.

Supported clusters

The following cluster types are supported in the Anthos Security dashboard:

  • GKE clusters on Google Cloud
  • Anthos clusters on VMware
  • Anthos clusters on bare metal

To monitor security across Vmware and bare metal clusters you need to enable application logging and monitoring. Follow the instructions in the Anthos clusters on VMware and Anthos clusters on bare metal documentation to do this.

View your application security overview

To view the Anthos Security dashboard in the Google Cloud console:

By default, the Policy Summary tab is displayed, showing the status of Anthos application security features in your project, including links to find out more and enable features. Features are listed under two headings: Access control and Authentication.

Screenshot of policy summary view

Access control

This section shows the status of selected Anthos authorization features. These are:

  • Binary Authorization, which lets you ensure that only trusted images are deployed on your clusters.
  • Kubernetes network policy, which lets you specify which pods are allowed to communicate with each other and other network endpoints.
  • Anthos Service Mesh service access control, which lets you configure fine-grained access control for your mesh services based on service accounts and request contexts.

For any feature that isn't enabled in your project, you can click to enable (or find out how to enable) the feature.

For features that are enabled, you can see the feature's current status, and click to see more details over your selected Time span, including any actions that have been denied based on your access control policies and other interesting events. For example, in this project three deployments have been blocked on one cluster in the previous hour as a result of Binary Authorization policies:

Screenshot of Binary Authorization security details

Authentication

This section shows the status of Anthos authentication features. Currently this view shows you whether you have created a policy to enforce mutual TLS (mTLS) in each cluster where you're using Anthos Service Mesh. mTLS is a security protocol that ensures that traffic is secure and trusted in both directions between two services.

Note this only shows whether your service mesh has an mTLS policy - to see whether the policy is effectively securing your traffic and if unencrypted traffic is permitted in your mesh at runtime, you need to visit the more detailed Policy audit view, as described in the next section.

Audit application security

The audit view provides a more detailed runtime assessment of your current application security posture, cluster by cluster. To switch to the audit view:

  1. Select the Policy Audit tab.
  2. Select the Cluster and (optionally) the Namespace that you want to monitor from the drop-downs.

As in the summary view, you can see the current status for all monitored security features. For mTLS, you also see if your policies currently allow unencrypted traffic in your service mesh on this cluster. This can happen if you have enabled mTLS anywhere in permissive mode, which lets services receive both mTLS and plaintext traffic. This is useful to prevent unexpected service outages while you are migrating to strict mTLS, but should be updated if you want end-to-end encryption throughout your mesh.

The Workloads list then lets you see how your security features are operating at the workload level. For each workload, you can see:

  • If they have Kubernetes network policies enforced
  • The Anthos Service Mesh service access control policies that apply to the workload
  • The Anthos Service Mesh mTLS policy that applies to the workload - Permissive (the default if you haven't created any explicit policies that apply to the workload), Disable, or Strict

View workload security details

Select individual workloads in the audit view Workloads list to see more details about their security in the workload view. For each workload, you can see the following information:

  • Where applicable, a link to view the specific policy definition for each application security feature that applies to the workload.

Screenshot of link to a network policy

  • General workload details, including name, cluster, and related service.
  • Service requests to and from this workload, including whether any requests were denied by your policies. If a request is denied, you can drill down to view the relevant logs in Cloud Logging, helping you troubleshoot specific denials and find more useful information about the request.

Screenshot of service requests to and from a workload

  • Network policy requests to and from this workload if Dataplane V2 network policy logging is enabled on your cluster. You can find out more about how to view network policy information and understand how it impacts your workload in the next section.
  • The running pods managed by this workload.

View workload connectivity with Dataplane V2

If the cluster containing your workload has Dataplane V2 enabled, the Network policy requests section is displayed as part of the workload view. If network policy logging is configured to log allowed and denied connections, inbound and outbound traffic for your workload is also shown, as in the following example.

Screenshot of network policy requests to and from a workload

The table also provides additional information about the connections logged by Dataplane V2 network policy logging. To see this information for a specific workload:

  1. Click the more actions menu in the table row for the workload you're interested in.
  2. From the menu, select the additional information you'd like to view:
    • Select View in GKE to navigate to the GKE UI for more information about the workload.
    • Select View denial logs to navigate to Cloud Logging filtered to the relevant log entries.
    • Select View network policy connectivity to see a connectivity diagram that shows the observed security posture for each direction of the connection (Egress and Ingress). An example diagram is shown below.

Screenshot of network policy connectivity

Simulate connection between workloads based on deployed network policies

If the cluster containing your workload has Network policy enforcement enabled, the Simulate Network Policy button is displayed at the top of the workload view page. This feature lets you simulate whether the workload being viewed can send or recieve traffic based on a configuration analysis of the currently deployed network policies.

To simulate the connection between your workloads:

  1. Click the Simulate Network Policy button for the workload to test traffic for.
  2. Select the direction of traffic (inbound or outbound) for the workload.
  3. Select the namespace and workload that you want to test traffic to or from.
  4. Click Simulate. A connectivity diagram will appear showing the status of Egress and Ingress for the connection. The diagram shown is similar to the one used when viewing workload connectivity with Dataplane V2.

An example of the form for simulating network policy connection is shown below:

Screenshot of network policy simulation

What's next?