STIG hardening for Tanzu Kubernetes Grid clusters

You can harden Tanzu Kubernetes Grid (TKG) clusters to be compliant with the Defense the Information Systems Agency Security Technical Implementation Guides (DISA STIG) standards. Hardening your clusters for compliance to STIG standards allows you to achieve an Authorization to Operate (ATO) for your deployment.

How you harden your cluster for STIG compliance depends on whether the cluster is class-based or plan-based.

STIG hardening for TKG management and class-based workload clusters

To create a hardened Tanzu Kubernetes Grid (TKG) management cluster or class-based workload cluster that is compliant with STIG standards, you first update the clusterconfig file and then create the hardened cluster from the updated clusterconfig file.

  1. Update the clusterconfig file to include the required variables and values.

    See Update the TKG clusterconfig to STIG standards.

  2. Create a cluster from the updated clusterconfig file.

    The cluster created from the updated clusterconfig file is hardened to be compliant with STIG standards.

    For information about how to deploy a cluster from a clusterconfig file, see Deploy Management Clusters from a Configuration File and Create Workload Clusters.

Note

You cannot harden an existing TKG cluster.

Update the TKG clusterconfig to STIG standards

You update the TKG clusterconfig file with the necessary variables to create a file that you can use to create a STIG-compliant TKG cluster.

To add the necessary variables to the TKG clusterconfig file, do one of the following:

  • Add the contents of stig.conf to your clusterconfig file.

    OR

  • Export the following variables after setting them in your local environment.

    export ETCD_EXTRA_ARGS="auto-tls=false;peer-auto-tls=false;cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384"
export KUBE_CONTROLLER_MANAGER_EXTRA_ARGS="tls-min-version=VersionTLS12;profiling=false;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384"
export WORKER_KUBELET_EXTRA_ARGS="streaming-connection-idle-timeout=5m;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384;protect-kernel-defaults=true"
export APISERVER_EXTRA_ARGS="tls-min-version=VersionTLS12;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384"
export KUBE_SCHEDULER_EXTRA_ARGS="tls-min-version=VersionTLS12;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384"
export CONTROLPLANE_KUBELET_EXTRA_ARGS="streaming-connection-idle-timeout=5m;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384;protect-kernel-defaults=true"
export ENABLE_AUDIT_LOGGING=true

STIG hardening for TKG plan-based workload clusters

You use ytt overlays to harden plan-based Tanzu Kubernetes Grid (TKG) clusters for compliance with STIG standards. VMware provides several ytt overlays that allow you to harden your TKG clusters to STIG standards.

The following snippet is an example ytt overlay to set tls-min-version (STIG: V-242378) on the api-server.

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match missing_ok=True,by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    clusterConfiguration:
      apiServer:
        extraArgs:
        #@overlay/match missing_ok=True
        tls-min-version: VersionTLS12

You can get more ytt overlays from the VMware dod-compliance-and-automation GitHub repository. These overlays apply to TKG v2.1 and v2.2.

For information on how to customize plan-based TKG clusters using ytt, see Legacy Cluster Configuration with ytt in Tanzu Kubernetes Grid documentation.

You can create legacy clusters by setting allow-legacy-cluster to true in your CLI configuration as describe in the Tanzu CLI Reference documentation.

Kubernetes STIG hardening results

The STIG hardening process changes security scans for TKG v2.2 cluster nodes. The following screen captures show the scan results for out-of-box TKG cluster notes and the scan results after hardening.

Scan results, hardened TKG v2.2 cluster nodes:

  • Control Plane

    Hardened Control Plane

  • Worker Nodes

    Hardened Worker

Kubernetes STIG exceptions

Some TKG processes and features are not hardened. The following table lists the exceptions and provides an explanation for the exception and a resolution.

