This is part three of our four-part blog series on Google Kubernetes Engine (GKE) security. You can find the previous two parts below: GKE security best practices: designing secure clusters GKE networking best practices for security and operations Adhering to security best practices for running your workloads on GKE plays a critical role in safeguarding your cluster and all its workloads. Misconfigured pods, for example, pose a huge danger if they are compromised.
Part six of our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – covers Credential Access, a set of activities intended for stealing sensitive credentials such as application secrets, passwords, and tokens that may be used by either users or service accounts. These credentials can subsequently be used to gain access to resources that include applications, cluster resources (e.g., pods, controllers, or other Kubernetes objects), cloud resources, and others.
StackRox is in the midst of our own “Fed ramp” of sorts, with news today that we’ve been awarded a Department of Defense SBIR Phase II Award, our long history with In-Q-Tel and multiple deployments in the U.S. Intelligence Community, and more news coming soon on additional Fed initiatives. We have deep roots in protecting the cloud-native apps of many civilian and Intelligence Community agencies, including our long partnership with In-Q-Tel.
In February, we published an article providing a side-by-side comparison of the managed Kubernetes offerings from the three largest cloud providers: Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE). The Kubernetes ecosystem changes rapidly, as do the feature sets of these managed platforms. This post covers important updates to these services made since our original comparison and our April, May, June, and July updates.
This is part two of our four-part GKE security blog series. Don’t forget to check out our previous blog post that covers security best practices for designing your GKE clusters. Securing your GKE cluster’s network traffic and access is crucial for the entire cluster’s security and operation. Follow the below recommendations and best practices to protect your Kubernetes network on GKE. Enable Network Policy Why: By default, network traffic in a Kubernetes cluster can flow freely between pods and also leave the cluster network altogether.
The fifth installment in our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – covers Defense Evasion, a grouping of techniques focused on concealing adversary actions intended to avoid detection. This includes tactics such as deleting evidence of an attacker’s presence or obfuscating how access to a resource was gained. You can find the first four articles in the series below:
As the brainchild behind the original Kubernetes project, Google launched its Google Kubernetes Engine (GKE) platform – then called Google Container Engine – in August 2015. Today, GKE is one of the most popular managed Kubernetes services in the market. Like any infrastructure platform or Kubernetes service, though, GKE customers have to make important decisions and formulate a plan for configuring and maintaining secure GKE clusters. While many of the security requirements and responsibilities apply to all Kubernetes clusters, regardless of where they are hosted, GKE also has several unique requirements that users must consider and act on to ensure that their GKE clusters and the workloads their organization run on them are safeguarded from potential breaches or malicious attacks.
What’s better than being named a Computer Reseller News Emerging Vendor? Winning that designation two years running! We’re thrilled to be included amongst these elite technical innovators. The advantages of our unique Kubernetes-native approach to securing today’s modern apps are earning us kudos across customers (see online reviews on Gartner Peer Insights and G2), cloud partners, resellers, and industry watchers. As companies of all stripes work to accelerate their digital transformation, resellers have a special opportunity to serve as trusted advisors on the path toward app modernization.
Part four of our nine-part blog series on the various Kubernetes threat vectors and tactics covers Privilege Escalation, which encompasses techniques that enable an attacker to gain additional privileges that can be used to take more actions within the cluster and/or grant access to a wider scope of resources. These techniques include accessing or running a privileged container, taking advantage of roles with broad administrative privileges, and gaining access to cloud resources.
This is part three of a nine-part blog series where we examine each of the nine Kubernetes threat vectors across 40 attack techniques and provide actionable advice to mitigate these threats. Don’t forget to check out parts one and two. The third tactic in the Kubernetes attack matrix is Persistence. This tactic groups together techniques that are aimed at enabling an attacker to maintain a presence within a Kubernetes cluster beyond initial access through actions such as taking advantage of Kubernetes controllers, mounting a file to a container, or running recurring Kubernetes Jobs.
We recently published the first part of our nine-part blog series where we take a deep dive into each of the nine Kubernetes threat vectors across 40 attack techniques and provide actionable advice to mitigate these threats. This post is the second in the series and covers tactic #2: Execution. Execution The second tactic in the Kubernetes attack matrix is Execution, which focuses on an attacker running code within a Kubernetes cluster to achieve his or her objectives.