Discovery: Can get sensitive Kubernetes object check
Stay organized with collections
Save and categorize content based on your preferences.
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.
Overview
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
How to respond
To respond to this finding, do the following:
Step 1: Review finding details
Open the Discovery: Can get sensitive Kubernetes object check finding as
directed in Reviewing findings.
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
On the Summary tab of the finding details panel, click the
Cloud Logging URI link to open the Logs Explorer.
On the page that loads, check for other actions taken by the principal by
using the following filters:
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
Review MITRE ATT&CK framework entries for this finding type:
Discovery
Confirm the sensitivity of the object queried and determine whether there are
other signs of malicious activity by the principal in the logs.
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.
To develop a response plan, combine your investigation results with
MITRE research.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["| Premium and Enterprise [service tiers](/security-command-center/docs/service-tiers)\n\nThis document describes a threat finding type in Security Command Center. Threat findings are generated by\n[threat detectors](/security-command-center/docs/concepts-security-sources#threats) when they detect\na potential threat in your cloud resources. For a full list of available threat findings, see [Threat findings index](/security-command-center/docs/threat-findings-index).\n\nOverview\n\nA potentially malicious actor attempted to determine what sensitive objects in\nGKE they can query for, by using the [`kubectl\nauth can-i get`](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access) command. Specifically,\nthe actor ran any of the following commands:\n\n- `kubectl auth can-i get '*'`\n- `kubectl auth can-i get secrets`\n- `kubectl auth can-i get clusterroles/cluster-admin`\n\nHow to respond\n\nTo respond to this finding, do the following:\n\nStep 1: Review finding details\n\n1. Open the `Discovery: Can get sensitive Kubernetes object check` finding as directed in [Reviewing findings](/security-command-center/docs/how-to-investigate-threats#reviewing_findings).\n2. In the finding details, on the **Summary** tab, note the values of\n following fields:\n\n - Under **What was detected** :\n - **Kubernetes access reviews** : the requested access review information, based on the [`SelfSubjectAccessReview`](https://kubernetes.io/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1/) k8s resource.\n - **Principal email**: the account that made the call.\n - Under **Affected resource** :\n - **Resource display name**: the Kubernetes cluster where the action occurred.\n - Under **Related links** :\n - **Cloud Logging URI**: link to Logging entries.\n\nStep 2: Check logs\n\n1. On the **Summary tab** of the finding details panel, click the **Cloud Logging URI** link to open the **Logs Explorer**.\n2. On the page that loads, check for other actions taken by the principal by\n using the following filters:\n\n - `resource.labels.cluster_name=\"`\u003cvar class=\"edit\" translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`\"`\n - `protoPayload.authenticationInfo.principalEmail=\"`\u003cvar class=\"edit\" translate=\"no\"\u003ePRINCIPAL_EMAIL\u003c/var\u003e`\"`\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the value that you noted in the\n **Resource display name** field in the finding details.\n\n - \u003cvar translate=\"no\"\u003ePRINCIPAL_EMAIL\u003c/var\u003e: the value that you noted in the\n **Principal email** field in the finding details.\n\nStep 3: Research attack and response methods\n\n1. Review MITRE ATT\\&CK framework entries for this finding type: [Discovery](https://attack.mitre.org/tactics/TA0007/)\n2. Confirm the sensitivity of the object queried and determine whether there are other signs of malicious activity by the principal in the logs.\n3. If the account that you noted in the **Principal email** row in the\n [finding details](#discovery_gke_findings) is not a service account,\n contact the owner of the account to confirm whether the legitimate owner\n conducted the action.\n\n If the principal email is a service account (IAM or\n Kubernetes), identify the source of the access review to determine its\n legitimacy.\n4. To develop a response plan, combine your investigation results with\n MITRE research.\n\nWhat's next\n\n- Learn [how to work with threat\n findings in Security Command Center](/security-command-center/docs/how-to-investigate-threats).\n- Refer to the [Threat findings index](/security-command-center/docs/threat-findings-index).\n- Learn how to [review a\n finding](/security-command-center/docs/how-to-investigate-threats#reviewing_findings) through the Google Cloud console.\n- Learn about the [services that\n generate threat findings](/security-command-center/docs/concepts-security-sources#threats)."]]