A common customer question is how to view host vulnerabilities in the Asset Inventory for each Cloud Service Provider. In this article, we will focus on Azure, following up with articles for GCP and AWS.     Kubernetes is a popular container orchestration tool.  Most Cloud Service Providers have a managed offering.  Azure has AKS, Google offers GKE, AWS has EKS and Red Hat offers RedHat openshift.   The container workloads for all of these managed offerings run on host machines and those machines can contain vulnerabilities.

A common customer question is how to view host vulnerabilities in the Asset Inventory for each Cloud Service Provider. Host vulnerabilities are easily identified in the Runtime Security Module, by selecting Monitor - Vulnerabilities - Hosts.    Most Cloud Service Providers have a managed offering-- Azure has AKS, Google offers GKE, AWS has EKS and Red Hat offers RedHat openshift; in this article, specifically, we will focus on EKS. The container workloads for all of these managed offerings run on host machines and those machines can contain vulnerabilities.   The Prisma Cloud Command Center (Figure 1) and Vulnerabilities (Figure 2) dashboards are the first high level dashboards that provide visibility into Vulnerabilities, and its purpose is to identify top issues by severity for hosts, images and repositories.  In order to narrow the scope and filter based on EKS worker nodes in Cloud Security, it is recommended to explore the asset inventory.

Prisma Cloud Console is backwards compatible with up to two (n-2) major releases back (including all minor versions) for the following:   All types of Defenders. Twistcli/Jenkins plugin.

This document presents a step-by-step guide for automating the deployment of Prisma Cloud Windows container defender to Google Kubernetes Engine Windows nodes. You will set up a Kubernetes cluster with a Windows node-pool and leverage the Google Cloud startup scripts on Windows VMs to install the Prisma Cloud container defenders. We will discuss installation of Prisma Cloud defender on Windows Google Kubernetes Engine clusters.

This document showcases the process of how to deploy the Prisma Cloud Compute console in a Kubernetes cluster on any cloud provider and use a NGINX Ingress controller as a proxy for this console. Purpose For many enterprises, moving production workloads into Kubernetes brings additional challenges and complexities around application traffic management. An Ingress controller abstracts away the complexity of Kubernetes application traffic routing and provides a bridge between Kubernetes services and external ones.  

The Prisma Cloud Runtime Security DaemonSet auto-deploy feature uses a kubeconfig file generated from a kubernetes service account with limited permissions.    Purpose If you aim to streamline the deployment of Defender DaemonSets to a cluster or lack direct kubectl access to your cluster, you can conveniently deploy Defender DaemonSets directly from the Console UI.   The Auto-Defend feature also allows you to upgrade with ease any Defender that you have deployed before, so you could easily perform the upgrade process from the Console UI or automate it by making API calls to the appropriate console endpoints.