DirectorySecurity Advisories
Sign In
Directory
node-fips logoFIPS

node-fips

Last changed

Sign In for Updates

Get notified of upcoming product changes, critical vulnerability notifications and patches and more.

Sign In
Versions
Overview
Provenance
Specifications
SBOM
Vulnerabilities
Advisories

Chainguard Image for node-fips

Chainguard Images are regularly-updated, minimal container images with low-to-zero CVEs.

Download this Image

This image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/node-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard registry.

Compatibility Notes

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.

Getting Started

Verify FIPS Mode

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:

ORGANIZATION=my-organization

Then run the following:

docker run cgr.dev/$ORGANIZATION/node-fips --eval "require('crypto'); console.log(crypto.getFips() === 1)"
true

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.

Distroless CLI Application

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:

mkdir -p ~/node-reverse/bin && cd ~/node-reverse

This creates the following folder structure and sets our working directory to the root node-reversefolder:

node-reverse
└── bin

Now let's create a package.json file, which provides metadata about the project, including dependencies:

cat << 'EOF' > package.json
{
    "name": "linky_hello",
    "version": "1.0.0",
    "description": "Say hello to Linky",
    "main": "bin",
    "bin": {
        "linky_hello": "./bin/index.js"
    },
    "keywords": [],
    "author": "",
    "license": "ISC",
    "dependencies": {
        "text-reverse": "^1.0.0"
    }
}
EOF

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:

cat << 'EOF' > bin/index.js
#!/usr/bin/env node

const reverse=require('text-reverse');

const run_argument=process.argv[2]

if (run_argument) {
    console.log(run_argument)
    console.log(reverse(run_argument))    
} else {
    const message="Hello, Linky!"
    const reversed=reverse(message)
    console.log(message  + "🐙")
    console.log("🐙" + reversed)
}
EOF

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:

ORGANIZATION=my-organization

Then run the following to create the Dockerfile:

cat << EOF > Dockerfile
FROM cgr.dev/$ORGANIZATION/node-fips:latest
ENV NODE_ENV=production

WORKDIR /app

COPY --chown=node:node package.json .
ADD ./bin ./bin
RUN npm install

ENTRYPOINT ["node", "bin/index.js"]
EOF

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:

docker build . -t node-reverse

Finally, run the container:

docker run node-reverse

You should see the following output:

Hello, Linky!🐙
🐙!ykniL ,olleH

You can also pass an argument to the docker run node-reverse command to change the output:

docker run node-reverse "Hello, Chainguard User\!"

This should produce the following output:

Hello, Chainguard User!
!resU draugniahC ,olleH

Express.js Server

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:

mkdir -p ~/node-express && cd $_

Create a package.json file, which provides metadata about the project, including dependencies:

cat << 'EOF' > package.json
{
  "name": "Express Server",
  "version": "1.0.0",
  "description": "A server that allows getting and posting dummy data in JSON format",
  "main": "server.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "node server.js"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "body-parser": "^1.14.1",
    "express": "^4.13.3"
  }
}
EOF

Next, add our server application code:

cat << 'EOF' > server.js
var express = require('express');
var bodyParser = require('body-parser');
var app = express();

//Allow all requests from all domains
app.all('/*', function(req, res, next) {
  res.header("Access-Control-Allow-Origin", "*");
  res.header("Access-Control-Allow-Headers", "X-Requested-With, Content-Type, Accept");
  res.header("Access-Control-Allow-Methods", "POST, GET");
  next();
});

app.use(bodyParser.json());
app.use(bodyParser.urlencoded({extended: false}));

var animals = [
    {
        "id": "234kjw",
        "text": "octopus"
    },
    {
        "id": "as82w",
        "text": "penguin"
    },
    {
        "id": "234sk1",
        "text": "whale"
    }
];


app.get('/animals', function(req, res) {
    console.log("GET From SERVER");
    res.send(animals);
});

app.post('/animals', function(req, res) {
    var animal = req.body;
    console.log(req.body);
    animals.push(animal);
    res.status(200).send("Successfully posted animal\n");
});

console.log("🐙🐧🐋 Server running. Retreive animals from http://localhost:6069/animals")
app.listen(6069);
EOF

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:

ORGANIZATION=my-organization

Then run the following to create the Dockerfile:

cat << EOF > Dockerfile
FROM cgr.dev/$ORGANIZATION/node-fips:latest
ENV NODE_ENV=production

WORKDIR /app

COPY --chown=node:node ["package.json", "server.js", "./"]

RUN npm install --omit-dev

CMD [ "server.js" ]
EOF

Build the image:

docker build . -t node-express

Finally, run the server container:

docker run --rm -p 6069:6069 node-express

You should see the following message:

🐙🐧🐋 Server running. Retreive animals from http://localhost:6069/animals

Visit http://localhost:6069/animals to view the served JSON data.

You can post new data to the running application:

 curl -H 'Content-Type: application/json' \
 -d '{ "id":9001,"text":"gnu"}' \
 -X POST \
 http://localhost:6069/animals

After posting, refresh the page on http://localhost:6069/animals to view the additional data.

Configuration

Webpack Recommendation

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.

Documentation and Resources

Contact Support

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.

What are Chainguard Images?

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 Variants

As 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.

Learn More

To better understand how to work with Chainguard Images, we encourage you to visit Chainguard Academy, our documentation and education platform.

Licenses

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 agreement

Compliance

This 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

Related images

Category
FIPS
STIG
base

Safe Source for Open Source™
Media KitContact Us
© 2024 Chainguard. All Rights Reserved.
Private PolicyTerms of Use

Chainguard Images