Discovery: Can get sensitive Kubernetes object check

This document describes a threat finding type in Security Command Center. Threat findings are generated by threat detectors when they detect a potential threat in your cloud resources. For a full list of available threat findings, see Threat findings index.

Finding description

A potentially malicious actor attempted to determine what sensitive objects in GKE they can query for, by using the kubectl auth can-i get command. Specifically, the actor ran any of the following commands:

  • kubectl auth can-i get '*'
  • kubectl auth can-i get secrets
  • kubectl auth can-i get clusterroles/cluster-admin

Step 1: Review finding details

  1. Open the Discovery: Can get sensitive Kubernetes object check finding as directed in Reviewing findings.

  2. In the finding details, on the Summary tab, note the values of following fields:

    • Under What was detected:
      • Kubernetes access reviews: the requested access review information, based on the SelfSubjectAccessReview k8s resource.
      • Principal email: the account that made the call.
    • Under Affected resource:
      • Resource display name: the Kubernetes cluster where the action occurred.
    • Under Related links:
      • Cloud Logging URI: link to Logging entries.

Step 2: Check logs

  1. On the Summary tab of the finding details panel, click the Cloud Logging URI link to open the Logs Explorer.

  2. On the page that loads, check for other actions taken by the principal by using the following filters:

    • resource.labels.cluster_name="CLUSTER_NAME"

    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Replace the following:

    • CLUSTER_NAME: the value that you noted in the Resource display name field in the finding details.

    • PRINCIPAL_EMAIL: the value that you noted in the Principal email field in the finding details.

Step 3: Research attack and response methods

  1. Review MITRE ATT&CK framework entries for this finding type: Discovery
  2. Confirm the sensitivity of the object queried and determine whether there are other signs of malicious activity by the principal in the logs.

  3. If the account that you noted in the Principal email row in the finding details is not a service account, contact the owner of the account to confirm whether the legitimate owner conducted the action.

    If the principal email is a service account (IAM or Kubernetes), identify the source of the access review to determine its legitimacy.

  4. To develop a response plan, combine your investigation results with MITRE research.

What's next