> For the complete documentation index, see [llms.txt](https://docs.expel.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.expel.io/detection-strategy-guides/a-c/amazon-aws/amazon-elastic-kubernetes-service-detection-strategy.md).

# Amazon Elastic Kubernetes Service Detection Strategy

## Product Overview <a href="#h_01jz67d9k3h5x9fw134ac33cje" id="h_01jz67d9k3h5x9fw134ac33cje"></a>

Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes platform that simplifies running containerized applications on AWS and on-premises. While not a security monitoring tool, it automates key tasks like provisioning, scaling, and managing Kubernetes control plane infrastructure across multiple AWS Availability Zones for high availability. EKS is certified Kubernetes-conformant, ensuring compatibility with existing Kubernetes tools and applications. It supports deployment on both Amazon EC2 and AWS Fargate, allowing flexibility in choosing compute resources.&#x20;

EKS integrates with AWS services such as IAM for access control, VPC for networking, and CloudWatch for monitoring. Features like EKS Auto Mode automate infrastructure management, including provisioning, scaling, and patching, enhancing operational efficiency. For hybrid environments, EKS Anywhere and EKS Hybrid Nodes enable consistent Kubernetes management across on-premises and edge locations. The EKS console provides a unified interface for managing clusters, and tools like AWS Controllers for Kubernetes (ACK) allow direct management of AWS services from within Kubernetes.

The Expel Amazon Elastic Kubernetes Service security device consumes audit logs from the AWS platform through Kinesis. This visibility allows Workbench to identify activity of interest in EKS, investigate, and notify organizations if action is recommended.

## Detection Strategy for Cloud Integrations <a href="#h_01jz3qmqgm1nbhesa4k4qwtdc7" id="h_01jz3qmqgm1nbhesa4k4qwtdc7"></a>

### Detection <a href="#h_01jz3qn0sc7st1b270cna7574h" id="h_01jz3qn0sc7st1b270cna7574h"></a>

Our cloud security detection strategy focuses on two common signal types at the control plane and resource levels: authentication events and API events. In limited cases, we also ingest certain data plane events such as network activity. We do this by integrating directly with cloud providers as well as cloud security service providers to gain a complete view of your cloud footprint.

We consume these events through a mix of raw log analysis and security alert processing, which are then run through our detection engine to look for signs of post-exploitation activity. When a threat is detected, our automated response bot, Ruxie, takes action by enriching evidence fields with first- and third-party threat intelligence. Additional Ruxie actions query a wide span of technologies in order to directly arm analysts with key pieces of investigative information and related events.

### Response <a href="#h_01jz3qnewa93fnmsd4mqqgqx83" id="h_01jz3qnewa93fnmsd4mqqgqx83"></a>

In addition to verbose evidence collection for cloud alerts, cloud technologies are useful for triaging SaaS and identity alerts as well. User activities within the cloud providers, along with related alerts for anomalous indicators, help analysts gain a full picture of the activity that occurred within a session.

To learn more about our overall approach to detection strategy, see [About Detection Strategy](/workbench-reference/detections/about-detection-strategy.md).

## What We Support for Amazon Elastic Kubernetes Service <a href="#h_01jz3qpkga0vgnt9fhy2hd3pka" id="h_01jz3qpkga0vgnt9fhy2hd3pka"></a>

To see a comprehensive list of the most up-to-date Expel detection rules, vendor detection rules, opt-in detections, and available DUETs (**d**id yo**u** **e**xpect **t**his) that we support for Amazon Elastic Kubernetes Service, you can visit the [Detections page](https://workbench.expel.io/tools/detections/all?filter=%7B%22supportedTech%22%3A%7B%22is%22%3A%5B%22kubernetes_eks%3A1.0.0%22%5D%7D%7D) in Workbench or ask your Sales or Support rep for the most recent download.

| **Supported platform**               | <ul><li>Kinesis</li></ul>                                    |
| ------------------------------------ | ------------------------------------------------------------ |
| **Supported event log sources**      | <ul><li>Amazon Elastic Kubernetes Service (EKS)</li></ul>    |
| **Detection rules written by Expel** | Yes.                                                         |
| **Hunting support**                  | No. Hunting is not currently available for this integration. |

## Additional Details and Common Questions <a href="#h_01jz3r2q03bj8haj940pj1c8n4" id="h_01jz3r2q03bj8haj940pj1c8n4"></a>

### Console Access <a href="#h_01jz3r2tr0k5j43eypnfj1fqnb" id="h_01jz3r2tr0k5j43eypnfj1fqnb"></a>

A vendor alert does not typically include all of the contextual timeline activity surrounding the event of interest. Because this integration does not allow us to get all necessary data via the API, we will ask you for a certain level of console access during onboarding.

The level of access that we require is meant to support essential triage and research activities, and to help us determine the vector and extent of attacker activity for an identified threat. At minimum, we will ask for visibility into alert data, timeline events recorded, and live response/real time response shell (if applicable).

### DUET <a href="#h_01jz3r3bafff9fztd7dfz6n3wf" id="h_01jz3r3bafff9fztd7dfz6n3wf"></a>

A DUET (**d**id yo**u** **e**xpect **t**his) rule flags certain events as needing an immediate verification or notification, and bypasses the normal internal event triage process. The events subject to DUET rules contain behaviors that are not typically indicative of true security incidents, as they are related to policy violations or *potential* risk.

There are a number of workflows that a DUET may follow. When enabled, the activity will be flagged for investigation and will be routed to you (rather than to us) to take a specified first action. To see the specific DUET rules currently supported for this integration, visit the [Detections page](https://workbench.expel.io/tools/detections/all).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.expel.io/detection-strategy-guides/a-c/amazon-aws/amazon-elastic-kubernetes-service-detection-strategy.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.