alcide

Alcide Blog

Cloud-native Security Provider

Kubernetes Threat Vectors: Part 6 - Credentials Access

Dec 31, 2020 10:15:53 AM / by Alon Berger

 

Welcome to our sixth blog post on the Kubernetes threat vectors series.

We are covering different tactics on the Kubernetes attack matrix, published by Microsoft and originally based on the MITRE ATT&CK framework. In this blog post, we will review the Credential Access tactic, and cover its techniques.

 

What is Credential Access?

The credential access tactic consists of techniques that are used by attackers to steal credentials including passwords, tokens and sensitive application secrets. Holding such credentials enables the attacker to gain access to essential cloud resources and Kubernetes objects.

Let’s review the different techniques:

 

  • List Kubernetes secret

    The Kubernetes Secret objects store and manage sensitive information such as sensitive credentials and are easily consumed by reference in the pod configuration.
    Attackers can exploit misconfigurations and weaknesses to gain permission from the Kubernetes API server, and retrieve valuable information from the Secret objects.

    How to mitigate?


    The best way to keep your sensitive information safe is to tweak the Role-based access control (RBAC) configurations, so that permissions for users and service accounts are limited, allowing access to secrets only for authorized personnel within the organization.

    Alcide’s kAdvisor and Admission Controller help in hunting for misplaced secrets and ensuring they do not find their way into production environments. In addition, with the kArt module, DevSecOps teams can easily deploy microservices firewall policies and perform quick validation for service accounts.


  • Mount service principal

    When managing and deploying Kubernetes clusters in the cloud, there is the risk of attackers leveraging their access to containers and getting access to other cloud resources outside the cluster. Cloud providers often use a service principal credential in each node, mostly needed for cluster operation. Attackers who get access to this service principal file (by hostPath mount, for example) can use its credentials to access or modify the cloud resources.

    How to mitigate?

    Mitigating this in Kubernetes’ territory, an organization should apply the same precautions used against the “hostPath mount” technique, under the Privilege Escalation tactic. The main focus should be on applying Pod Security Policies (PSPs) in order to limit the file paths that can be mounted using a host mount, or deny it completely. Leveraging the admission controller’s capabilities is also recommended here, as it enables better control in preventing compromised containers from being deployed into clusters in production.

    Another area to keep in mind is the cloud provider’s platform and resources. The managed services these providers offer should include tools that help manage cloud metadata and detect compromised pods.

 

  • Access container service account

    A Kubernetes service account represents the identity given to a process that runs in a pod. By default, any service account is mounted new pod created in the cluster, allowing containers in pods to communicate with the Kubernetes API server. The attacker’s goal is to gain access to a pod, reach the mounted service account’s token, and perform actions within the cluster. If RBAC is disabled, the default permissions for the service account are unlimited.

    How to mitigate?

    Same with the last technique, the main focus here is RBAC configurations. Permissions should be strictly limited to administrators and cluster-admin roles, stripping down unnecessary privileges for any user, group, or service account.

    Alcide helps with several pre-deployment capabilities such as scanning and monitoring RBAC settings, highlighting drifts and misconfigurations, customized security policies, and seamless integrations across the CI/CD pipeline.

 

  • Application credentials in configuration files

    Kubernetes secrets are often stored as environment variables in the Kubernetes configuration files. Attackers gaining access to these files can easily steal stored secrets and use them.

    How to mitigate?

    Secrets should be closely monitored and have limited access by properly tweaking the RBAC controls. API server policies should be implemented and used to enforce read-only operations and access to configuration files. Furthermore, it is highly recommended to keep close track of the Kubernetes audit logs, using an automated analysis tool like kAudit, intercepting any suspicious activity or unusual events on the network.

 

What We Think Is Missing

As we go and cover the different tactics and techniques in the Kubernetes attack matrix, we’re also providing our take on it, and what we think Microsoft has left out, specifically within the Kubernetes domain. In one of our previous blogs - Cloud Native Security for Kubernetes In Practice, we talked about cluster operations threats and risks, and how they are usually associated with either the supply chain (CI/CD pipeline) or the Runtime environment.

With that in mind, we took the liberty to add several noteworthy security elements, that were not found in Microsoft Azure’s original matrix:


One key element that we think is missing here is that with Kubernetes, admission controllers and Kubernetes operators can also be compromised, and should not be an afterthought when it comes to security. If attackers compromise an admission controller, they can inject malicious sidecar containers to any pod of their desire. Read the full article on Dark Reading magazine - Microsoft's Kubernetes Threat Matrix: Here's What's Missing.

Stay tuned for our next chapter, where we will review the seventh tactic - Discovery.

 

Want to give Alcide a try? Sign up for our 14-day trial to fully experience our platform.

 

 

Subscribe to Email Updates