AWS Integration
Overview of the AWS Context Integration using the AWS Agent
Last updated
Was this helpful?
Overview of the AWS Context Integration using the AWS Agent
Last updated
Was this helpful?
The Spyderbat platform is designed to provide a central, detailed contextual view of monitored assets. To achieve this, we start by gathering accurate data regarding the assets using our agent technology.
We then apply contextual and detection analytics to model this context, which forms the core of the platform. To communicate this context, along with security and operational insights, the platform provides a user interface for investigations (backed by an integration API), as well as Reports, Notifications and Actions.
To provide an integrated view, we collect various types of information:
Machine information: This includes data such as processes, listening sockets, connections, and more, collected by the Spyderbat Nano Agent using eBPF technology.
Kubernetes orchestration information: This covers details about active deployments, services, and pods in the cluster, gathered by the Spyderbat ClusterMonitor through the Kubernetes API.
Kubernetes IAM information: This includes Service Accounts, Roles, ClusterRoles, and bindings within the cluster, also collected via the Kubernetes API.
The newest agent in this list is the AWS Agent, which uses various AWS APIs to gather cloud context from the AWS backend hosting your assets.
Currently, the AWS Agent collects the following information from configured AWS accounts:
Cloud Compute Context from AWS EC2 and AWS EKS: This includes all EC2 instances and EKS clusters within an AWS account, along with their detailed configurations and runtime statuses as reported by the AWS API.
Cloud IAM Context from AWS: This includes all AWS Roles and their associated Trust policies and Permission policies.
The AWS Agent is designed to be extendable to collect more information from additional AWS services. Future integrations are planned for AWS Config, AWS ECR Image Registry, AWS GuardDuty, AWS EKS Audit Logs, and AWS CloudTrail.
Kubernetes Workloads: The platform highlights ServiceAccounts used by pods. If a ServiceAccount is linked to an AWS IAM Role (through a role annotation), that IAM Role is also displayed in the AWS accordion in the context of the investigation.
Kubernetes Service Account for a pod with associated IAM Role:
Details of the IAM Role integrated inline in the investigation UI:
AWS EC2 Information: Machine-associated AWS EC2 information is available in a new 'AWS' accordion in the Investigations UI, under the EC2 subtab.
AWS IAM Roles: IAM Roles associated with an EC2 instance (via an instance profile) are displayed within the 'AWS' accordion, in the IAM subtab of the Investigations UI.
AWS EC2 and IAM integrated context in the investigation UI:
These updates allow investigators to quickly locate AWS resource context involved in incidents and assess the associated permissions to evaluate potential impact.
Two new reports are available to leverage the AWS and Kubernetes IAM context collected:
This report provides an overview of all EC2 instances and EKS clusters discovered within a specified AWS account. By comparing the complete list of compute assets with those that have a Spyderbat agent deployed, the report highlights detection coverage and helps identify assets that require monitoring and protection.
This report provides an analysis of RBAC (Role-Based Access Control) and permissions for all Kubernetes workloads within a cluster. It summarizes the permissions associated with Service Accounts used by workloads — covering both Kubernetes roles and permissions (defining actions workloads can perform within Kubernetes) as well as AWS permissions (if the Service Account is associated with an AWS IAM Role).
The following detection analytics have been added to leverage the new context available:
Creation of new Service Accounts in Kubernetes
Deletion of Service Accounts in Kubernetes
Creation of new Roles and ClusterRoles in Kubernetes
Deletion of Roles and ClusterRoles in Kubernetes
Creation of new AWS IAM Roles
Deletion of AWS IAM Roles
Permission drift in configured Kubernetes Roles or ClusterRoles
Permission drift in AWS IAM Roles
Compliance checks against Kubernetes RBAC best practices
To utilize this capability, an AWS Agent must be deployed to collect AWS API data. One agent is required for each AWS account you wish to monitor.
Spyderbat offers multiple deployment options for the AWS Agent, including self-hosted on an AWS VM, deployment on a Kubernetes cluster, or a hosted solution managed by Spyderbat.
For detailed installation and usage instructions, refer to the AWS Agent Installation Documentation.
