Part seven of our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – examines the technique known as Discovery. The tactics in this category are intended to help an attacker effectively explore a Kubernetes environment to achieve lateral movement and gain access to a wider scope of resources with or beyond the cluster. They include ways to gain access to the Kubernetes API server or the Kubelet API, map the cluster network, or compromise resources via the Kubernetes Dashboard or cloud instance metadata.
This is the final installment of our four-part Google Kubernetes Engine (GKE) security blog series. Don’t forget to check out our previous blog posts in the series: Part 1: GKE Security Best Practices: Designing Secure Clusters Part 2: GKE Networking Best Practices for Security and Operation Part 3: Guide to GKE Runtime Security This post concludes the series by highlighting the routine maintenance and operational tasks required to keep your GKE clusters and infrastructure secured.
Right on the heels of last week’s news that we’re providing Kubernetes security for DoD’s Platform One software factory, we’re excited to share today that we’ve been awarded a Phase III contract with the Department of Homeland Security. In this stage of our partnership, we’re deploying our Kubernetes Security Platform to protect running systems at a large U.S. bank. The DHS Science and Technology Directorate (S&T) uses its Silicon Valley Innovation Program (SVIP) to invest in next-generation security technologies to protect critical infrastructure, including mission-critical, cloud-native applications for financial institutions.
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.