Lesson 02 — CIS Kubernetes Benchmark

Learning Objectives

By the end of this lesson, you will be able to:

Explain the purpose of the CIS Kubernetes Benchmark
Understand how CIS recommendations are organised
Distinguish between Level 1 and Level 2 controls
Identify the Kubernetes components assessed by CIS
Understand automated and manual benchmark checks
Apply CIS guidance to Amazon EKS environments
Interpret benchmark assessment results
Build an enterprise remediation and exception process
Integrate CIS assessments into continuous compliance workflows

Why This Matters

Kubernetes contains many security-sensitive configuration options.

A single insecure setting can expose:

The Kubernetes API
Cluster credentials
Secrets
Worker nodes
Service Accounts
Production workloads
Internal network traffic
Administrative functions

Cloud Security Engineers need a consistent way to determine whether these settings are securely configured.

The CIS Kubernetes Benchmark provides a structured collection of prescriptive security recommendations for Kubernetes components.

It helps organisations move from general questions such as:

Is our Kubernetes cluster secure?

to specific, testable questions such as:

Is anonymous authentication disabled?
Is audit logging enabled?
Is access to etcd restricted?
Are kubelet permissions secured?
Are privileged workloads controlled?
Are Service Account tokens managed appropriately?

This makes the CIS Benchmark valuable for hardening, compliance validation and security governance.

What is CIS?

CIS stands for the Center for Internet Security.

CIS publishes security guidance for technologies including:

Operating systems
Cloud platforms
Databases
Network devices
Container platforms
Kubernetes

CIS Benchmarks are developed through a community consensus process involving security professionals, technology vendors and subject-matter experts.

The recommendations are designed to provide practical, measurable configuration guidance.

What is the CIS Kubernetes Benchmark?

The CIS Kubernetes Benchmark is a set of security recommendations used to assess Kubernetes components and cluster configurations.

It provides guidance for areas such as:

Control plane security
etcd security
API Server configuration
Controller Manager configuration
Scheduler configuration
Worker node security
Kubelet configuration
Kubernetes policies
RBAC
Secrets
Network Policies
Admission controls

Each recommendation generally includes:

A control identifier
A security recommendation
A rationale
An audit procedure
A remediation procedure
A default value
An applicability profile

CIS Benchmark Structure

A CIS recommendation commonly contains the following elements.

Element	Purpose
Control ID	Uniquely identifies the recommendation
Title	Describes the security requirement
Profile	Indicates Level 1 or Level 2 applicability
Assessment Status	Automated or manual
Description	Explains the required configuration
Rationale	Explains the security importance
Impact	Describes potential operational consequences
Audit	Provides validation steps
Remediation	Provides corrective actions
Default Value	Documents the default behaviour
References	Links the control to supporting guidance

This structure enables assessments to remain repeatable and auditable.

Benchmark Profiles

CIS commonly categorises controls into two profiles.

Level 1

Level 1 recommendations are intended to:

Provide practical security improvements
Reduce common attack paths
Minimise operational disruption
Be suitable for most environments

Typical Level 1 controls may address:

Restricting anonymous access
Enabling audit logging
Protecting administrative configuration files
Applying least privilege
Limiting insecure kubelet access

Level 1 is usually the starting point for enterprise Kubernetes hardening.

Level 2

Level 2 recommendations provide stronger security but may:

Require additional operational effort
Affect compatibility
Introduce stricter restrictions
Require application or architecture changes

Level 2 may be more appropriate for:

Highly regulated systems
Financial environments
Healthcare platforms
Critical infrastructure
Sensitive production workloads

Organisations should evaluate Level 2 controls through testing and formal change management.

Level 1 and Level 2 Comparison

Profile	Security Strength	Operational Impact	Typical Use
Level 1	Strong baseline	Lower	Most enterprise clusters
Level 2	Enhanced hardening	Higher	High-risk or regulated clusters

Level 2 should not automatically be applied without understanding the operational consequences.

Automated and Manual Controls

CIS controls may be assessed automatically or manually.

Automated Controls

Automated controls can be evaluated using scripts or security tools.

Examples include checking:

File permissions
Process arguments
Configuration flags
Authentication settings
Logging configuration
Kubelet settings

Automated checks improve speed and consistency.

Manual Controls

