Azure Kubernetes Service accounts accessing sensitive objects

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Sensitive object access is not necessarily malicious, but user and object context can provide guidance for detection. You want to investigate sensitive object access on your network to determine if it represents a threat.

Required data

Kubernetes
Azure storage data

Procedure

Ensure that you have configured Kube-Audit data diagnostics.
Run the following search. You can optimize it by specifying an index and adjusting the time range.

sourcetype=mscs:storage:blob:json category=kube-audit 
| spath input=properties.log
| search objectRef.resource=secrets OR configmaps user.username=system.anonymous OR annotations.authorization.k8s.io/decision=allow  
| table user.username user.groups{} objectRef.resource objectRef.namespace objectRef.name annotations.authorization.k8s.io/reason 
| dedup user.username user.groups{} |`kubernetes_azure_detect_sensitive_object_access_filter`

Search explanation

The table provides an explanation of what each part of this search achieves. You can adjust this query based on the specifics of your environment.

Splunk Search	Explanation
sourcetype:mscs:storage:blob:json	Search only the source type mscs:storage:blob:json.
category=kube-audit	Search the data source kube-audit from the diagnostic logs in Azure Cloud services.
\| spath input=properties.log	Extract fields from the properties Kube-Audit log.
\| search objectRef.resource=secrets OR configmaps	Search specific, sensitive resources, such as secrets or configmaps.
user.username=system.anonymous OR annotations.authorization.k8s.io/decision=allow	Search for anonymous users or any requests with allow decisions.
\| table user.username user.groups{} objectRef.resource objectRef.namespace objectRef.name annotations.authorization.k8s.io/reason	Display the results in a table with columns in the order shown.
\|dedup user.username user.groups{}	Remove duplicate results from the same user names and user groups.

Next steps

Compromise of sensitive objects can lead to cluster compromise and further lateral movement. Secrets and configmaps are highly sensitive objects due the cluster information they contain. Multiple failed or denied attempts may indicate suspicious activity. Source IP address, users, geolocation, and reputation are other useful contextual items to evaluate to look for compromise. To refine the search, adding data.labels.authorization.k8s.io/decision!=allow may give fewer results and more specific context on errors or suspicious requests.

For additional information about this search, such as its applicability to common frameworks and standards, see this project on GitHub for AWS, Azure, or GCP.

Finally, you might be interested in other processes associated with the Monitoring Kubernetes sensitive object access use case.