Kubernetes serves as the backbone of modern cloud-native applications, providing scalability, flexibility, and automation for deploying and managing workloads. In many organizations, a single Kubernetes cluster is shared across multiple teams to maximise resource efficiency, reduce operational overhead, and simplify infrastructure management. However, when an incident occurs in such environment, security teams must navigate a minefield of challenges such as isolating affected workloads without disrupting business-critical applications, identifying the root cause in a highly dynamic infrastructure, and ensuring that attackers cannot exploit inter-team trust boundaries. This article provides a structured approach to handling incidents in shared Kubernetes clusters, specifically focusing on the recommended and not-so-recommended isolation and containment practices of the incident response framework.

The main goal of this document is to define a method for controlling data and security compliance in an AWS landing zone environment, where many different applications/platform teams are accessing the landing zone. An AWS landing zone environment is already fully configured using AWS Organisations to deploy different components from scratch following the AWS Security Reference Architecture. However, for the purpose of this document we will assume AWS Control Tower has not been used to curate organisation accounts, and instead a custom process is in place as part of AWS Organizations.