Version: latest

FIPS Validate

The fips-validate command checks the Federal Information Processing Standards (FIPS) compliance of your Kubernetes clusters. You can use the command to ensure that your clusters are FIPS-compliant by scanning the images and exposed service endpoints in your clusters.

info

If you have the environment variable KUBECONFIG set, the fips-validate will automatically use the kubeconfig file and skip prompting you for the kubeconfig file path.

Subcommands

The fips-validate command exposes the following subcommands:

images: Validate the FIPS compliance of the images in your clusters.
services: Validate the FIPS compliance of the service endpoints in your clusters.
clean: Remove the FIPS validation resources from your clusters.

Prerequisites

The fips-validate command requires the following prerequisites:

Ensure you have access to the kubeconfig file for the cluster that you want to validate. The file needs to be accessible from the machine where you issue the fips-validate command. Refer to the Set up Kubectl guide to learn how to get the kubeconfig file for your cluster.
Sufficient permissions to create a new namespace and deploy resources in the namespace. We recommend using an elevated ClusterRole such as cluster-admin to ensure that the command can create the necessary resources.
The Kubernetes cluster must be accessible from the machine where you issue the fips-validate command. Ensure that the kubeconfig file is correctly configured to access the cluster.
The Kubernetes cluster must have internet access to download the images when using the images subcommand.

Limitations

The only supported runtime is Go. Images with binaries compiled in other languages are marked as unknown in the report.
Only services exposing port 443 are verified.
Non-HTTP based service endpoints are not supported.

Images

The images subcommand validates the FIPS compliance of the images in your clusters. The command scans all the images of active containers. The image is downloaded from the source and unpacked through Luet and all files that are Executable and Linkable Format binaries are scanned. The scan checks if the binaries are compiled with FIPS compliant cryptographic libraries.

To enable the scan, the command deploys resources into a Kubernetes namespace named vertex-ns, unless otherwise specified, in the target cluster. Upon completion of the scan, the command prints the results of the scan to the terminal and cleans up the resources from the cluster.

The images subcommand accepts the following flags:

Short Flag	Long Flag	Description	Type
`-n`	`--namespace`	The namespace in which to deploy the resources for the FIPS scan. The default namespace is `vertex-ns`	string
`-f`	`--out`	The output file path to save the scan results. The default output is the terminal.	string
`-h`	`--help`	Display the help message for the `images` subcommand.	boolean

Limitations

Images hosted in private registries are not supported.
Only Go binaries are supported. Images with binaries compiled in other languages are marked as unknown in the report.

Examples

Validate the FIPS compliance of the images in your cluster.

palette fips-validate images

Validate the FIPS compliance of the images in your cluster and save the results to a file.

palette fips-validate images --out /path/to/fips-scan-results.txt

Validate the FIPS compliance of the images in your cluster and deploy the resources in a custom namespace.

palette fips-validate images --namespace my-scan-ns

Review Results

The report contains a list of images and the FIPS compliance status of the binaries in the images. Each row in the report contains the following columns:

Column	Description
`NO.`	The number of the image in the order of the scan.
`BINARY`	The name of the executable binary.
`ARCH`	The architecture of the binary.
`PATH`	The path of the binary in the image.
`VERSION`	The version of the programming language used to create the binary. Go is the only supported language from a version detection capability.
`EXE`	How the binary was compiled, either statically or dynamically.
`CRYPTO`	The cryptographic library used to compile the binary.

The following is an example of the FIPS compliance report. The validated image is FIPS compliant as the binary is compiled with the BoringSSL cryptographic library.

---------------------------------------------------------------
image: gcr.io/spectro-images-public/release-fips/cluster-api-aws/cluster-api-aws-controller:v1.5.2-spectro-4.3.0
┌─────┬─────────┬────────┬──────────┬──────────┬────────┬────────┐
│ NO. │ BINARY  │ ARCH   │ PATH     │ VERSION  │ EXE    │ CRYPTO │
├─────┼─────────┼────────┼──────────┼──────────┼────────┼────────┤
│   1 │ manager │ x86-64 │ /manager │ go1.21.6 │ static │ boring │
└─────┴─────────┴────────┴──────────┴──────────┴────────┴────────┘

If the scan is not able to determine the FIPS compliance status of a binary, the status is marked as unknown in the summary section. The individual row will contain a note stating the reason for the unknown status.

