Code Monkey home page Code Monkey logo

eks-cis-cluster-baseline's Introduction

eks-cis-cluster-baseline

InSpec profile to validate the secure configuration of AWS EKS, against Cluster requirements under CIS's CIS Amazon Elastic Kubernetes Service (EKS) Benchmark version 1.0.1 and 1.3.0*.

*for 4.2.x requirements

The baseline includes tests that must be executed against the Kubernetes API and tests that must be executed against the underlying nodes over SSH. This profile handles only the cluster tests, and is intended to be run alongside the EKS CIS Node Baseline profile.

Getting Started

This profile should be executed from a runner host with network access to the EKS cluster under test. The runner host must have InSpec installed.

For the best security of the runner, always install on the runner the latest version of InSpec and supporting Ruby language components.

Latest versions and installation options are available at the InSpec site.

Dependencies

This profile is executed against an AWS EKS cluster via the Kubernetes API and the AWS CLI. The profile assumes that the runner is authenticated as an AWS role permitted to run the kubectl utility against the cluster and run queries using the aws eks CLI command.

Kubernetes API

The profile makes use of the kubectl utility to access the Kubernetes API. The runner host must have kubectl installed -- see the Kubernetes documentation for tools for details.

A host's connection to the Kubernetes API is established using credentials recorded in the kubeconfig file. For the profile to use the Kubernetes API, the runner host must either have a valid kubeconfig file either in the default location ($HOME/.kube/config) or have designated a file as the kubeconfig file using the $KUBECONFIG environment variable. See the Kubernetes documentation for kubeconfig for details.

You can test if the runner host has access to the Kubernetes API by running kubectl from the command line:

kubectl get nodes

If the command returns a list of information on the EC2 nodes that comprise the cluster, then kubectl is able to support the profile.

AWS CLI

Some controls in the profile require the use of the AWS CLI to investigate the EKS cluster. Ensure the runner host has the AWS CLI installed as per Amazon's instructions.

The runner host must also have assumed a role with sufficient permissions to access the AWS components of the EKS cluster. If running AWS commands results in a permission error, work with your cloud administrator to ensure your role has the correct IAM privileges to access the cluster's components.

To ensure the AWS CLI is installed and configured correctly, use it to print information on the target cluster:

aws eks describe-cluster --name <cluster name> --region <cluster region>

Tailoring to Your Environment

The following inputs may be configured in an inputs ".yml" file for the profile to run correctly for your specific environment. More information about InSpec inputs can be found in the InSpec Profile Documentation.

# Used by the AWS CLI controls. Give the name of the cluster under test
# as a string, ex. "my-test-cluster"
cluster-name:

# Used by the AWS CLI controls. Give the region of the cluster under test
# as a string, ex. "us-east-1"
cluster-region:

# Used by 4.1.1. Give an array of roles which are permitted to hold the
# cluster-admin role.
# If not defined, default is: ["system:admin", "system:masters"]
allowed_cluster_admin_principals:

# Optional -- leave blank if no outside access should be allowed
# IPs from within this array of CIDR blocks should be the only ones allowed to
# access the cluster via k8s API from outside the VPC
# Can be configured via AWS console
# Ex. ["0.0.0.0/0"]
allowlist_cidr_blocks:

Running the Profile

Executing the profile by downloading it to the runner:

git clone https://github.com/mitre/eks-cis-cluster-baseline.git
cd eks-cis-cluster-baseline
inspec exec . --input-file <path_to_your_input_file/name_of_your_input_file.yml> --reporter cli json:node1results.json

Executing the profile by executing it from this GitHub repository:

inspec exec https://github.com/mitre/eks-cis-cluster-baseline/archive/main.tar.gz --input-file <path_to_your_input_file/name_of_your_input_file.yml> --reporter cli json:cluster-results.json

Running This Baseline from a local Archive copy

If your runner is not always expected to have direct access to GitHub, use the following steps to create an archive bundle of this profile and all of its dependent tests:

(Git is required to clone the InSpec profile using the instructions below. Git can be downloaded from the Git site.)

