mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-10-29 08:37:18 +08:00
Sorting the bullets
This commit is contained in:
55
sections/docker/install-for-production.md
Normal file
55
sections/docker/install-for-production.md
Normal file
@ -0,0 +1,55 @@
|
||||
# Remove development dependencies
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### One Paragraph Explainer
|
||||
|
||||
Dev dependencies greatly increase the container attack surface (i.e. potential security weakness) and the container size. As an example, some of the most impactful npm security breaches were originated from devDependecies like [eslint-scope](https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes) or affected dev packages like [event-stream that was used by nodemon](https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor/). For those reasons, the image that is finally shipped to production should be safe and minimal. Running npm install with a --production is a great start however it get even safer to run 'npm ci' that ensure a fresh install and the existence of lock file. Removing the local cache can shave additional tens of MB. Often there is a need to test or debug within a container using devDependencies - In that case, multi stage builds can help in having different sets of dependencies and finally only those for production (See dedicated bullet on multi stage builds)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Code Example – Installing for production
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Dockerfile</strong></summary>
|
||||
|
||||
```
|
||||
FROM node:12-slim AS build
|
||||
WORKDIR /usr/src/app
|
||||
COPY package.json package-lock.json ./
|
||||
RUN npm ci --production && npm clean cache --force
|
||||
|
||||
# The rest comes here
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Code Example Anti-Pattern – Installing all dependencies
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Dockerfile</strong></summary>
|
||||
|
||||
```
|
||||
|
||||
FROM node:12-slim AS build
|
||||
WORKDIR /usr/src/app
|
||||
COPY package.json package-lock.json ./
|
||||
# Two mistakes below: Installing dev dependencies, not deleting the cache after npm install
|
||||
RUN npm install
|
||||
|
||||
# The rest comes here
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Blog Quote: "npm ci is also more strict than a regular install"
|
||||
|
||||
From [npm documentation](https://docs.npmjs.com/cli/ci.html)
|
||||
|
||||
> This command is similar to npm-install, except it’s meant to be used in automated environments such as test platforms, continuous integration, and deployment – or any situation where you want to make sure you’re doing a clean install of your dependencies. It can be significantly faster than a regular npm install by skipping certain user-oriented features. It is also more strict than a regular install, which can help catch errors or inconsistencies caused by the incrementally-installed local environments of most npm users.
|
||||
30
sections/docker/scan-images.md
Normal file
30
sections/docker/scan-images.md
Normal file
@ -0,0 +1,30 @@
|
||||
# Scan the entire image before production
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### One Paragraph Explainer
|
||||
|
||||
Scanning the code for vulnerabilities is a valuable act, but it doesn't cover all the potential threats. Why? Because vulnerabilities also exist on the OS level and the app might execute those binaries like Shell, Tarball, OpenSSL. Also, vulnerable dependencies might be injected after the code scan (i.e. supply chain attacks) - hence scanning the final image just before production is in order. This idea resembles E2E tests - after testing the various pieces in-isolation, it's valuable to finally check the assmebled deliverable. There are 3 main scanner families: Local/CI binaries with a cached vulnerabilities DB, scanners as a service in the cloud and a niche of tools which scan during the docker build itself. The first group is the most popular and usually the fastest - Tools like [Trivvy](https://github.com/aquasecurity/trivy), [Anchore](https://github.com/anchore/anchore) and [Snyk](https://support.snyk.io/hc/en-us/articles/360003946897-Container-security-overview) are worth exploring. Most CI vendors provide a local plugin that facilitates the interaction with these scanners. It should be noted that these scanners cover a lot of ground and therefore will show findings in almost every scan - consider setting a high threshold bar to avoid getting overwhelmed
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Code Example – Scanning with Trivvy
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Bash</strong></summary>
|
||||
|
||||
```
|
||||
sudo apt-get install rpm
|
||||
$ wget https://github.com/aquasecurity/trivy/releases/download/{TRIVY_VERSION}/trivy_{TRIVY_VERSION}_Linux-64bit.deb
|
||||
$ sudo dpkg -i trivy_{TRIVY_VERSION}_Linux-64bit.deb
|
||||
trivy image [YOUR_IMAGE_NAME]
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Report Example – Docker scan results (By Anchore)
|
||||
|
||||

|
||||
Reference in New Issue
Block a user