image: ghcr.io/spectrocloud/hello-universe:1.1.1
note: binaries are not using boring crypto and/or not statically linked
┌─────┬──────────────────┬────────┬─────────────────────────────────┬─────────┬────────┬─────────┐
│ NO. │ BINARY           │ ARCH   │ PATH                            │ VERSION │ EXE    │ CRYPTO  │
├─────┼──────────────────┼────────┼─────────────────────────────────┼─────────┼────────┼─────────┤
│   1 │ legacy.so        │ x86-64 │ /usr/lib/ossl-modules/legacy.so │ unknown │ static │ openssl │
│   2 │ padlock.so       │ x86-64 │ /usr/lib/engines-3/padlock.so   │ unknown │ static │ openssl │
│   3 │ libcurl.so.4.8.0 │ x86-64 │ /usr/lib/libcurl.so.4.8.0       │ unknown │ static │ openssl │
│   4 │ node             │ x86-64 │ /usr/local/bin/node             │ unknown │ static │ openssl │
│   5 │ libcrypto.so.3   │ x86-64 │ /lib/libcrypto.so.3             │ unknown │ static │ openssl │
└─────┴──────────────────┴────────┴─────────────────────────────────┴─────────┴────────┴─────────┘

The end of the report contains a summary of the scan results. The summary includes all the images scanned and the status of each image.

┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬─────────┐
│ IMAGE                                                                                                           │ STATUS  │
|---------------------------------------------------------------------------------------------------------------------------|
│ gcr.io/spectro-dev-public/vishu/spectro-drive:latest                                                            │ unknown │
│ gcr.io/spectro-images-public/release/kube-rbac-proxy:spectro-v0.14.0-20230508                                   │ failed  │
│ gcr.io/spectro-images-public/release-fips/system-upgrade-controller:v0.11.4_spectro                             │ passed  │
│ us-east1-docker.pkg.dev/spectro-palette-images/public/daily-fips/upgrade:20240305.0000                          │ passed  │
│ gcr.io/spectro-images-fips/kube-scheduler:v1.28.5                                                               │ passed  │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴─────────┘

Services

The services subcommand validates the FIPS compliance of the service endpoints in your clusters. The command scans the service endpoints and conducts a handshake with each endpoint through testssl. The handshake is used to verify if the service endpoint is using FIPS compliant TLS versions and cryptographic ciphers. The service endpoint's certificate is also verified if it's within a valid timeframe by verifying its start and expiration dates.

The following flags are available for the services subcommand:

Short Flag	Long Flag	Description	Type
`-n`	`--namespace`	The namespace in which to deploy the resources for the FIPS scan. The default namespace is `vertex-ns`	string
`-f`	`--out`	The output file path to save the scan results. The default output is the terminal.	string
`-h`	`--help`	Display the help message for the `images` subcommand.	boolean

Checks

The following is a list of checks is performed by the services subcommand:

Check	Description
cipher-tls12	Verifies TLS 1.2 cipher suites.
cipher-tls13	Verifies TLS 1.3 cipher suites.
SSLv2, SSLv3, TLS1, TLS1_1	Checks for the presence of deprecated SSL/TLS versions.
cipherlist_NULL	Checks for the presence of NULL encryption cipher suites.
cipherlist_aNULL	Checks for the presence of aNULL encryption cipher suites.
cipherlist_EXPORT	Checks for the presence of EXPORT encryption cipher suites.
cipherlist_3DES_IDEA	Checks for the presence of 3DES and IDEA encryption cipher suites.
cipherlist_OBSOLETED	Checks for the presence of obsoleted encryption cipher suites.
cipherlist_LOW	Checks for the presence of LOW encryption cipher suites.
cert_notBefore	Validates the start date of the certificate.
cert_notAfter	Validates the expiration date of the certificate.
FS_TLS12_sig_algs	Verifies the supported signature algorithms for TLS 1.2.
HSTS	Validates the presence of HTTP Strict Transport Security (HSTS) headers.
DNS_CAArecord	Confirms the presence of DNS Certification Authority Authorization (CAA) records.
security_headers	Checks for the presence of recommended security headers. Refer to testssl.sh documentation for more context. Search for the `--header` description.
overall_grade	Assesses the overall security grade of the configuration.
cert_	Ensures certificate-related configurations meet requirements, excluding specific cases.

Examples

Validate the FIPS compliance of the service endpoints in your cluster.

palette fips-validate services

Validate the FIPS compliance of the service endpoints in your cluster and save the results to a file.

palette fips-validate services --out /path/to/fips-scan-results.txt

Validate the FIPS compliance of the service endpoints in your cluster and deploy the resources in a custom namespace.

palette fips-validate services --namespace my-scan-ns

Review Results

The report contains a list of service endpoints and the FIPS compliance status of the service endpoints. Each row in the report contains the following columns:

Column	Description
`NO.`	The number of the service endpoint in the order of the scan.
`ID`	The finding identifier.
`FINDING`	The description of the finding. Depending on the finding, you may receive a technical finding. Refer to the Findings section in case you receive a technical finding.
`SEVERITY`	The severity of the finding.
`STATUS`	The status of the finding. Allowed values are `PASSED` or `FAILED`.