VID Finding Title Compliant By Default? Fix Exception / Explanation
V-242376 The Kubernetes Controller Manager must use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during electronic dissemination. No Yes This can be resolved by setting KUBE_CONTROLLER_MANAGER_EXTRA_ARGS
V-242377 The Kubernetes Scheduler must use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during electronic dissemination. No Yes This can be resolved by setting the KUBE_SCHEDULER_EXTRA_ARGS
V-242378 The Kubernetes API server must use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during electronic dissemination. No Yes This can be resolved by setting APISERVER_EXTRA_ARGS
V-242379 The Kubernetes etcd must use TLS to protect the confidentiality of sensitive data during electronic dissemination. No Yes This can be resolved by setting the ETCD_EXTRA_ARGS
V-242390 The Kubernetes API server must have anonymous authentication deactivated. No No RBAC authorization is enabled on the API server, it is generally considered reasonable to allow anonymous access to the API server for health checks and discovery purposes when RBAC is enabled
V-242397 The Kubernetes kubelet static PodPath must not enable static pods. No No Kubernetes uses the static pod path to launch the API server, controller manager, and scheduler
V-242401 The Kubernetes API server must have an audit policy set. No Yes This can be resolved by setting ENABLE_AUDIT_LOGGING=true
V-242402 The Kubernetes API server must have an audit log path set. No Yes This can be resolved by setting ENABLE_AUDIT_LOGGING=true
V-242403 Kubernetes API server must generate audit records that identify what type of event has occurred, identify the source of the event, contain the event results, identify any users, and identify any containers associated with the event. No No The default audit rules that are generated filter out a lot of communication between internal components that flood the logs.
V-242404 Kubernetes kubelet must deny hostname override. No No This is required for Kubernetes on a cloud provider such as AWS/Azure
V-242409 Kubernetes Controller Manager must deactivate profiling. No Yes This can be resolved by setting KUBE_CONTROLLER_MANAGER_EXTRA_ARGS
V-242410 The Kubernetes API server must enforce ports, protocols, and services (PPS) that adhere to the Ports, Protocols, and Services Management Category Assurance List (PPSM CAL). No Requires manual review
V-242411 The Kubernetes Scheduler must enforce ports, protocols, and services (PPS) that adhere to the Ports, Protocols, and Services Management Category Assurance List (PPSM CAL). No Requires manual review
V-242412 The Kubernetes Controllers must enforce ports, protocols, and services (PPS) that adhere to the Ports, Protocols, and Services Management Category Assurance List (PPSM CAL). No Requires manual review
V-242413 The Kubernetes etcd must enforce ports, protocols, and services (PPS) that adhere to the Ports, Protocols, and Services Management Category Assurance List (PPSM CAL). No Requires manual review
V-242415 Secrets in Kubernetes must not be stored as environment variables. No No “SecretKeyRef will show the secret name not the contents of the secret when calling the ““Get Pod”” API call.”
V-245541 Kubernetes Kubelet must not deactivate timeouts. No Yes This can be resolved by setting the worker node and control plane KUBELET_EXTRA_ARGS
V-242417 Kubernetes must separate user functionality. No Requires manual review
V-242418 The Kubernetes API server must use approved cipher suites. No Yes This can be resolved by setting APISERVER_EXTRA_ARGS
V-242424 Kubernetes Kubelet must enable tls-private-key-file for client authentication to secure service. No No RotateServerCertificates requires serving certificates to be manually approved. The user can manually enable this, approve the certificates, and then apply this setting to the kubelets.
V-242425 Kubernetes Kubelet must enable tls-cert-file for client authentication to secure service. No No RotateServerCertificates requires serving certificates to be manually approved. The user can manually enable this, approve the certificates, and then apply this setting to the kubelets.
V-242434 Kubernetes Kubelet must enable kernel protection. No Yes This can be resolved by setting the worker node and control plane KUBELET_EXTRA_ARGS
V-254800 Kubernetes must have a Pod Security Admission control file configured. No No OPA Gatekeeper is a viable alternative and allows for finer grained pod security.
V-242442 Kubernetes must remove old components after updated versions have been installed. No Requires manual review
V-242445 The Kubernetes component etcd must be owned by etcd. No No To provision clusters, Tanzu Kubernetes Grid uses Cluster API which, in turn, uses the kubeadm tool to provision Kubernetes. kubeadm makes etcd run containerized as a static pod, therefore the directory does not need to be set to a particular user.
V-242447 The Kubernetes kube-proxy must have file permissions set to 644 or more restrictive. No No kube-proxy runs in a pod so this file does not exist on the host. Within the pod it is linked to another directory that has correct permissions
V-242461 Kubernetes API server audit logs must be enabled. No Yes This can be resolved by setting ENABLE_AUDIT_LOGGING=true
V-242462 The Kubernetes API server must be set to audit log max size. No Yes This can be resolved by setting ENABLE_AUDIT_LOGGING=true
V-242463 The Kubernetes API server must be set to audit log maximum backup. No Yes This can be resolved by setting ENABLE_AUDIT_LOGGING=true
V-242464 The Kubernetes API server audit log retention must be set. No Yes This can be resolved by setting ENABLE_AUDIT_LOGGING=true
V-242465 The Kubernetes API server audit log path must be set. No Yes This can be resolved by setting ENABLE_AUDIT_LOGGING=true
V-242468 The Kubernetes API server must prohibit communication using TLS version 1.0 and 1.1, and SSL 2.0 and 3.0. No Yes This can be resolved by setting APISERVER_EXTRA_ARGS
check-circle-line exclamation-circle-line close-line
Scroll to top icon