mkdir profiles
cd profiles
git clone https://github.com/mitre/eks-cis-cluster-baseline.git
inspec archive eks-cis-cluster-baseline
sudo inspec exec <archive name> --input-file <path_to_your_input_file/name_of_your_input_file.yml> --reporter cli json:cluster-results.json

For every successive run, follow these steps to always have the latest version of this baseline and dependent profiles:

cd eks-cis-cluster-baseline
git pull
cd ..
inspec archive eks-cis-cluster-baseline --overwrite
sudo inspec exec <archive name> --input-file <path_to_your_input_file/name_of_your_input_file.yml> --reporter cli json:cluster-results.json

Using Heimdall for Viewing the JSON Results

Heimdall Lite 2.0 Demo GIF

The JSON results output file can be loaded into heimdall-lite for a user-interactive, graphical view of the InSpec results.

The JSON InSpec results file may also be loaded into a full heimdall server, allowing for additional functionality such as to store and compare multiple profile runs.

Authors

Special Thanks

Contributing and Getting Help

To report a bug or feature request, please open an issue.

NOTICE

© 2018-2021 The MITRE Corporation.

Approved for Public Release; Distribution Unlimited. Case Number 18-3678.

NOTICE

MITRE hereby grants express written permission to use, reproduce, distribute, modify, and otherwise leverage this software to the extent permitted by the licensed terms provided in the LICENSE.md file included with this project.

NOTICE

This software was produced for the U. S. Government under Contract Number HHSM-500-2012-00008I, and is subject to Federal Acquisition Regulation Clause 52.227-14, Rights in Data-General.

No other use other than that granted to the U. S. Government, or to those acting on behalf of the U. S. Government under that Clause is authorized without the express written permission of The MITRE Corporation.

For further information, please contact The MITRE Corporation, Contracts Management Office, 7515 Colshire Drive, McLean, VA 22102-7539, (703) 983-6000.

NOTICE

CIS Benchmarks are published by the Center for Internet Security (CIS), see: https://www.cisecurity.org/cis-benchmarks/.

eks-cis-cluster-baseline's People

Contributors

ejaronne avatar karikarshivani avatar raziz086 avatar wdower avatar

Stargazers

avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

neatnerdprime

eks-cis-cluster-baseline's Issues

Remove unnecessary check from 5.4.2

For https://github.com/mitre/eks-cis-cluster-baseline/blob/0f075949a612f3a3b9d525c7fa737039969de8a0/controls/eks-cis-5.4.2.rb ,
the CIS benchmark title says "Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled", but the Description says "Disable access to the Kubernetes API from outside the node network if it is not required." outside, as in from the Public side. The author isn't forcing folks to enable private access. They hadn't anticipated that a team might not want to enable private access at all, and just use public access. In fact, enabling private access is less secure. CIS benchmarks tend to drift out of strict security lock-down requirements and (sometimes confusingly) mix in guidance to ensure you can still get things done. So, it isn't a security finding for not enabling private access. The InSpec code should only focus on the Description statement: "Disable access to the Kubernetes API from outside the node network if it is not required.". The first describe block at

eks-cis-cluster-baseline/controls/eks-cis-5.4.2.rb

Lines 46 to 49 in 0f07594

describe 'Private access should be enabled' do
subject { access_restrictions }
its('endpointPrivateAccess') { should be true }
end
is simply not necessary, so I propose it be removed. The other describe blocks focus on either not enabling public access or enabling with restricted access in alignment with the security hardening recommended by the author.

Profile Errors for `4.1.1` and `4.3.2`

I can't access the target to dig deeper into this issue, but there probably needs to be an edge case or a different method to handle the following profile errors:

Screen Shot 2022-12-06 at 12 47 50 PM

Controls missing check and fix text

eks-cis-cluster-baseline/controls/eks-cis-5.1.4.rb

Lines 8 to 9 in 0f07594

desc 'check', ''
desc 'fix', ''

eks-cis-cluster-baseline/controls/eks-cis-5.4.2.rb

Lines 21 to 22 in 0f07594

desc 'check', ''
desc 'fix', ''

eks-cis-cluster-baseline/controls/eks-cis-5.4.3.rb

