Does COSP require an agent on every Kubernetes node?
No. COSP primarily integrates with the Kubernetes control plane using cluster-level permissions. It collects metadata, resource configuration, entitlement information, and posture telemetry through Kubernetes API access.
What permissions are required to onboard a cluster?
Cluster onboarding requires:
- access to the cluster’s master node CLI
- Linux sudo privileges for installation activities
- Kubernetes cluster-admin privileges to create cluster-scoped objects such as: ClusterRole, ServiceAccount, and ClusterRoleBinding
What Kubernetes objects are created during onboarding?
During onboarding, COSP creates:
- a dedicated namespace
- service account
- cluster role
- cluster role binding
These components enable secure read access required for discovery and security analysis.
How frequently does COSP scan the cluster?
Scanning is continuous and follows configured schedules. Each scan refreshes resource inventory, posture findings, entitlement evaluation, and anomaly observations.
What does COAE discover in the cluster?
COAE identifies cluster assets such as:
- namespaces
- nodes
- pods
- deployments
- daemonsets
- services
- ingress resources
- persistent volumes
- persistent volume claims
- config maps
- secrets
How does COAE help with exposure analysis?
COAE maps discovered assets and helps identify:
- internet-exposed services
- externally reachable workloads
- publicly exposed ingress configurations
- workload communication visibility
Are posture checks benchmark-driven?
Yes. COPM evaluates cluster resources against predefined benchmark rules and policy checks aligned with container security best practice.
Are posture findings updated automatically after a scan?
Yes. Findings are refreshed after each scan cycle so the latest cluster posture is reflected in dashboards and reports.
What security risks does COEM help identify?
COEM helps identify:
- excessive privileges
- over-permissive RBAC assignments
- unnecessary cluster-wide access
- privilege escalation exposure
- broad wildcard permissions
How is anomaly detection different from posture checks?
Posture checks validate resources against predefined rules.
Anomaly detection identifies unusual deviations from established patterns or expected cluster behavior.
Are findings correlated across modules?
Yes. A single resource can appear across multiple modules. For example:
- COAE may identify an exposed service
- COPM may flag insecure configuration
- COEM may show over-permissive access
- COPA may detect abnormal posture change
This gives richer investigation context.
Does COSP support remediation workflows?
Yes. Findings are designed to support investigation, prioritization, and remediation workflows through centralized visibility.
Does deleting a cluster resource automatically remove historical findings?
Historical findings may remain available for auditability until refreshed by subsequent scans or according to platform retention behavior.
Can multiple Kubernetes clusters be managed from one COSP account?
Clusters can be onboarded and monitored centrally, enabling unified operational visibility across environments.
What happens if cluster permissions change after onboarding?
Reduced permissions may affect discovery coverage, entitlement visibility, posture evaluation accuracy, and anomaly detection completeness.
Troubleshooting
Why are no findings visible after onboarding?
Common causes include:
- initial scan not completed
- insufficient Kubernetes permissions
- API access restrictions
Why are some Kubernetes resources missing from inventory?
Possible reasons:
- namespace access restrictions
- deleted resources between scans
- insufficient RBAC permissions
- API visibility limitations
Why do findings change between scans?
Because Kubernetes environments are dynamic. Resource creation, deletion, configuration updates, and permission changes can alter scan results.
