STIGQter: STIG Summary: Mirantis Kubernetes Engine Security Technical Implementation Guide Version: 2 Release: 1 Benchmark Date: 24 Jul 2024:

MKE must preserve any information necessary to determine the cause of the disruption or failure.

DISA Rule

SV-260932r966153_rule

Vulnerability Number

V-260932

Group Title

SRG-APP-000226-CTR-000575

Rule Version

CNTR-MK-000980

Severity

CAT II

CCI(s)

• CCI-001665 - Preserve organization-defined system state information in the event of a system failure.

Weight

10

Fix Recommendation

When using Swarm orchestration, this check is Not Applicable.

This is a catastrophic error, contact Mirantis support.

Check Contents

When using Swarm orchestration, this check is Not Applicable.

Review the Kubernetes configuration to determine if information necessary to determine the cause of a disruption or failure is preserved.

Notes:
- The ReadWriteOnce access mode in the PVC means the volume can be mounted as read-write by a single node. Ensure the storage backend supports this mode.
- Adjust the sleep duration in the writer pod as needed.
- Ensure that the namespace and PVC names match the setup.

Steps to verify data durability:
1. Create a namespace to manage the testing:

apiVersion: v1
kind: Namespace
metadata:
name: stig

2. PersistentVolumeClaim (PVC):
Ensure a PVC is created. If using a storage class like Longhorn, it would look similar to:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: stig-pvc
namespace: stig
spec:
accessModes:
- ReadWriteOnce
storageClassName: longhorn # Replace with your storage class if different, e.g. NFS
resources:
requests:
storage: 5Gi

3. Deploying the Initial Pod:
Create a pod that writes data to the PVC. This pod will use a simple loop to write data (e.g., timestamps) to a file on the mounted PVC. Example:

apiVersion: v1
kind: Pod
metadata:
name: write-pod
namespace: stig
spec:
volumes:
- name: log-storage
persistentVolumeClaim:
claimName: stig-pvc
containers:
- name: writer
image: busybox
command: ["/bin/sh", "-c"]
args: ["while true; do date >> /data/logs.log; sleep 10; done"]
volumeMounts:
- name: log-storage
mountPath: /data

4. Simulate Pod Failure:
After the pod has been writing data for some time, it can be deleted to simulate a failure by executing the following:

kubectl delete pod write-pod -n stig

5. Deploying a New Pod to Verify Data:
Deploy another pod that mounts the same PVC to verify that the data is still there.

apiVersion: v1
kind: Pod
metadata:
name: read-pod
namespace: stig
spec:
volumes:
- name: log-storage
persistentVolumeClaim:
claimName: stig-pvc
containers:
- name: reader
image: busybox
command: ["/bin/sh", "-c"]
args: ["sleep infinity"]
volumeMounts:
- name: log-storage
mountPath: /data

6. Verify Data Persistence:
Check the contents of the log file in the new pod to ensure that the data written by the first pod is still there by executing the following:

kubectl exec read-pod -n stig -- cat /data/logs.log

If there is no log data, this is a finding.

Vulnerability Number

V-260932

Documentable

False

Rule Version

CNTR-MK-000980

Severity Override Guidance

When using Swarm orchestration, this check is Not Applicable.

Review the Kubernetes configuration to determine if information necessary to determine the cause of a disruption or failure is preserved.

Notes:
- The ReadWriteOnce access mode in the PVC means the volume can be mounted as read-write by a single node. Ensure the storage backend supports this mode.
- Adjust the sleep duration in the writer pod as needed.
- Ensure that the namespace and PVC names match the setup.

Steps to verify data durability:
1. Create a namespace to manage the testing:

apiVersion: v1
kind: Namespace
metadata:
name: stig

2. PersistentVolumeClaim (PVC):
Ensure a PVC is created. If using a storage class like Longhorn, it would look similar to:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: stig-pvc
namespace: stig
spec:
accessModes:
- ReadWriteOnce
storageClassName: longhorn # Replace with your storage class if different, e.g. NFS
resources:
requests:
storage: 5Gi

3. Deploying the Initial Pod:
Create a pod that writes data to the PVC. This pod will use a simple loop to write data (e.g., timestamps) to a file on the mounted PVC. Example:

apiVersion: v1
kind: Pod
metadata:
name: write-pod
namespace: stig
spec:
volumes:
- name: log-storage
persistentVolumeClaim:
claimName: stig-pvc
containers:
- name: writer
image: busybox
command: ["/bin/sh", "-c"]
args: ["while true; do date >> /data/logs.log; sleep 10; done"]
volumeMounts:
- name: log-storage
mountPath: /data

4. Simulate Pod Failure:
After the pod has been writing data for some time, it can be deleted to simulate a failure by executing the following:

kubectl delete pod write-pod -n stig

5. Deploying a New Pod to Verify Data:
Deploy another pod that mounts the same PVC to verify that the data is still there.

apiVersion: v1
kind: Pod
metadata:
name: read-pod
namespace: stig
spec:
volumes:
- name: log-storage
persistentVolumeClaim:
claimName: stig-pvc
containers:
- name: reader
image: busybox
command: ["/bin/sh", "-c"]
args: ["sleep infinity"]
volumeMounts:
- name: log-storage
mountPath: /data

6. Verify Data Persistence:
Check the contents of the log file in the new pod to ensure that the data written by the first pod is still there by executing the following:

kubectl exec read-pod -n stig -- cat /data/logs.log

If there is no log data, this is a finding.

Check Content Reference

M

Target Key

5595