The Container Orchestration Asset Exposure(COAE) tool allows organizations to efficiently monitor and manage containerized environments through a unified platform. It enables the configuration and viewing of watchlists, tracking Kubernetes cluster health and resource status, and assessment of open port exposures to enhance security.
COAE provides insightful visibility into resource distribution across clusters and namespaces, monitors workload performance, and categorizes resources for better organization. It also visualizes the relationships between containers and images, analyzes fluctuations in both cluster-scoped and namespaced resources, and tracks trends in images and workloads over time.
With detailed visibility and export options for cloud resources, COAE empowers users to maintain optimized, secure, and well-organized container infrastructures.
Get Started
This guide walks you through every stage of using COAE, from initial setup to advanced monitoring and analytics. You’ll learn how to configure and manage watchlists, assess resource utilization, analyze open port exposures, and track workload and image trends over time. With COAE, you gain actionable insights that simplify complex container orchestration operations, ensuring better reliability, scalability, and compliance.
By the end of this guide, you would have tapped into COAE’s full capabilities for intelligent, data-driven management of your Kubernetes and cloud ecosystems.
Access the Container Orchestration Asset Exposure (COAE) Tool
You can access the COAE Dashboard through 2 entry points: the overall COSP Dashboard or directly via the App Launcher.
EntryPoint 1: From the Overall COSP Dashboard
EntryPoint 2: From the App Launcher
Configure Watchlist
Configuring watchlists in container orchestration asset exposure allows users to proactively monitor critical namespaces and resource types. This paves way for early detection of misconfigurations, unauthorized access, and more.
Watchlists help prioritize scanning either on the current dataset or the next scheduled scan, while providing audit traceability through a required reason for monitoring. By focusing on selected resources, they simplify management in complex environments and support compliance with organizational security policies.
Note: All fields in the watchlist configuration are mandatory except the Application Scan Timing.
Here’s how to Configure a Watchlist:
Step1: Provide a Name
Enter a meaningful name for the watchlist configuration to help you identify it later.
Step2: Select a Namespace
From the drop-down menu, choose the namespace you want to monitor. Once selected, the related resource types for that namespace automatically displays in the “Resource Types” drop-down.
Step3: Choose Resource Types
Select one or more resource types associated with the chosen namespace from the drop-down list.
Step4: Provide a Reason
Enter a valid reason for creating this watchlist. This helps with audit tracking and documentation.
Step5: Specify Scan Time
Specify if the watchlist must apply to:
- Current dataset: applies immediately to the existing scanned data
- Next cloud scan: applies when the next scheduled cloud scan runs
Step6: Add to Watchlist
After completing your watchlist configuration, click the Add to Watchlist button to save your configuration and use it when you need it again.
Step7[Optional]: Clear Configuration
If you want to set up the configuration all over again, just go ahead and click the Clear Configuration button to clear all the data.
Monitor Kubernetes Cluster Health and Resource Status
The dashboard view provides a quick health and status overview of key Kubernetes resources such as control plane nodes, worker nodes, namespaces, images, and containers so that issues such as node failures, deprecated images, or container errors can be identified and acted upon immediately.
Assess Open Port Exposure in Container Orchestration
The Open Ports Distribution block presents a clear overview of open port distribution across assets, categorized by risk level (high, medium, and low). This helps security teams quickly assess exposure in containerized and orchestrated environments, prioritize the remediation of critical risks, and enhance the overall network security posture.
In this case, the dashboard shows a total of 739 open ports, with 282 classified as high-risk, 78 as medium-risk, and 379 as low-risk. This indicates a significant exposure within container orchestration assets.
High-risk ports are often associated with critical components like the Kubernetes API, etcd, or database services, where exposure could potentially lead to a complete cluster compromise. Medium-risk ports may expose internal services or administrative dashboards, while the large number of low-risk ports still increase the attack surface in a dynamic container environment.
To reduce exposure, organizations should restrict access to sensitive ports, apply Kubernetes NetworkPolicies, review service configurations (such as NodePort, LoadBalancer, and ingress), and continuously monitor port states to maintain a zero-trust security posture.
Analyze Kubernetes Resources Distribution for Cluster and Namespace
The dashboard view provides visibility into Resources Distribution, helping administrators quickly identify the type and proportion of resources in the cluster. This supports tasks such as security auditing, capacity planning, and governance enforcement by showing how roles, bindings, namespaces, and nodes are structured across the cluster.
By toggling between Cluster-Scoped and Namespaced views, users can understand how resources are allocated and managed at different scopes within the cluster.
Analyze Cluster-Scoped Resource Distribution in Kubernetes
The visualization shows the distribution of cluster-scoped resources within the Kubernetes environment. It highlights key entities such as ClusterRole, ClusterRoleBinding, Namespace, and Node, with their relative sizes reflecting their count or usage.
Analyze Namespaced Resource Distribution in Kubernetes
The visualization shows the distribution of Namespaced resources within the Kubernetes environment. It highlights key entities such as Pod, Role, ServiceAccount and more with their relative sizes reflecting their count or usage.
How is Data Captured and Presented in Workload Status?
The workload status dashboard in Kubernetes collects data directly from the cluster to display the health and progress of various controllers.
For Deployments, it monitors the desired, updated, ready, and unavailable replicas to reflect the progress of rollouts. For StatefulSets, it shows the desired, current, ready, and updated replicas, ensuring that pods are created in order and align with the latest template.
For DaemonSets, it reports the number of pods that are scheduled, ready, updated, or unavailable across nodes, confirming coverage throughout the cluster. Finally, for CronJobs, it provides scheduling details, including the last and next run times, active jobs, and execution history by connecting with related Job resources.
Understand and Organize Resources through Categorization
The Resource Categorization view provides a clear overview of how container orchestration assets are distributed across various categories. It provides a comprehensive perspective of all resources within a cluster using a standardized categorization language. This common terminology helps make sense of resources allocated across different container orchestration platforms, such as Kubernetes and OpenShift, as well as public cloud infrastructures like AWS and Azure. This approach facilitates the development of a simplified mental model that is both concise and consistent with various types of infrastructure and their unique terminologies.
As an example, for a team that manages AWS cloud resources and Kubernetes workloads through AWS EKS, this sample visualization can prompt important questions such as, how do the 196 IAM resources within the Kubernetes cluster relate to the IAM resources in the associated AWS account? why are there no storage resources allocated in the cluster? Is it intentionally designed to run only compute workloads? and so on.
Additionally, the dashboard snapshot also highlights where resources are concentrated, identifies areas with higher exposure risks, and points out critical gaps. High counts in categories like Identity and Access Management (IAM) and Workload Management indicate areas that need closer security attention.
In contrast, low or zero counts in categories such as Monitoring/Logging and Admission Control suggest a lack of necessary observability and enforcement controls.
How Resource Categorization Works?
Resource categorization organizes Kubernetes assets into functional groups. This helps teams to quickly see what kind of assets are present, their volume, and where the exposure risk exists.
Here’s how it works:
Capture Orchestration Resource
The orchestration system queries the Kubernetes API server to collect all active resources across namespaces, extracting details about workloads, services, and policies for further analysis.
Categorize Resources by Function
Each resource is mapped to a functional group, such as IAM, Workload Management, Networking, Storage, or Monitoring, based on its role in managing access, workloads, configurations, or cluster operations.
Visualize Asset Distribution in Dashboard
The results are presented in a dashboard view, showing counts per category to reveal large surface areas, most allocated resource category, and missing components such as Monitoring or Admission Control.
How are Resources Grouped into Categories?
The resources are organized by their functions and roles within the container orchestration platform, such as Kubernetes. This structure enhances visibility into the most populated functional areas, helps identify potential exposure risks, and highlights where coverage may be insufficient.
The grouping is done by mapping Kubernetes resource kinds to predefined functional categories:
Identity and Access Management (IAM)
Resources that manage user, service, and workload access (for example, Roles, ClusterRoles, RoleBindings, ServiceAccounts).
Workload Management
Resources that define and operate workloads (for example, Deployments, ReplicaSets, StatefulSets, DaemonSets, Jobs, CronJobs).
Configuration Management
Objects that hold configuration and sensitive data (for example, ConfigMaps, Secrets).
Cluster Management
Cluster-wide objects used for governance and structure (for example, Nodes, Namespaces, ResourceQuotas, Limits).
Networking
Resources that control communication and exposure (for example, Services, Ingress, NetworkPolicies, Endpoints).
Core Resource
Fundamental building blocks like Pods and essential controllers.
Admission Control
Resources enforcing runtime policies (for example, ValidatingWebhookConfiguration, MutatingWebhookConfiguration, PodSecurityPolicy).
Monitoring and Logging
Observability-related resources such as Events, metrics servers, or custom logging CRDs.
Storage
Resources tied to persistence and volumes (for example, PersistentVolumes, PersistentVolumeClaims, StorageClasses).
Track Container to Image Mapping
The Mapping: Containers to Images clarifies the connection between containers and their underlying images. This aids users in tracking image usage, identifying outdated or vulnerable images, and ensuring compliance and operational integrity within Kubernetes environments.
The dashboard block helps you monitor and understand the relationship between deployed containers and their underlying images. It offers insight into which images are currently in use, helps identify outdated or vulnerable images, and supports operational auditing and compliance within Kubernetes environments.
This view presents a tabular mapping between running containers and their associated container images and includes the following columns:
Container ID
A unique identifier for each running container instance.
Container Name
The name assigned to the container(for example, coredns, etcd, game-2048).
Image Name
The source image repository and tag from which the container was created(for example, registry.k8s.io/coredns, docker.io/alexwhen/docker-2048).
Image ID
The digest or unique identifier of the image used.
At the bottom of the table, you see the pagination information(for example, showing entries 1–15 of 25) and options for exporting to CSV, as well as a selection for the number of entries displayed per page.
Monitor Image and Container Workload Trends Over Time
Asset Workloads Over Time: Images and Containers helps you to monitor and analyze workload trends by tracking the variation in the number of images and running containers over a selected time period, enabling better visibility into workload growth, utilization, and operational patterns.
The dashboard block presents a line chart that visualizes workload trends over a selected period. The chart displays dates (in the format yyyy-mm-dd) on the x-axis and workload counts on the y-axis, making it easy to track changes in the number of images and running containers over time.
By hovering over the chart, you can see precise counts for each date. As an example, the “Asset Workloads over Time” chart highlights the number of images and running containers from September 3 to October 14, 2025. It shows a steady increase beginning around September 8, peaking on September 24 with a total of 10 images and 41 running containers. Following this peak, the workload declines and stabilizes by mid-October. This visualization reveals how container activity fluctuates in relation to the availability of images, making it easier to track workload scalability and deployment trends over time.
Additionally, you have an option to export the data to CSV format, allowing for further analysis or reporting.
Monitor Fluctuations in Cluster-scoped and Namespaced Resources Over Time
Resources Over Time: Cluster-Scoped, Namespaced helps you tomonitor and analyze the growth and variation of cluster-scoped and namespaced resources over time, providing insights into resource utilization trends and helping to identify changes in cluster activity or configuration.
The dashboard block presents an area chart that visualizes resource trends over time. The chart displays dates (formatted as yyyy-mm-dd) on the x-axis and resource counts on the y-axis, enabling you to track fluctuations in both cluster-scoped and namespaced resources.
By hovering over the chart, you can see detailed resource counts for specific dates. Additionally, you have an option to export the data as a CSV file is available for further analysis and reporting.
Monitor and Manage Cloud Resources with Detailed Visibility and Export Options
All Resources provides a detailed overview of the resources available in the environment, allowing you to quickly identify, categorize, and assess resource details, including accessibility status, for more effective inventory management and security oversight.
The dashboard presents a column view of all the resources along with their Resource ID, Resource Name, Resource Type, Namespace, Resource Category, and if the resource is Publicly Accessible.
By clicking on the Resource ID link, users can access additional details including Cloud Account ID, Cloud Provider, Profile Name, Region Name, Resource Category, Service Type, and a detailed summary covering Reservations, Groups, Instances, and more.
You can take various actions from the view, such as sorting or filtering, searching for keywords, selecting the number of records to view, and exporting the records into a spreadsheet (CSV). Additionally, you can adjust the number of records shown, making navigation easier.
Visual indicators assist you to monitor the status of Publicly Accessible resources, with exposed resources displayed in orange and non-exposed resources in grey. This setup allows for quick identification of which instances are actively utilizing public network interfaces, aiding in security and resource management decisions. The visualization and linked data provide a comprehensive tool for monitoring cloud environments, ensuring informed security decisions and effective resource management.
Commonly Asked Questions
Are all fields mandatory while configuring a Watchlist?
Yes, all fields are mandatory except the “Application Scan Timing”, which is optional.
What happens when I select a Namespace?
When you select a namespace, the system automatically displays the Resource Types dropdown with relevant resource types associated with that namespace.
Is there a limit to select resources in a Watchlist?
No, you can select one or more resource types from the available list based on your monitoring requirements.
Why is providing a reason mandatory for Watchlist creation?
The reason field ensures:
- Audit traceability
- Proper documentation of monitoring intent
- Compliance with organizational security policies
What are the available scan timing options?
You can choose:
- Current dataset – applies the watchlist immediately to existing scanned data
- Next cloud scan – applies the watchlist during the next scheduled scan
Where can I view my configured Watchlists?
You can view them in the Watchlist Resources dashboard, which provides a tabular view of all monitored resources.
Can I export Watchlist data for analysis?
Yes, the dashboard allows you to export the data in .csv format for further analysis and reporting.
How do I look for specific Watchlist entries?
Use the search box in the dashboard to quickly locate specific resources based on your criteria.
Can I control how many records are displayed in the dashboard block?
Yes, you can adjust the number of records displayed using the dropdown available at the top-right corner of the dashboard block.
How do Watchlists help in compliance and governance?
Watchlists support compliance by:
- Enforcing focused monitoring of critical resources
- Providing audit-ready documentation (via reasons)
- Enabling traceability of monitored entities
I want to take a quick glance at the Kubernetes cluster health? How’s that possible in COAE?
The COAE dashboard provides a centralized, real-time overview of the health and operational status of key Kubernetes components such as control plane nodes, worker nodes, namespaces, images, and containers. It enables rapid detection of failures, misconfigurations, and runtime issues.
Which Kubernetes components are monitored in the health dashboard?
The dashboard tracks:
- Control plane nodes (API server, scheduler, controller manager)
- Worker nodes
- Namespaces
- Container images
- Running containers and pods
I want to quickly identify cluster issues and take corrective actions?
The dashboard highlights anomalies such as node failures, unhealthy pods, deprecated or vulnerable images, and container runtime errors, allowing administrators to take immediate corrective action.
Can COAE detect image-related risks?
Yes, the tool identifies deprecated or potentially vulnerable container images and displays on the dashboard to help teams enforce secure image usage policies.
I want to understand the network exposure within the Kubernetes environment? How does the dashboard support this?
The “Open Port Distribution” block on the dashboard provides a visualization that categorizes open ports across cluster assets based on risk levels (high, medium, low), helping teams understand network exposure within the Kubernetes environment.
How does COAE take care of the open port risks?
The COAE tool evaluates port-related risks by categorizing them into distinct risk levels, and displaying on the dashboard:
- High Risk: Ports that expose critical services such as the Kubernetes API, etcd, or databases
- Medium Risk: Ports that expose internal tools or administrative interfaces
- Low Risk: Ports with minimal direct impact but that still contribute to the overall attack surface
What does a high number of open ports indicate?
A large number of open ports suggests increased attack surface and potential misconfigurations, making the environment more vulnerable to external threats.
How can organizations reduce open port exposure?
Recommendation is to Restrict access using firewall rules and security groups, Implement Kubernetes NetworkPolicies, Review service types (NodePort, LoadBalancer, Ingress), and Continuously monitor and audit open ports.
How does open port monitoring support a zero-trust model?
By continuously validating and restricting access to only required ports, organizations ensure that no implicit trust is granted, minimizing lateral movement and unauthorized access.
What is the difference between cluster-scoped and namespaced resources?
Cluster-scoped resources exist at the cluster level and are not bound to a namespace (e.g., Nodes, ClusterRoles). On the other hand, Namespaced resources exist within a specific namespace (e.g., Pods, Services, RoleBindings).
Which resources are considered cluster-scoped?
Common cluster-scoped resources include:
- ClusterRole
- ClusterRoleBinding
- Namespace
- Node
What insights does cluster-scoped distribution provide?
It helps identify:
- Role-based access control (RBAC) structure
- Node distribution and scaling
- Namespace organization across the cluster
- Namespaced Resource Distribution
Which resources are considered namespaced?
Typical namespaced resources include:
- Pods
- Roles
- ServiceAccounts
- Services
How does combining health monitoring and resource distribution improve security?
By correlating runtime health data with resource allocation, administrators can quickly pinpoint misconfigurations, unauthorized access patterns, and potential vulnerabilities.
How frequently should cluster health and port exposure be monitored?
Continuous monitoring is recommended, with real-time alerts for critical issues and periodic audits for compliance and governance.