Manual controls require human review because the result depends on:

Organisational intent
Workload context
Architecture
Policy design
Business risk
Cloud-provider implementation

Examples may include evaluating:

Whether RBAC permissions are appropriate
Whether Network Policies meet segmentation requirements
Whether Secrets management is sufficient
Whether privileged access is justified
Whether audit retention meets policy requirements

A successful CIS assessment requires both technical scanning and expert review.

Major Benchmark Sections

The exact benchmark structure may vary by Kubernetes version and distribution, but common assessment areas include:

CIS Kubernetes Benchmark

├── Control Plane Components
│   ├── API Server
│   ├── Scheduler
│   ├── Controller Manager
│   └── Configuration Files
│
├── etcd
│   ├── Access Control
│   ├── TLS
│   └── Data Protection
│
├── Worker Nodes
│   ├── Kubelet
│   ├── Configuration Files
│   └── Authentication
│
└── Kubernetes Policies
    ├── RBAC
    ├── Service Accounts
    ├── Secrets
    ├── Network Policies
    └── Workload Restrictions

Control Plane Security

The Kubernetes control plane manages the entire cluster.

It includes:

kube-apiserver
kube-controller-manager
kube-scheduler
etcd

A compromise of the control plane can result in complete cluster compromise.

Typical CIS control plane checks include:

Restricting insecure API Server settings
Enforcing secure authentication
Configuring authorisation
Enabling audit logging
Protecting configuration files
Securing TLS communication
Restricting administrative access

API Server Controls

The API Server is the primary interface to Kubernetes.

Users and Services

↓

Kubernetes API Server

↓

Authentication

↓

Authorisation

↓

Admission Control

↓

Cluster Resources

CIS recommendations may evaluate whether the API Server:

Rejects anonymous requests where not required
Uses approved authorisation modes
Enables audit logging
Protects sensitive request data
Restricts insecure ports
Uses secure TLS configuration
Enables suitable admission controls

An insecure API Server can expose the entire cluster.

etcd Security

etcd stores Kubernetes cluster state, including sensitive configuration data.

Depending on the workload and configuration, etcd may contain:

Secret data
Service Account information
Deployment configurations
ConfigMaps
RBAC definitions
Cluster metadata

Typical controls include:

Restricting etcd access
Enforcing TLS
Protecting certificate files
Encrypting Kubernetes Secrets at rest
Limiting network access
Monitoring administrative activity

Kubernetes API Server

↓

Encrypted TLS Connection

↓

etcd

↓

Encrypted Cluster Data

Direct access to etcd must be tightly controlled.

Controller Manager Security

The Controller Manager runs controllers that regulate cluster state.

CIS guidance may evaluate:

Service Account credential management
Certificate handling
Controller configuration
Secure communication settings
Legacy or insecure configuration options

Incorrect settings may create unnecessary credentials or weaken workload identity security.

Scheduler Security

The Kubernetes Scheduler assigns Pods to worker nodes.

Benchmark checks may assess:

Configuration file permissions
Secure API communication
Authentication and authorisation settings
Profiling endpoint exposure

Although the Scheduler does not directly run workloads, its configuration remains part of the trusted control plane.

Worker Node Security

Worker nodes run application workloads and process container activity.

Typical CIS worker node controls examine:

Kubelet configuration
Configuration file permissions
Certificate permissions
Anonymous authentication
Authorisation mode
Read-only ports
TLS certificate usage
Event and logging configuration

Kubernetes Control Plane

↓

Kubelet

↓

Container Runtime

↓

Pods and Containers

A compromised kubelet can expose containers, logs, credentials and node-level resources.

Kubelet Security

The kubelet is the node agent responsible for managing Pods.

Security checks may assess whether:

Anonymous access is disabled
Webhook authorisation is enabled
Client certificate authentication is configured
Read-only access is restricted
TLS certificates are rotated
Node configuration files have secure permissions
Streaming connections are protected

Weak kubelet security can allow attackers to execute commands, access logs or interact with containers.

Kubernetes Policy Controls

CIS policy controls focus on how workloads and users interact with the cluster.

Common topics include:

RBAC
Service Accounts
Secrets
Pod security
Network Policies
Namespace isolation
Admission controls
Privileged containers
Host namespace access
Linux capabilities

