Mirantis Kubernetes Engine STIG

Mirantis Kubernetes Engine Security Technical Implementation Guide

The Mirantis Kubernetes Engine Security Technical Implementation Guide (V2 R1) has 44 STIG checks. New to STIG checklists? Read What is a STIG checklist?, CKL vs CKLB, and STIG vs SCAP benchmark.

Find STIG checks

44STIG checks

Search filters this STIG's checks locally. Separate terms must all match (use quotes for an exact phrase). A search you ran on the Search page carries over here.

Severity

Version

V2 · R1

CurrentPublished Wed Jul 24 2024

CPU priority must be set appropriately on all containers.

Mirantis Kubernetes Engine Security Technical Implementation Guide

Assessment Title

Rule Text

CPU priority must be set appropriately on all containers.

Description

Discussion Text

All containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as CPU shares, the user controls the host CPU resources that a container may consume.

By default, CPU time is divided between containers equally. If CPU shares are not properly set, the container process may have to starve if the resources on the host are not available. If the CPU resources on the host are free, CPU shares do not place any restrictions on the CPU that the container may use.

New to STIG checklists? Read What is a STIG checklist? and CKL vs CKLB.

Objective

V-260925

Rule

SV-260925r966132_rule

Severity

medium

Rule Version

CNTR-MK-000590

Documentable

false

IA Controls

NIST SP 800-53

Rev 5

Assessment Procedure

Check Text

Ensure Resource Quotas and CPU priority is set for each namespace.

When using Kubernetes orchestration:
Log in to the MKE web UI, navigate to Kubernetes >> Namespace, and then click on each defined Namespace.

If the Namespace states "Quotas Nothing has been defined for this resource." or the limits.cpu or the limits.memory settings do not match the System Security Plan (SSP), this is a finding.

When using Swarm orchestration:
1. Check Resource Quotas:

Linux: As an administrator, execute the following command using a Universal Control Plane (MKE) client bundle:

docker ps --quiet --filter """"label=com.docker.ucp.version""""  | xargs docker inspect --format '{{ .Name }}: Memory={{ .HostConfig.Memory }}'

If the above command returns "0", it means the memory limits are not in place, and this is a finding.

2. Check CPU Priority:
When using Swarm orchestration, to ensure CPU priority is set, use the CLI:

Linux: As an MKE Admin, execute the following command using a Universal Control Plane (MKE) client bundle:

docker ps --quiet --filter ""label=com.docker.ucp.version"" | xargs docker inspect --format '{{ .Name }}: CpuShares={{ .HostConfig.CpuShares }}'

Compare the output against the SSP, if any containers are set to "0" or "1024", and they are not documented in the System Security Plan (SSP), this is a finding.

Implementation Procedure

Fix Text

Set Resource Quotas and CPU priority for each namespace.

When using Kubernetes orchestration:

1. Create a resource quota as follows (quotaexample.yaml):

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: ""1""
    requests.memory: 1Gi
    limits.cpu: ""2""
    limits.memory: 2Gi
Where the limits can be set according to the SSP.

Save this file.

2. Apply the quota to a namespace within the cluster by executing:

kubectl apply -f [full path to quotaexample.yaml] --namespace=[name of namespace on cluster]

This must be repeated for all namespaces. Quotas can differ per namespace as required by the site.

When using Swarm orchestration:

1. Set Resource Quotas by executing the following:

docker exec -it [container name] --memory=""""2g""""

This must be repeated for all containers. Quotas can differ per container as required by the site.

2. Set CPU Priority:

When using Swarm orchestration to manage the CPU shares between containers, start the container using the --cpu-shares argument.

For example, run a container as below:

docker run --interactive --tty --cpu-shares 512 [image] [command]

In the above example, the container is started with CPU shares of 50 percent of what the other containers use. So, if the other container has CPU shares of 80 percent, this container will have CPU shares of 40 percent.

Note: Every new container will have 1024 shares of CPU by default. However, this value is shown as "0" if running the command mentioned in the audit section.

Alternatively:
1. Navigate to /sys/fs/cgroup/cpu/system.slice/ directory.

2. Check the container instance ID using docker ps.

3. Inside the above directory (in step 1), there will be a directory called docker-<Instance ID>.scope. For example, docker-4acae729e8659c6be696ee35b2237cc1fe4edd2672e9186434c5116e1a6fbed6.scope. Navigate to this directory.

4. Find a file named cpu.shares. Execute cat cpu.shares. This will always show the CPU share value based on the system. Even if there are no CPU shares configured using -c or --cpu-shares argument in the docker run command, this file will have a value of 1024.

By setting one containers CPU shares to 512, it will receive half of the CPU time compared to the other container. Take 1024 as 100 percent and derive the number that set for respective CPU shares. For example, use 512 to set 50 percent and 256 to set 25 percent.

STIG check 23 of 44 in the Mirantis Kubernetes Engine STIG checklist

← Previous · V-260924Incoming container traffic must be bound to a specific host interface.Next · V-260926 →MKE must use a non-AUFS storage driver.