Guide to the Secure Configuration of Amazon Elastic Kubernetes Service

with profile CIS Amazon Elastic Kubernetes Service Benchmark - Platform
This profile defines a baseline that aligns to the Center for Internet Security® Amazon Elastic Kubernetes Service (EKS) Benchmark™, V1.0.1. This profile includes Center for Internet Security® Amazon Elastic Kubernetes Service (EKS)™ content. This profile is applicable to EKS 1.21 and greater.
This guide presents a catalog of security-relevant configuration settings for Amazon Elastic Kubernetes Service. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the scap-security-guide package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The NIST National Checklist Program (NCP), which provides required settings for the United States Government, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Profile Information

Profile TitleCIS Amazon Elastic Kubernetes Service Benchmark - Platform
Profile IDxccdf_org.ssgproject.content_profile_cis

CPE Platforms

  • cpe:/a:amazon:elastic_kubernetes_service:1
  • cpe:/o:amazon:elastic_kubernetes_service_node:1
  • cpe:/a:amazon:elastic_kubernetes_service_node:1.21

Revision History

Current version: 0.1.60

  • draft (as of 2022-01-27)

Table of Contents

  1. OpenShift Settings
    1. Network Configuration and Firewalls

Checklist

Group   Guide to the Secure Configuration of Amazon Elastic Kubernetes Service   Group contains 2 groups and 1 rule
Group   OpenShift Settings   Group contains 1 group and 1 rule
[ref]   Each section of this configuration guide includes information about the default configuration of an OpenShift cluster and a set of recommendations for hardening the configuration. For each hardening recommendation, information on how to implement the control and/or how to verify or audit the control is provided. In some cases, remediation information is also provided. Many of the settings in the hardening guide are in place by default. The audit information for these settings is provided in order to verify that the cluster admininstrator has not made changes that would be less secure than the OpenShift defaults. A small number of items require configuration. Finally, there are some recommendations that require decisions by the system operator, such as audit log size, retention, and related settings.
Group   Network Configuration and Firewalls   Group contains 1 rule
[ref]   Most systems must be connected to a network of some sort, and this brings with it the substantial risk of network attack. This section discusses the security impact of decisions about networking which must be made when configuring a system.

This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks.

Rule   Ensure that application Namespaces have Network Policies defined.   [ref]

Use network policies to isolate traffic in your cluster network.
Warning:  This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:
  • /apis/networking.k8s.io/v1/networkpolicies?limit=500 API endpoint, filter with with the jq utility using the following filter [.items[] | select((.metadata.namespace | startswith("openshift") | not) and (.metadata.namespace | startswith("kube-") | not) and .metadata.namespace != "default") | .metadata.namespace] | unique and persist it to the local /kubernetes-api-resources/apis/networking.k8s.io/v1/networkpolicies?limit=500#be3bc6bd210beadc30340bb284c1c9e025ba99d36211737f8315a322a59e7ad3 file.
  • /api/v1/namespaces?limit=500 API endpoint, filter with with the jq utility using the following filter [.items[] | select((.metadata.name | startswith("openshift") | not) and (.metadata.name | startswith("kube-") | not) and .metadata.name != "default")] and persist it to the local /kubernetes-api-resources/api/v1/namespaces?limit=500#fd5b5e88df0104bbaa6307578a6470079073f3977e798271b22b11999d94be52 file.
Rationale:
Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_configure_network_policies_namespaces
Identifiers and References

References:  CIP-003-8 R4, CIP-003-8 R4.2, CIP-003-8 R5, CIP-003-8 R6, CIP-004-6 R2.2.4, CIP-004-6 R3, CIP-007-3 R2, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R6.1, AC-4, AC-4(21), CA-3(5), CM-6, CM-6(1), CM-7, CM-7(1), SC-7, SC-7(3), SC-7(5), SC-7(8), SC-7(12), SC-7(13), SC-7(18), Req-1.1.4, Req-1.2, Req-1.2.1, Req-1.3.1, Req-1.3.2, Req-2.2, SRG-APP-000038-CTR-000105, SRG-APP-000039-CTR-000110, SRG-APP-000141-CTR-000315, SRG-APP-000141-CTR-000320, SRG-APP-000142-CTR-000325, SRG-APP-000142-CTR-000330, SRG-APP-000516-CTR-001325, SRG-APP-000516-CTR-001330, SRG-APP-000516-CTR-001335, SRG-APP-000645-CTR-001410, 4.3.2

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.