These controls frequently require manual assessment because secure implementation depends on workload context.

Example CIS Assessment Findings

Control Area	Example Finding	Risk
Authentication	Anonymous access permitted	Critical
Authorisation	Broad cluster-admin assignments	High
Audit	Audit logging disabled	High
Node Security	Kubelet anonymous authentication enabled	High
Workload Security	Privileged containers allowed	High
Secrets	Encryption at rest not configured	High
Networking	No Network Policies	Medium
Service Accounts	Default token automatically mounted	Medium

Amazon EKS Shared Responsibility

Amazon EKS is a managed Kubernetes service.

AWS manages several control plane responsibilities, while customers manage cluster and workload security.

AWS Responsibility

├── Managed Control Plane Infrastructure
├── Control Plane Availability
├── Control Plane Patching
└── Managed Service Operations

Customer Responsibility

├── IAM and RBAC
├── Control Plane Logging
├── Secrets Encryption Configuration
├── Worker Nodes
├── Workloads
├── Network Policies
├── Admission Policies
├── Runtime Security
└── Monitoring and Compliance

This shared responsibility model affects how CIS controls are assessed.

CIS Benchmark in Amazon EKS

Some traditional Kubernetes controls cannot be directly inspected or changed in EKS because AWS manages the control plane.

For example, customers may not have direct access to:

Control plane host files
etcd hosts
API Server startup arguments
Scheduler host configuration
Controller Manager host configuration

Therefore, organisations should use an EKS-specific benchmark or applicability guidance rather than treating EKS as a self-managed Kubernetes cluster.

The assessment should distinguish between:

AWS-managed controls
Customer-configurable controls
Shared controls
Not-applicable controls
Controls requiring compensating evidence

EKS Assessment Areas

For Amazon EKS, important customer-controlled areas include:

EKS control plane logging
IAM authentication
Kubernetes RBAC
EKS access entries
Secrets encryption
VPC and Security Group configuration
Managed node group security
Kubelet configuration on self-managed nodes
Pod Security Admission
Network Policies
Admission controllers and policy engines
Runtime detection
Image security
Audit and compliance reporting

Example Amazon EKS Architecture

AWS-Managed EKS Control Plane
        │
        │ Secure Kubernetes API
        ▼
Customer AWS Account
        │
        ├── IAM Identities
        ├── EKS Access Entries
        ├── Kubernetes RBAC
        ├── Managed Node Groups
        ├── Fargate Profiles
        ├── Network Policies
        ├── Pod Security Admission
        ├── OPA Gatekeeper or Kyverno
        └── Logging and Monitoring

The CIS assessment must correctly map each control to the responsible party.

Benchmark Assessment Tools

Organisations may use several tools to support CIS assessments.

Common categories include:

Command-line benchmark scanners
Cloud security posture management platforms
Kubernetes security platforms
Policy engines
Configuration management tools
SIEM and compliance dashboards

A commonly used open-source tool is kube-bench.

It evaluates Kubernetes configuration against CIS-style checks where technical access permits.

Example command:

kube-bench run

A targeted assessment may use:

kube-bench run --targets node

Tool results must still be reviewed by an engineer because:

Some checks may not apply
Managed services expose limited configuration
False positives may occur
Manual controls remain
Business context affects risk

Example kube-bench Result

[INFO] 4 Worker Node Security Configuration

[PASS] 4.1.1 Ensure kubelet service file permissions are configured
[FAIL] 4.2.1 Ensure anonymous authentication is disabled
[WARN] 4.2.10 Ensure eventRecordQPS is configured appropriately

Result categories commonly include:

Result	Meaning
PASS	The configuration meets the tested recommendation
FAIL	The configuration does not meet the recommendation
WARN	Manual review or additional validation is required
INFO	Informational assessment detail

A PASS does not guarantee the entire cluster is secure.

CIS Assessment Workflow

Select Applicable Benchmark

↓

Define Scope

↓

Collect Technical Evidence

↓

Run Automated Checks

↓

Perform Manual Reviews

↓

Validate Applicability

↓

Assign Risk

↓

Create Remediation Plan

↓

Approve Exceptions

↓

Retest

↓

Publish Compliance Report

Selecting the Correct Benchmark

Before beginning an assessment, confirm:

Kubernetes version
Kubernetes distribution
Cloud platform
Managed or self-managed control plane
Worker node type
Container runtime
Regulatory requirements

Using the wrong benchmark version may produce inaccurate findings.

For example, a self-managed Kubernetes control may not be applicable to an AWS-managed EKS control plane.

Evidence Collection

Evidence should be repeatable and auditable.

Examples include:

EKS cluster configuration exports
AWS CLI command outputs
Kubernetes manifests
RBAC reports
Network Policy inventories
Audit logging configuration
KMS configuration
Node configuration
Security platform reports
Screenshots or dashboard exports
Approved security exceptions

Evidence must include:

Collection date
Cluster name
AWS account
Region
Environment
Benchmark version
Assessor
Tool version

Risk-Based Remediation

Not every failed control should be treated equally.

A remediation process should consider:

Control Failure

↓

Technical Severity

↓

Workload Criticality

↓

Threat Exposure

↓

Compliance Requirement

↓

Compensating Controls

↓

Business Priority

↓

Remediation Deadline

Example prioritisation:

Finding	Environment	Priority
Anonymous API access	Production	Critical
Excessive cluster-admin access	Production	Critical
Audit logging disabled	Production	High
Missing Network Policy	Development	Medium
Non-standard logging retention	Sandbox	Low

Enterprise Exception Management

Some CIS recommendations may not be immediately implementable.

An approved exception should include:

Control identifier
Affected clusters
Business justification
Security risk
Compensating controls
Control owner
Approver
Expiry date
Remediation plan
Review date

Failed Control

↓

Technical Review

↓

Can It Be Remediated?

├── Yes → Remediation Plan
└── No  → Formal Exception

↓

Compensating Controls

↓

Risk Approval

↓

Expiry and Review

Permanent, undocumented exceptions create long-term security risk.

Continuous CIS Compliance

A mature organisation does not perform CIS assessments only before an audit.

Continuous compliance integrates benchmark controls into:

Infrastructure as Code
CI/CD pipelines
Cluster provisioning
Policy engines
Security monitoring
Configuration drift detection
Compliance dashboards
Periodic reassessments

Infrastructure as Code

↓

Secure EKS Baseline

↓

Automated Policy Validation

↓

Cluster Deployment

↓

Continuous Benchmark Assessment

↓

Compliance Dashboard

↓

Remediation Workflow

Policy Enforcement

CIS recommendations can be translated into enforceable Kubernetes policies.

Examples include:

Deny privileged containers
Require non-root execution
Disallow host networking
Require resource limits
Restrict hostPath volumes
Require approved registries
Require Network Policies
Disable automatic Service Account token mounting

Policy tools may include:

Pod Security Admission
OPA Gatekeeper
Kyverno
CI/CD admission checks

Assessment identifies non-compliance, while policy enforcement helps prevent it.

Enterprise Monitoring

CIS compliance should be monitored centrally.

An enterprise dashboard may include:

Metric	Target
Production clusters assessed	100%
Critical controls passed	100%
High-risk findings remediated within SLA	95% or greater
Expired exceptions	0
Benchmark version coverage	100%
Configuration drift alerts investigated	100%

Useful monitoring areas include:

CIS pass percentage
Critical failures
Findings by AWS account
Findings by region
Findings by environment
Exception expiry
Remediation ageing
Repeated control failures

Enterprise Implementation Strategy

Phase 1 — Define the Baseline

Select the approved CIS benchmark
Identify applicable controls
Define Level 1 requirements
Identify Level 2 requirements for high-risk systems
Document managed-service exceptions

Phase 2 — Assess Existing Clusters

Inventory all EKS clusters
Collect cluster metadata
Run automated assessments
Perform manual reviews
Identify critical gaps

Phase 3 — Remediate High-Risk Findings

Address identity and access weaknesses
Enable control plane logging
Restrict privileged workloads
Configure Secrets encryption
Strengthen node security
Implement Network Policies

Phase 4 — Automate Secure Provisioning

Build benchmark requirements into Terraform or CloudFormation
Standardise EKS cluster modules
Apply policy-as-code
Validate configuration in CI/CD
Prevent insecure deployments

Phase 5 — Establish Continuous Compliance

