# Source: https://docs.datadoghq.com/security/default_rules/def-000-b69.md

---
title: AWS principal granted access to a EKS cluster then removed
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Datadog Security > OOTB Rules > AWS principal granted access to a EKS
  cluster then removed
---

# AWS principal granted access to a EKS cluster then removed
Classification:attackTactic:[TA0005-defense-evasion](https://attack.mitre.org/tactics/TA0005)Technique:[T1070-indicator-removal](https://attack.mitre.org/techniques/T1070) 
## Goal{% #goal %}

Detect when an AWS principal is assigned permissions on an Amazon EKS cluster, and removed permissions shortly after. This can be an indicator of an attacker temporarily granting themselves access to an EKS cluster, then removing permissions to stay under the radar.

## Strategy{% #strategy %}

This rule leverages CloudTrail and triggers if an event `CreateAccessEntry` is followed by `DeleteAccessEntry` for the same AWS principal within 1 hour.

To learn more about EKS Cluster Access Management, see this guide on Datadog Security Labs: [Deep dive into the new Amazon EKS Cluster Access Management features](https://securitylabs.datadoghq.com/articles/eks-cluster-access-management-deep-dive/).

## Triage and response{% #triage-and-response %}

1. Determine if `@requestParameters.principalArn` should have access to the EKS cluster.
1. Determine if `{{@userIdentity.session_name}}` should have granted permissions on the EKS cluster.
1. If the API calls were not made by the user:

- Rotate user credentials.
- Determine what other API calls were made by the user.
- Revert the permissions change by removing the access entry.
If the API calls were made by the user:
- Determine if the user should be granting access to the cluster.
- If not, see if other API calls were made by the user and determine if they warrant further investigation.