Last changed
Get notified of upcoming product changes, critical vulnerability notifications and patches and more.
Sign InChainguard Images are regularly-updated, minimal container images with low-to-zero CVEs.
This image is available on cgr.dev
:
Be sure to replace the ORGANIZATION
placeholder with the name used for your organization's private repository within the Chainguard registry.
node-fips
is comparable to the official node
image for running NodeJS apps, but is specially designed to use approved cryptographic implementations at runtime. For more on FIPS support in Chainguard Images, consult the guide on FIPS-enabled Chainguard Images on Chainguard Academy
The node-fips
Chainguard Image runs as a nonroot user (node
) by default. A USER root
statement may be required before performing tasks requiring elevated permissions.
Node provides the Crypto API as standard. The cryptographic primitives accessed via these APIs are implemented by OpenSSL. When OpenSSL is configured to use the OpenSSL FIPS provider by default, the NodeJS Crypto API will be using approved implementation at runtime. This is documented in the FIPS section of the NodeJS Crypto API. The configuration options mentioned there have been completed at the node-fips
image build time, meaning the node-fips
image from Chainguard provides the Crypto APIs in approved mode without any special actions required from you, and without any need to modify your code.
This is achieved using the openssl-config-fipshardened
package that is pre-installed in the images, and completes the configuration described in the NodeJS upstream documentation, which states "FIPS mode can be enabled in Node.js via the OpenSSL configuration file". The applicable Cryptographic Module Validation Program (CMVP) certificate is listed on the FIPS commitment page.
To interactively verify that FIPS mode is correctly enabled, use the crypto.getFips() API.
First, set an environment variable to the name of your organization:
Then run the following:
The majority of npm packages that use the Crypto API to implement all cryptography and higher level abstractions, and thus are FIPS-compliant, or fail at runtime (for example, by attempting to request and use an unapproved algorithm).
There are many npm packages that provide their own cryptographic implementations (typically in pure-JavaScript) or by vendoring native code. All of those are likely to not be FIPS-certified, unless they only use Crypto for the cryptographic primitives or have been separately certified. This means that the majority and potentially all of the npm packages with the keyword "crypto" are not FIPS-certified implementations, and must not be used to cryptographically secure data. It is permitted to use them for non-security purposes.
In this example, we'll write a .js
script that prints a message, then prints the message reversed. The script will use one dependency, the text-reverse
package. The script will optionally take one positional argument: if no argument is passed, a default message will be printed and reversed, otherwise the passed argument will be printed and reversed.
First, let's create a project structure for our example:
This creates the following folder structure and sets our working directory to the root node-reverse
folder:
Now let's create a package.json
file, which provides metadata about the project, including dependencies:
The above defines a package, linky_hello
, that depends on text-reverse
, and which whill run the code in bin/index.js
on npm run start
.
Let's create our application code now:
This application code first looks at any arguments passed to the script. If a positional argument is passed when the script is run, it will print that argument, then print its reverse. If no argument is passed, a default message will be printed and reversed.
Finally, let's create a Dockerfile
for our image build. First, set an environment variable to the name of your organization:
Then run the following to create the Dockerfile:
This Dockerfile
sets the file NODE_ENV
environment variable to production
, copies our package.json
and bin
directory, installs our dependency with npm install
, and runs our .js
script.
Build the image, tagging it node-reverse
:
Finally, run the container:
You should see the following output:
You can also pass an argument to the docker run node-reverse
command to change the output:
This should produce the following output:
In this example, we'll create an Express.js server that allows retrieval of a JSON-formatted list of animals and the addition of new animals via POST request.
First, create a folder for our example:
Create a package.json
file, which provides metadata about the project, including dependencies:
Next, add our server application code:
This application runs a server with GET and POST endpoints. At the GET endpoint, some dummy data is served in JSON format. The POST endpoint accepts and adds new entries passed as JSON.
Finally, create a Dockerfile
for our image build. First, set an environment variable to the name of your organization:
Then run the following to create the Dockerfile:
Build the image:
Finally, run the server container:
You should see the following message:
Visit http://localhost:6069/animals to view the served JSON data.
You can post new data to the running application:
After posting, refresh the page on http://localhost:6069/animals to view the additional data.
WebPack 4 may default to using the Crypto API MD4 hash for non-security purposes, which is not available with node-fips
. Upgrade to WebPack 5 which defaults to highly performant non-security xxhash for better performance.
If upgrading to WebPack 5 is not an option, one can update local webpack configuration to use SHA-256 (even though it is for a non-security purpose) which will work regardless of the node's fips mode. See this PR as an example.
If you have a Zendesk account (typically set up for you by your Customer Success Manager) you can reach out to Chainguard's Customer Success team through our Zendesk portal.
Chainguard Images are a collection of container images designed for security and minimalism.
Many Chainguard Images are distroless; they contain only an open-source application and its runtime dependencies. These images do not even contain a shell or package manager. Chainguard Images are built with Wolfi, our Linux undistro designed to produce container images that meet the requirements of a secure software supply chain.
The main features of Chainguard Images include:
-dev
VariantsAs mentioned previously, Chainguard’s distroless Images have no shell or package manager by default. This is great for security, but sometimes you need these things, especially in builder images. For those cases, most (but not all) Chainguard Images come paired with a -dev
variant which does include a shell and package manager.
Although the -dev
image variants have similar security features as their distroless versions, such as complete SBOMs and signatures, they feature additional software that is typically not necessary in production environments. The general recommendation is to use the -dev
variants only to build the application and then copy all application artifacts into a distroless image, which will result in a final container image that has a minimal attack surface and won’t allow package installations or logins.
That being said, it’s worth noting that -dev
variants of Chainguard Images are completely fine to run in production environments. After all, the -dev
variants are still more secure than many popular container images based on fully-featured operating systems such as Debian and Ubuntu since they carry less software, follow a more frequent patch cadence, and offer attestations for what they include.
To better understand how to work with Chainguard Images, we encourage you to visit Chainguard Academy, our documentation and education platform.
Chainguard Images contain software packages that are direct or transitive dependencies. The following licenses were found in the "latest" version of this image:
Apache-2.0
Artistic-2.0
BSD-2-Clause
GCC-exception-3.1
GPL-2.0-only
GPL-2.0-or-later
GPL-3.0-or-later
For a complete list of licenses, please refer to this Image's SBOM.
Software license agreementThis is a FIPS validated image for FedRAMP compliance.
This image is STIG hardened and scanned against the DISA General Purpose Operating System SRG with reports available.
Learn more about STIGsGet started with STIGs