Schedule recurring assessments
Detect configuration drift
Track findings centrally
Manage exceptions
Report compliance to leadership

Common Challenges

Managed Control Plane Limitations

EKS customers cannot inspect every control plane setting.

Response: Use EKS-specific guidance and AWS evidence for managed controls.

Benchmark Version Mismatch

Using an outdated benchmark may create inaccurate results.

Response: Align the benchmark with the deployed Kubernetes and EKS versions.

False Positives

Automated tools may report failures for controls that do not apply.

Response: Validate each result before assigning remediation.

Operational Impact

A secure setting may disrupt applications.

Response: Test changes in non-production environments and use controlled rollout plans.

Configuration Drift

Clusters may become non-compliant after deployment.

Response: Implement continuous assessment and policy enforcement.

Exception Accumulation

Temporary exceptions may become permanent.

Response: Require expiry dates, ownership and periodic review.

Enterprise Best Practices

As a Cloud Security Engineer:

Use the CIS benchmark version appropriate to the Kubernetes distribution.
Prefer EKS-specific applicability guidance for managed clusters.
Adopt Level 1 as the minimum enterprise baseline.
Evaluate Level 2 controls for regulated and high-risk workloads.
Combine automated scans with manual validation.
Record evidence for every assessed control.
Prioritise identity, API access, Secrets and privileged workload findings.
Integrate benchmark controls into Infrastructure as Code.
Use policy-as-code to prevent recurring violations.
Track exceptions with expiry dates and formal approval.
Reassess clusters after upgrades and major configuration changes.
Report benchmark compliance through central dashboards.
Never treat a benchmark score as proof that the cluster is completely secure.

Real-World Scenario

A financial services organisation operates Amazon EKS clusters across multiple AWS accounts.

An external audit identifies inconsistent security practices:

Some clusters do not have control plane logging enabled.
Several teams assign cluster-admin access too broadly.
Production namespaces permit privileged containers.
Network Policies are missing from sensitive workloads.
Benchmark scans use different versions across teams.

The Cloud Security team launches an enterprise CIS compliance programme.

The organisation:

Selects an approved EKS-aligned CIS baseline.
Establishes Level 1 as the minimum standard.
Applies additional Level 2 controls to payment environments.
Runs automated assessments across all clusters.
Performs manual reviews for RBAC and network segmentation.
Creates remediation tickets for failed controls.
Introduces Gatekeeper policies to prevent privileged workloads.
Tracks exceptions through a formal risk process.
Publishes compliance results to an executive dashboard.

Within two assessment cycles, the organisation significantly reduces critical findings and improves audit readiness.

Key Takeaways

The CIS Kubernetes Benchmark provides prescriptive and measurable security recommendations.
Level 1 provides a practical enterprise baseline, while Level 2 provides stronger hardening.
Automated checks improve scale, but manual assessment remains essential.
Amazon EKS requires an assessment approach that recognises the AWS shared responsibility model.
Benchmark findings must be validated, prioritised and remediated based on risk.
Policy-as-code and continuous assessment help prevent configuration drift.
A high CIS score supports security assurance but does not replace comprehensive Kubernetes security engineering.

Knowledge Check

1. What is the primary purpose of the CIS Kubernetes Benchmark?

Answer: To provide prescriptive security recommendations for assessing and hardening Kubernetes configurations.

2. What is the main difference between Level 1 and Level 2 controls?

Answer: Level 1 provides practical baseline security with lower operational impact, while Level 2 applies stronger hardening that may require more testing and operational change.

3. Why can CIS assessments differ between self-managed Kubernetes and Amazon EKS?

Answer: AWS manages the EKS control plane, so customers cannot directly inspect or modify some control plane settings assessed in a self-managed Kubernetes environment.

4. Why should automated benchmark results be manually reviewed?

Answer: Some controls may be not applicable, affected by managed-service architecture, produce false positives or require business context.

5. What information should be included in a CIS exception?

Answer: The control identifier, business justification, affected resources, risk, compensating controls, owner, approval, expiry date and remediation plan.

What’s Next?

In the next lesson, we will examine the NSA Kubernetes Hardening Guide and understand how its defensive recommendations complement CIS controls through stronger workload isolation, identity security, network protection and threat detection.

➡️ Next Lesson: Lesson 03 — NSA Hardening Guide