The AWS Shared Responsibility Model for Kubernetes
Amazon Web Services‘ Shared Responsibility Model clearly delineates the infrastructural security responsibilities covered by AWS and those responsibilities that fall on the enterprises themselves.
AWS takes responsibility for the security “of” the cloud — fully protecting the infrastructural assets it provides. At the same time, AWS customers are responsible for securing all aspects of the data and solutions they run in the cloud. To meet these responsibilities, customers utilizing the AWS to operate Kubernetes, Red Hat OpenShift, EKS, or ECS environments absolutely must come to the table with their own effective AWS container security strategy.
The AWS Shared Responsibility Model
Note that the shared responsibility model tasks you with monitoring and properly configuring AWS-provided operating systems, networks, and firewalls, in addition to your own data, orchestration platform, etc. Additionally, the approach you take to secure containers on AWS should also protect applications across the full CI/CD pipeline and into production. To achieve the defense-in-depth required to reliably protect container and Kubernetes environments, security must extend throughout the application lifecycle, from initial vulnerability and compliance scans to robust admission controls and automated security at runtime.
Here’s a closer examination of each area of enterprise responsibility from a container and Kubernetes security perspective:
1) Customer Data
Enterprises using AWS remain solely responsible for the data they utilize, whether in transit or at rest. Appropriate data security strategies for achieving defense-in-depth include encryption, network firewalls, inspection measures, and runtime security. For example, deep packet inspection can closely monitor container traffic to provide data loss prevention (DLP), detecting and blocking the transfer of personally identifiable information (PII), credit card data, and other sensitive information. Identity and access management and application security are also crucial for restricting data access to only those authorized.
2) Platforms
Kubernetes and other orchestration platforms are attack surfaces in their own right — and must be defended. Enterprises running Kubernetes on EC2 instances must have monitoring and security safeguards in place. If using an AWS service for orchestration such as EKS or ECS, enterprises must secure all worker node components, including application and system containers. AWS takes responsibility for securing master nodes and critical system containers, for example, the Kubernetes api-server. To best meet their responsibilities, enterprises should implement robust monitoring of platform system containers, vulnerability scanning, and auditing of platform configurations using tools such as the CIS Benchmarks.
3) Applications
Containerized applications are vulnerable to exploits, zero-day attacks, SQL injection (and other application-layer attacks), embedded malware, and other dangerous threats that enterprises are themselves are responsible for overcoming. If an attack succeeds, the end result can be a data breach, critical application failure, or an open door to attacks on additional enterprise assets. Introducing runtime security that automatically defines and enforces appropriate container behaviors for each application offers enterprises a powerful method for meeting these threats.
4) Identity and Access Management (IAM)
Implementing robust identity and access management, including role-based access controls (RBACs), neutralizes the risk of insider attacks upon critical AWS resources. Correctly configured RBACs can similarly protect Kubernetes or other orchestration platforms, as well as essential tools. As a best practice, integrate RBACs and security tools within the overall identity and access management architecture. Also important here: perform compliance checks and regular reviews of AWS roles and permissions.
5) Operating System, Network, and Firewall Configuration
Enterprises are responsible for cutting off attack opportunities by correctly configuring and regularly auditing OS, network, and firewall security protections. Again, compliance checks such as the CIS Benchmarks for Kubernetes and other orchestrators can verify correct configurations, as can customized container and host checks. Host OS monitoring and vulnerability scanning will guard against OS exploits as well. Note that enterprises must carefully configure both AWS-provided security groups and any other firewalls they have in place to safeguard both external and internal container environment connectivity.
6) Client and Server-side Data Encryption, Data Integrity, and Authentication
Enterprises should enforce encryption of data at rest, and encrypt connections for all communication between clients and servers. These measures safeguard against data breaches, and are mandated by certain regulations (such as PCI-DSS). You’ll also need to protect data integrity by securing container software images as carefully as data itself. Authentication security mostly concerns client access to applications, such as may be provided by externally-facing containers. Authenticated access to microservices should also be enforced as appropriate.
7) Network Traffic Protection and Segmentation
As you undoubtedly are seeing in more and more headlines, container and Kubernetes networks are prized targets for attackers, who gain access to enterprise data and opportunities to escalate attacks after an initial intrusion. Securing network traffic is essential to preventing such attacks from succeeding. Security strategies able to prevent traditional network threats (such as DDoS attacks, SQL injection, or DNS tunneling) should be paired with capabilities designed to protect highly dynamic container environments. Network segmentation, packet capture, and deep packet inspection enable automated protections that keep pace and block any suspicious or unauthorized containers or connections, defeating attacks before they become dangerous. Remember too that traditional network approaches are blind to east-west traffic and cannot enforce egress and ingress rules effectively, so specialized security for containers is imperative.
The Takeaway
Enterprises operating container and Kubernetes environments in AWS must consider the runtime security, security automation, and compliance and auditing measures their applications require, and take the initiative in implementing these safeguards effectively. By clearly understanding your responsibilities under the AWS Shared Responsibility Model, your enterprise can benefit from robust protections and eliminate any oversights in your overall container and Kubernetes security strategy.