endpoint: oldrelease-vc1.cluster-65ea4b3b9fe382461d51fbb3
┌─────┬────────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬──────────┬────────┐
│ NO. │ ID                     │ FINDING                                                                                                                           │ SEVERITY │ STATUS │
├─────┼────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼──────────┼────────┤
│   1 │ cipherlist_OBSOLETED   │ offered                                                                                                                           │ CRITICAL │ FAILED │
│   2 │ cipher-tls1_2_xcca9    │ TLSv1.2   xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 521   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 │ HIGH     │ FAILED │
│   3 │ cipher-tls1_3_x1303    │ TLSv1.3   x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                  │ HIGH     │ FAILED │
│   4 │ Cache-Control_multiple │ Multiple Cache-Control headers. Using first header: no-cache, private                                                             │ MEDIUM   │ FAILED │
│   5 │ LUCKY13                │ potentially vulnerable, uses TLS CBC ciphers                                                                                      │ LOW      │ FAILED │
└─────┴────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴──────────┴────────┘

Findings

A finding is a result of a failed check. The FINDING column may contain technical details of the finding. The technical finding contains the following information:

The TLS version
The cipher suite HEX code.
The name of the cipher suite.
The key exchange algorithm.
The encryption algorithm.
The encryption key length.
The authentication algorithm.

To help you better understand technical findings values, use the following example.

TLSv1.3   x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256

The table below explains the example finding value and what each value represents. The values are separated by a space.

Value	Explanation
`TLSv1.3`	The TLS version.
`x1303`	The cipher suite HEX code.
`TLS_CHACHA20_POLY1305_SHA256`	The name of the cipher suite.
`ECDH 253`	The key exchange algorithm.
`ChaCha20`	The encryption algorithm.
`256`	The encryption key length.
`TLS_CHACHA20_POLY1305_SHA256`	The authentication algorithm.

The service endpoint is using the TLSv1.3 version with TLS_CHACHA20_POLY1305_SHA256 cipher suit. The TLS version and the cipher suite is not considered FIPS compliant and the status is marked as FAILED.

A successful check will not have a finding identifier. The following is an example of a successful check.

---------------------------------------------------------------
endpoint: palette-webhook-service.palette-system
note: all validations passed
---------------------------------------------------------------

The end of the report contains a summary of the scan results. The summary includes all the service endpoints scanned and the status of each endpoint. Below is an example of the summary section.

┌────────────────────────────────────────────────────────────────┬────────┐
│ ENDPOINT                                                       │ STATUS │
├────────────────────────────────────────────────────────────────┼────────┤
│ capa-webhook-service.capi-webhook-system                       │ passed │
│ capi-kubeadm-bootstrap-webhook-service.capi-webhook-system     │ passed │
│ capi-kubeadm-control-plane-webhook-service.capi-webhook-system │ passed │
│ capi-webhook-service.capi-webhook-system                       │ passed │
│ capvc-webhook-service.capi-webhook-system                      │ failed │
│ cert-manager-webhook.cert-manager                              │ passed │
│ metrics-server.cluster-65e4cb59cbfc84ea5877af4c                │ passed │
│ oldrelease-vc1.cluster-65ea4b3b9fe382461d51fbb3                │ failed │
│ oldrelease-vc1-headless.cluster-65ea4b3b9fe382461d51fbb3       │ failed │
│ oldrelease-vc1-lb.cluster-65ea4b3b9fe382461d51fbb3             │ failed │
│ kubernetes.default                                             │ passed │
│ palette-webhook-service.palette-system                         │ passed │
│ 10-0-3-97.kubernetes.default:2380                              │ failed │
│ 10-0-3-97.kubernetes.default:10250                             │ passed │
└────────────────────────────────────────────────────────────────┴────────┘

Clean

The clean subcommand removes the FIPS validation resources from your clusters. The command is intended to be used in scenarios where the images or services subcommands may fail to clean up the resources from the cluster. As a workaround, you can manually trigger the clean subcommand to remove the resources from the cluster.

The clean subcommand accepts the following flags:

Short Flag	Long Flag	Description	Type
`-h`	`--help`	Display the help message for the `clean` subcommand.	boolean

Examples

Remove the FIPS validation resources from your cluster.

export KUBECONFIG=/path/to/kubeconfig
palette fips-validate clean

Subcommands​

Prerequisites​

Limitations​

Images​

Limitations​

Examples​

Review Results​

Services​

Checks​

Examples​

Review Results​

Findings​

Clean​

Examples​

Subcommands

Prerequisites

Limitations

Images

Limitations

Examples

Review Results

Services

Checks

Examples

Review Results

Findings

Clean

Examples