Lines 8 to 9 in 0f07594

desc 'check', ''
desc 'fix', ''

eks-cis-cluster-baseline/controls/eks-cis-5.4.4.rb

Lines 19 to 20 in 0f07594

desc 'check', ''
desc 'fix', ''

eks-cis-cluster-baseline/controls/eks-cis-5.4.5.rb

Lines 6 to 7 in 0f07594

desc 'check', ''
desc 'fix', ''

Possible automation for 4.1.5

eks-cis-cluster-baseline/controls/eks-cis-4.1.5.rb

Line 54 in 58666ba

describe 'Manual control' do

Possible automation

items =json(command:"kubectl get rolebinding,clusterrolebinding --all-namespaces -o json").params['items']

control "test" do
items.each do |i|
  next if i['subjects'].nil?
  describe "service accounts for clusterrolebinding:#{i['roleRef']['name']}" do
    subject {i['subjects'].map{|x| x['name']}}
    it { should_not include 'default'}
  end
end
end


items =json(command:"kubectl get serviceaccount -A -o json").params['items']

control "test" do
items.each do |i|
  next unless i['metadata']['name'].eql?('default')
  describe "Default service account in namespace:#{i['metadata']['namespace']}" do
    subject {i}
    its(['automountServiceAccountToken']) { should cmp 'false'}
  end
end
end

Please consider if the above model is a cleaner implementation for ur check in 4.1.6 ... although ur current version works fine ...the above might make for better reporting.

`5.4.1` and `5.4.2` Consider adding a test for public access

The guidance states that authorized IP addresses should be added to an allowlist. To me, this sounds like 0.0.0.0/0 should lead to a failed test - even if the user adds it to the allow list - because allowing requests from all IP addresses essentially defeats the purpose of an allowlist.

Maybe we can modify the describe block so that the control doesn't pass if the user just looks at the following output and adds 0.0.0.0/0 to the input:

Screen Shot 2022-12-06 at 1 14 59 PM

actual_allowlist.each do |cidr|
  describe 'Cluster allowlist should match expected allowlist' do
    subject { cidr }
      it { should be_in expected_allowlist }
      it { should_not eq '0.0.0.0/0' } # or something like that
  end
end

I understand if the implication from guidance is insufficient to include a test like this in the control.

Possible automation for eks-cis-4.1.3

eks-cis-cluster-baseline/controls/eks-cis-4.1.3.rb

Line 44 in 58666ba

describe 'Manual control' do 

items =json(command:"kubectl get roles,clusterroles --all-namespaces -o json").params['items']

control "test" do
items.each do |i|
  #next unless i['metadata']['name'].eql?('default')
  describe "apiGroups for Role:#{i['metadata']['name']} namespace:#{i['metadata']['namespace']}" do
    subject {i['rules'].map{|x| x['apiGroups']}.flatten.uniq }
    it { should_not include '*'}
  end
end
end

control "test" do
items.each do |i|
  #next unless i['metadata']['name'].eql?('default')
  describe "resources for Role:#{i['metadata']['name']} namespace:#{i['metadata']['namespace']}" do
    subject {i['rules'].map{|x| x['resources']}.flatten.uniq }
    it { should_not include '*'}
  end
end
end

control "test" do
items.each do |i|
  #next unless i['metadata']['name'].eql?('default')
  describe "verbs for Role:#{i['metadata']['name']} namespace:#{i['metadata']['namespace']}" do
    subject {i['rules'].map{|x| x['verbs']}.flatten.uniq }
    it { should_not include '*'}
  end
end
end

possibly makes sense to have input based exception list for each for which checks could be skipped

set default value of allowlist_cidr_blocks

currently allowlist_cidr_blocks has a null value in inspec.yml

This causes an error when attempting to create a profile json using the inspec json command:

inspec json eks-cis-cluster-baseline
Input 'allowlist_cidr_blocks' with value '' does not validate to type 'Array'.

Please set the default value to [ ] or similar

`4.1.6` Add an allow list for pods that need service account tokens

Based on the description on the CIS control description:

Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API server

We can create an allow list for pods that require service account tokens to communicate with the API server.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.