UNCLASSIFIED

Container Hardening Process Guide

Version 1, Release 2

24 August 2022

Developed by DISA for the DOD

DISTRIBUTION – DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

(October 2020).

UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

Trademark Information

Names, products, and services referenced within this document may be the trade names,
trademarks, or service marks of their respective owners. References to commercial vendors and
their products or services are provided strictly as a convenience to our users and do not constitute
or imply endorsement by the Defense Information Systems Agency of any nonfederal entity,
event, product, service, or enterprise.

ii
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

TABLE OF CONTENTS

Page
1. OVERVIEW .............................................................................................................................1
1.1 Introduction .......................................................................................................................1
1.2 Definitions .........................................................................................................................2
1.2.1 DOD Hardened Containers (DHC) ..........................................................................2
1.2.2 Container Hardening Team (DHT) ..........................................................................2
1.2.3 DOD Container Factory (DCF) ...............................................................................3
1.2.4 Repo One/DOD Centralized Container Source Code Repository (DCCSCR) ........3
1.2.5 Iron Bank/DOD Centralized Artifacts Repository (DCAR) ....................................3
1.2.6 DOD Approved CI/CD Orchestration Solution (DACCOS) ...................................3
1.2.7 DOD Base Container Image Approved Source (DBCIAS) .....................................3
2. CONTAINER HARDENING PROCESS ..............................................................................5
2.1 Container Hardening Prerequisite Steps ............................................................................5
2.2 Container Hardening Process ............................................................................................6
2.3 Container Scanning Process ..............................................................................................8
2.4 Findings Mitigation Reporting ..........................................................................................9
2.5 Approving Process ...........................................................................................................11
2.6 Automated Hardening......................................................................................................13
2.7 Third-Party Container Sharing ........................................................................................13
2.8 Keycloak Integration .......................................................................................................13
3. APPENDIX A: FOLDER STRUCTURE EXAMPLE .......................................................15
3.1 Inside Repo One DCCSCR .............................................................................................15
3.2 Inside Iron Bank DCAR ..................................................................................................16
4. APPENDIX B: DOD HARDENED CONTAINERS CYBERSECURITY
REQUIREMENTS.................................................................................................................17
5. APPENDIX C: SECURITY CONTROL INHERITANCE ...............................................18
6. APPENDIX D: CONTAINER SECURITY/REMEDIATION CONSIDERATIONS ....19
6.1 False Positives Commentary............................................................................................19
7. APPENDIX E: VISUAL PROCESS FLOW .......................................................................20
7.1 Iron Bank Steps ...............................................................................................................20
8. APPENDIX E: CONTAINER BRANCHING STRATEGY .............................................23

iii
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

LIST OF FIGURES

Page
Figure 1-1: DevSecOps Example.................................................................................................... 1
Figure 1-2: Iron Bank Repository ................................................................................................... 2
Figure 3-1: Example 1: Repo One DCCSCR ............................................................................... 15
Figure 3-2: Example 2: Iron Bank DCAR .................................................................................... 16
Figure 7-1: Visual Iron Bank Flow Diagram ................................................................................ 20
Figure 8-1: Container Branching Process ..................................................................................... 23
Figure 8-2: Process Flow .............................................................................................................. 24

iv
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

LIST OF TABLES

Page
Table 2-1: Hardener Process ........................................................................................................... 7
Table 2-2: Scanning Process Steps ................................................................................................. 8
Table 2-3: Mitigation Recommendations ....................................................................................... 9
Table 2-4: Approved Container Deployment Process .................................................................. 11

v
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

1. OVERVIEW

1.1 Introduction
This document focuses on the Department of Defense (DOD) Enterprise DevSecOps Initiative
(DSOP) and was created to detail the Enterprise DevSecOps Container Hardening Process and
ensure it meets the DOD Hardened Containers Cybersecurity Requirements. It is important to
understand both DevSecOps and cybersecurity concepts and principals, as well as have
knowledge of containers and container platforms. Refer to the Master Approach Document for
more information on how the DSOP platform functions.

DevSecOps is a set of software development practices that combines software development

(Dev), security (Sec), and information technology operations (Ops) to secure the outcome and
shorten the development life cycle. Software features, patches, and fixes occur more frequently
and in an automated fashion. Security is applied at all phases of the software life cycle. An
example DevSecOps process is shown in Figure 1-1 below. This document will focus on the
process of securing containers that are placed into a common repository for everyone to use. This
repository can be found at https://repo1.dsop.io/dsop (refer to Figure 1-2).

Note: This document focuses on container security. It is understood that any application code or
library must be scanned by static/dynamic code analysis tools and passed or have
mitigated/accepted the risk prior to being integrated into a container for DOD use. If the
application is already approved for use (and scanned) by the Intelligence Community
(IC)/National Security Agency (NSA)/DOD Chief Information Officer (CIO)/Defense
Information Systems Agency (DISA), reciprocity can take effect. This document does not
describe that process.

Figure 1-1: DevSecOps Example

1
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

Figure 1-2: Iron Bank Repository

1.2 Definitions
In describing the hardening process, it is necessary to define concepts and terminology. This
section will define and describe items discussed in the process as well as other sections of this
document.

1.2.1 DOD Hardened Containers (DHC)

A DOD hardened container is an Open Container Image (OCI)-compliant image that is secured
and made compliant with the DOD Hardened Containers Cybersecurity Requirements.
Container images should adhere to the OCI Image Format Specification to ensure portability
whenever possible. These containers are made available for use in the Iron Bank, the centralized
repository.

1.2.2 Container Hardening Team (DHT)

The Container Hardening Team is responsible for hardening DOD containers according to DOD
Hardened Containers Cybersecurity Requirements. The team is composed of DevSecOps
Engineers and other container experts that have knowledge of the product being hardened.
They also have an understanding of the DHC Cybersecurity Requirements and DISA Security
Requirements Guide (SRG) and Security Technical Implementation Guide (STIG) information.
A single team member is called a Hardener.

Hardeners also require the following skills:

• Expertise in OCI-compliant container images, including creating compliant Dockerfiles.
• Understanding of DISA STIG/SRG documentation as it applies to the application run.

2
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

• Expertise in the DHC Cybersecurity Requirements.

• Strong understanding of Container security solutions (Prisma, Anchore, and StackRox)
for vulnerability scanning, Chef InSpec and OpenSCAP for compliance scanning.

1.2.3 DOD Container Factory (DCF)

To automate the hardening process, the DOD has implemented a DSOP platform on GovCloud
at Impact Level 2 (publicly accessible and open-source) to set up the Continuous Integration/
Continuous Delivery (CI/CD) pipeline leveraged to automate the container hardening process.
This DevSecOps process is similar to Figure 1-1 and will be used primarily for the validation of
hardened containers.

1.2.4 Repo One/DOD Centralized Container Source Code Repository (DCCSCR)

This is the web location used to store the hardened Dockerfiles and associated documentation.
This DOD enterprise source code repository will be centrally hosted so Hardeners can store their
code and leverage a CI/CD pipeline.

For onboarding containers into Repo One, view the prerequisite information shown at
https://repo1.dsop.io/dsop/dccscr/tree/master/contributor-onboarding or view the process detail
in Section 2.

1.2.5 Iron Bank/DOD Centralized Artifacts Repository (DCAR)

This is the system that stores the DOD Hardened Containers and associated documentation. This
DOD enterprise centralized artifacts repository is implemented on a DOD Approved Cloud to
provide access to DOD Programs and to the DOD Hardened Containers.

The artifact repository supports both files (traditional artifacts) and containers, as well as
container registry capabilities. It provides a secure mechanism to store, track, sign, and distribute
approved containers. It is accessible at: https://ironbank.dsop.io.

1.2.6 DOD Approved CI/CD Orchestration Solution (DACCOS)

In a DevSecOps system, a CI/CD pipeline is integral, and an orchestration solution is needed.
The DoD has chosen CI/CD orchestration solutions such as Jenkins (open source), Cloudbees
Jenkins, and GitLab for this function, and all are containerized and hardened where applicable.

1.2.7 DOD Base Container Image Approved Source (DBCIAS)

To ensure container base images are from approved sources, a container base image must be
downloaded from a DBCIAS as a baseline.

There are two types of repositories: trusted and untrusted. Trusted repositories are used as an
approved source for downloading container base images. Untrusted resources cannot be used in

3
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

this fashion unless a Memorandum of Understanding (MOU) is reached between the DoD and
the vendor or mission partner using the untrusted source. The MOU will dictate strict levels of
security and ensure access to base images and their updates.

The following sources are currently approved and should be used in order of priority:
• Iron Bank/DCAR (approved DOD-wide; trusted).
• Product vendor proprietary repository (untrusted).
• Docker Hub (untrusted).
• Red Hat Container Repository (untrusted).

A trusted repository indicates that the containers were hardened by the DHT and can be used as
is. Refer to Section 2.1 for the vendor/mission partner prerequisite review steps before selecting
a base image.

4
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

2. CONTAINER HARDENING PROCESS

The container hardening process requires the mission partner work closely with the DOD
Container Approvers and Hardeners so that cybersecurity confidence can be gained about the
containers prior to DOD use.

2.1 Container Hardening Prerequisite Steps

Some key prerequisite steps are listed below. The DHT is available to assist all personnel if there
are questions.
1. Always prioritize the reuse of a Dockerfile from Tech Note: A Dockerfile execution must
Iron Bank. Alternatively, a Dockerfile from its begin with a FROM instruction. This may
vendor or open-source community can be reused if be after parser directives, comments, and
it can be switched to an approved DOD base globally scoped ARGs. As an argument, a
image. Ideally, the team should ensure the Iron name is provided with an optional tag for
an image that should be used as the base
Bank’s accepted base images
for the Docker container. Instead of
(UBI7/UBI8/scratch/distroless) are used by building a host OS from scratch, the
upstream partners/vendors. FROM instruction allows a base image
for Linux or another OS as the Dockerfile
2. Ensure the Dockerfile uses a DOD- hardened/ basis.
approved base container whenever available. Use
the FROM command to do this. For example, if the Jenkins Dockerfile uses the Docker
Hub OpenJDK base image, ensure the FROM instruction is replaced by the DoD-
hardened OpenJDK base image instead. Use of the STIGed DOD-approved Universal
Base Image (UBI) is recommended, as is the use of the approved DOD scratch and
distroless image. These are open source, free, and available on the Iron Bank.
3. Use base images that reuse the closest hardened image layer available to inherit its
hardening. For example, if a Java application is used, use the base image of the DOD-
hardened OpenJDK and not just the DOD-hardened UBI image. It is highly
recommended to have the DOD Enterprise DevSecOps team review and agree to the
selection of a base image if it does not come from the Iron Bank.
4. If there are multiple source options/tags/variants for the base image chosen, ensure the
image is scanned with both Prisma (or StackRox) and Anchore, to understand security
risks associated with each image. For example, if you can download the image from
Docker Hub, RedHat registry or Oracle registry, select the image most closely aligned
with the DOD Hardened Containers Cybersecurity Requirements based on the scan
results of those images.
5. If the base image has security flaws such as critical vulnerabilities, attempt to mitigate the
flaw by applying security hardening, configuration changes etc. If that does not correct
the flaw, the library/binary impacted must be removed or the risk documented as
accepted.
6. Prepare all dependencies in the Repo One prior to submitting for hardening. All
dependencies that need to be downloaded from the internet must be included in the
Download.json or Download.YAML file to allow the container hardening system to build
containers offline. If a container can benefit the DOD, then it can be considered for
inclusion in Repo One or another repository compliant with the DOD Enterprise

5
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

DevSecOps Reference Design. The platform and hardened containers must be compliant
with the minimum viable product requirements or it cannot be accredited.
7. It is critical for containers to be able to be built on Tech Note: Platform One spends a great
classified and air gapped environments. Dockerfiles deal of time to ensure dependencies are
should not download any artifacts. Instead, a not downloaded without their knowledge.
prephase step called Download will occur so the Initially, Platform One will list all
dependencies, download them while
platform can download the required dependencies
connected to internet, go Offline, and
online. Then, the rest DOD Container Hardening build the container validating the
process will operate in a disconnected and/or dependency downloads are not attempted.
classified environment that does not have internet This critical security process ensures
access. This will ensure the process will not be able decoupling the download from the build
process.
to pull files from the internet that are required to
build.
8. If an organization that has a capability, has two license options (for example, open source
and an enterprise managed version), both containers must be provided to Repo One. The
organization cannot only provide the paid version. The DOD Hardening Team will not
accept enterprise containers if the open-source container is not also provided.

2.2 Container Hardening Process

The process described in this section is for vendor or mission partner informational awareness. It
is important for mission partners and vendors to understand the best practice considerations
shown in Appendix D: Container Security/Remediation Considerations. It is also important to
understand that as containers inherit many of the security controls from the underlying Platform
as a Service (PaaS) solution, the underlying host OS must be hardened per Agency-specific
security guidelines as listed in Appendix C: Security Control Inheritance.

It is important to understand that containers must run on a DevSecOps Platform compliant with
the DoD Enterprise DevSecOps Ref Design and its MVP requirements, including the Sidecar
Container Security Stack, which enforces behavior detection and zero trust in runtime.

Without a CNCF-compliant Kubernetes platform and the MVP Ref Design capabilities, a
standalone container is not accredited and its certificate to field does not apply.

The container hardening and scanning pipeline is located at https://repo1.dsop.io/dsop. Note that
third parties are not allowed master branch write access to the Repo One repository; only
members of the Hardening Team are authorized to make changes that will affect hardened
containers including, Dockerfiles, readme files, license files, and anything else required for the
scanning and hardening of the container. A Container Hardener will approve the container into
the Repo One and Iron Bank repository after validation and approval. This process should also
support free and open-source software (FOSS) as well as commercial off-the-shelf (COTS)
software.

Using the container software factory or pipeline, the Hardener will begin the hardening process
as depicted in the Figure 7-1 sub-process titled “Begin Hardener process”. The detailed steps and
examples are shown in Table 2-1 below.

6
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

Table 2-1: Hardener Process

Step Process Description Example Resource
1 Create a new folder in Repo One under Refer to Appendix A: Folder Structure Hardener
the organization name. Example. If open source, list as open
source.
2 Set up a new folder in the Repo One Refer to Appendix A: Folder Structure Hardener
under the product name. Example.
Note: If a product has multiple variant
options such as “cli” mode or
“daemon” mode or x86 versus x64
versions, various subfolders can be
created for each variant.
3 Define and list which version of the If a Hardener needs to harden Hardener
product and hardened containers will “Jenkins” with UBI base image, and
initially be supported. the current OSs supported on Docker
Hub are 2.59 to 2.60, the Hardener
should start with 2.59 and move to the
latest version, ideally using the same
documentation with attempted reuse of
the same Dockerfile created across
versions.
Note: Hardening a different OS
requires the OS to be STIGed! Use
STIGed UBI OSs if possible.
4 Select a DoD Base Container Image Iron Bank is the DoD trusted Hardener
Approved Source to download the repository, for example.
base image from for each version.
5 Set up a subfolder within Repo One Under “Open-source” and under Hardener
for each new version that will contain “Jenkins” a subfolder (“2.59”, “2.60”,
the newly created Dockerfile and etc.) will be created per version. Refer
related to Appendix A: Folder Structure
scripts/documentation/LICENSE/REA Example.
DME
.md.
6 Within each version, starting with the To understand which instructions are Hardener
lowest version supported, create a required, the Hardener will make
Dockerfile in Repo One that will use decisions based on the Scanner
the selected base image. The findings from the scan process. Refer
Dockerfile will download the to Section 2.3.
appropriate base image.
The Dockerfile will also have
additional instructions used to harden

7
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

Step Process Description Example Resource

the container based on the Hardener
decisions to mitigate findings and/or
ensure proper DoD compliance.

Note: It is imperative to reuse instructions as much as possible between versions so hardening

can be leveraged across versions. It is understood that new versions bring additional or new
features, which can require additional hardening. Therefore, the Dockerfile should be reused
from version minus one (if it exists) to avoid redundant work and leverage prior work.

2.3 Container Scanning Process

Using the CI/CD orchestration tool, the Repo One folder content will be downloaded into the
pipeline and the Dockerfile used to build the container using Docker. This is done by reusing the
Jenkins file.

Table 2-2: Scanning Process Steps

Step Process Description Example Resource
1 The CI/CD pipeline will be triggered Hardener
once the files are placed in the Repo
One folder. Health and readiness will
then be assessed.
2 The pipeline will automatically begin System
to run the necessary scanners
connected to it for compliance and
vulnerability checks. It is mandatory to
execute both Anchore and
Prisma/StackRox checks. For Atomic
OpenSCAP or Docker OSCAP, one
must be run.
2a Repo One Prisma/StackRox– BSH Prisma/StackRox configuration must Hardener
compliance rules will be loaded into set SCAP_ENABLED to true.
the product for policy checks. Using Scanner must have updated
the containers hardened from Repo vulnerability information prior to
One is mandated to ensure the proper every run.
policies are loaded and updated. This
step is mandated.
2b Repo One Anchore – JSON xml Custom policy checks can be made. Hardener
compliance rules must be loaded into Scanner must have updated
the product for policy checks. Using vulnerability information prior to
the containers hardened from Repo every run.
One is mandated to ensure the proper
policies are loaded and updated. This

8
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

Step Process Description Example Resource

step is mandated along with
Prisma/StackRox.
2c Atomic OpenSCAP – This product The focus is to manage Atomic host Hardener
will operate on the command line to system and containers. For additional
provide additional CVE and information, refer to “Atomic vs.
compliance scans. If Atomic Docker- OSCAP Whitepaper” by
OpenSCAP is not used, Docker DISA.
OSCAP must be used.
2d Docker-OSCAP – OpenSCAP The focus is on Docker images and Hardener
provides vulnerability and compliance containers. For additional information,
scanning for Docker images and refer to “Atomic vs. Docker-OSCAP
containers. If Docker OSCAP is not Whitepaper” by DISA.
used, Atomic OpenSCAP must be
used.
3 If findings exist, continue to the Hardener
mitigation process in Section 2.4;
otherwise, continue to the approval
process in Section 2.5.

2.4 Findings Mitigation Reporting

Once findings are produced, it is necessary to report on these findings to the DevSecOps
Approver as well as the mission partner or vendor. Table 2-3 lists some of the common
recommendations made to mission partners and vendors.

Table 2-3: Mitigation Recommendations

Vendor/Partner
Step Process Description Resource
Recommended Action
1 Iterate through the results, creating
mitigation Dockerfile instructions for
the mission partner or vendor.
1a Check base images, ports and list Enable or disable all ports except for Hardener
findings. those that are necessary to operate.
Change operating ports to numbers
other than standard 443 or 80.
1b List lack of transmission security if it Ensure that data in transmission is Hardener
exists. secured using TLS. Strive for TLS
v1.3.
1c List default configurations in use. Disable unused features and modify Hardener
default configurations to reduce the
possible security breach footprint.

9
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

Vendor/Partner
Step Process Description Resource
Recommended Action
1d Emit logs to stdout. Logs must be emitted to stdout or Hardener
accessible locations.
1e User privileges Do not run with elevated privileges. Hardener
Root ID (UID 0) must not be used
unless risk accepted and documented.
1f Decouple configurations to make them Use arguments, environment variables Hardener
more portable. Use secrets for and configmaps for configurations and
sensitive information such as tokens, key value pairs. Also, use encoding
keys, and passwords. such as base64 to obfuscate and
encrypt yaml secrets.
1g User access Integrate with the DoD hardened Hardener
Keycloak SSO stack for single sign on
capability or Require Common Access
Card (CAC) access through SAML
when possible. If not possible, MFA
may be used based on risk acceptance.
1h Ensure secure connections are Use TLS and secure certificates when Hardener
leveraged. connecting with other services and
containers. Refer to 1b.
1i Remove unnecessary packages, Remove anything not core to the Hardener
services, and applications. operation of the container.
1j Remove User and Group permissions. Remove the setuid and setgid Hardener
permissions so that file permissions
cannot be modified for malicious
purposes.
1k Comply with DoD Hardened Refer to Appendix B: DoD hardened Hardener
Containers Cybersecurity Containers Cybersecurity
Requirements. Requirements.
1l Avoid command injections. Be cautious with command injections Hardener
in RUN, particularly when using ENV
or ARGs.
1m Leverage Kubernetes secrets Ensure that Kubernetes Secrets and/or Hardener
secrets vault are used to store secrets.
2 Perform a container HEALTHCHECK Hardener
to ensure proper overall functionality
as well as the health and readiness of
the container.

10
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

2.5 Approving Process

From the mitigation reports, the DevSecOps Approver can determine if the results warrant
approving the container. The four options are as follows: Rejected, Conditional Approval with
Time Limit, Conditional Approval, and Approved. Each option is explained in more detail
below.
• Rejected – The container has been reviewed and it was determined that it does not meet
DoD standards for DOD enterprise-wide distribution.
• Conditional Approval Time Limit – The container will be approved provided the
findings are remediated or mitigated within a configurable number of days, dependent
upon the organization directive.
• Conditional Approval – The container has been approved with current mitigations in
place.
• Approved – The container has been approved for distribution as is.

The Approver will reach a decision on each container via a process that depicts the number and
severity of findings from the reporting performed in Section 2.4. For example, if the number of
findings is high but most are high to low, the approver may reject the container altogether due to
the magnitude of findings. If the Approver determines a critical finding exists that is key to
keeping the DOD secure, the container may be rejected. Conversely, if the finding report dictates
that the container only has a few low to medium findings, the container may be approved in its
entirety.

The level of acceptable risk for cybersecurity findings that cannot be remediated at the time of
processing will be decided on a case-by-case basis. These will all be reviewed by the Iron Bank
or the PMO Authorizing Official (AO).

Regardless of the outcomes from the Approval process, all findings and recommendations are
shared with the mission partner or vendor. If a container is placed in the Approval Time Limit
process, the container is placed into a file with a trigger for rerun at X time and date. For any
containers approved, the following steps will be performed.

Table 2-4: Approved Container Deployment Process

Step Process Description Example Resource
1 The container is signed and checksum Container is signed with a DOD Hardener
is created. approved key and a checksum created
using SHA 256 or more.
2 Copy Helm/Operators and the Hardener
README/LICENSE file
3 Checksum and artifact storage Store checksum and public key Hardener
alongside artifact in Iron Bank.
4 Store Repo One files in DCAR as Store files and tag version as Hardener
preproduction. preproduction until CtF, at which time
it will be tagged as production.

11
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

Step Process Description Example Resource

5 Scripts used for automation Scripts used to automate deployment Hardener
or facilitate adoption must be stored
under a “scripts” folder.
6 Configuration files for containers Configuration files for specific Hardener
container configurations must be
stored under a “config” folder.
7 Helm charts and Kubernetes Operators Helm charts or Kubernetes operators Hardener
should be stored in Iron Bank and
Repo One to facilitate adoption.
8 Additional documentation along with Documentation necessary to Hardener
base container documentation accompany container must be copied
into both repositories under a
“documentation” folder.
9 README files Vendor or Hardener should provide a Hardener
README.md file within the subfolder
that includes the impact level for
which the container is intended.
10 Scan results Results from Scan tools will be copied Hardener
into compliance folders as HTML files
and placed into Iron Bank repository.
As Prisma/StackRox and Anchore are
widely available and can be run by
anyone, the scan results are NOT
considered FOUO.
11 Risk Management Risk Management documentation Hardener
created by the Hardener to document
findings, false positives, accepted
risks, and current container risk
posture will be stored in a subfolder
called “accreditation” in both
repositories.
12 Changelog Changelog will be added to both Hardener
repositories’ subfolders and updates as
appropriate.
13 Examples Examples can be added to support Hardener
container adoption. These will be
stored in an examples folder in both
repositories.
14 Licensing Each hardened container requires a file Hardener
that describes the licensing required to
run the container (LICENSE). This

12
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

Step Process Description Example Resource

information (including files) should be
duplicated in both repositories.
README.md will also indicate if a
product requires a commercial license.

Note: Ensure any changes to the Repo One folder are changed in Iron Bank as well. If a
Dockerfile changes, the new artifact must go through the hardening process again.

2.6 Automated Hardening

The hardening process should be fully automated. When a new release is detected by the
pipeline, files are automatically downloaded from the repository and the steps are automatically
run as listed in the prior process tables. The pipeline will be configured to search for updated
dependencies/binaries and automatically run these with the pipeline, as well as notify the team of
the build results. It is important for vendors and mission partners to note that files
(artifacts/binaries) will be pulled from their existing agreed sources; it is not acceptable to host
binary files on Repo One.

If a new CVE is detected in an upgrade, the build will stop and a manual assessment of the new
CVE will be conducted.

2.7 Third-Party Container Sharing

Third parties must provide complete Dockerfiles, download.json/yaml file, scripts, and config
files so new folder creation and ingestion into Repo One can take place. Binary container images
will not be accepted and Dockerfiles must be provided to replicate the build.

It is allowed to leverage binaries (as long as they are downloaded by the Download.json or
Download.yaml script) in Dockerfile for the application layer but the source of the Dockerfile
must be provided so the container can be rebuilt. The goal is to integrate existing Dockerfiles
into the DOD hardening process and Repo One so that new containers benefit from the same
automation.

2.8 Keycloak Integration

Keycloak provides a centralized, delegated administrative model and single sign-on (SSO)
capabilities to an organization. Keycloak leverages DOD Public Key Infrastructure (PKI) and
stores information about objects on the network and makes this information available for
administrators and users to find and utilize. Keycloak uses a structured data store as the basis for
a logical, hierarchical organization of directory information. For DOD access, organizations need
the ability to use the CAC as the principal card to enable physical access to buildings and
controlled spaces as well as access to the DOD computer network and systems.

As Keycloak is fully integrated with the DOD Active Directory Federation Services
(ADFS)/PKI, it is strongly recommended that any system operating in Impact Level 4 or higher
13
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

use Keycloak for any user authentication. For nonperson entity-to-entity communication, signed
x509 certificates and PKI should be used.

14
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

3. APPENDIX A: FOLDER STRUCTURE EXAMPLE

3.1 Inside Repo One DCCSCR

Figure 3-1: Example 1: Repo One DCCSCR
Oracle Vendor name
MySQL Product name
v.8.0 Product version
Dockerfile File using the base approved
image and hardening the
container by using Dockerfile
INSTRUCTIONS
README.md README file to describe the
container, warn if this a
commercial product or not,
etc.
Scripts Scripts folder (optional)
Script files .sh or other scripts
Config
Config files Configuration folder
(optional)
documentation Documentation folder
(optional)
PDF files
Compliance
SCAP or
OVAL files
Accreditation Accreditation folder (optional)
PDF files risk mgt. of the container
Examples Examples folder (optional)
Misc. files Documentation that shows
how to use the container
LICENSE License text file describing
license of the product; if
commercial, a POC must be
listed for vendor questions
Changelog Changes from previous
version
Download.yaml or Rpm or File listing everything to be
Download.json download downloaded from the internet
files to build the container; it can
include application binaries
v.5.7
Repeat Replicate structure as v.8.0
v.5.6
Repeat Replicate structure as v.8.0

15
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

3.2 Inside Iron Bank DCAR

Note: Bold font shows custom files created by CI/CD pipeline that are not present in REPO
ONE.
Figure 3-2: Example 2: Iron Bank DCAR
Oracle Vendor name
MySQL Product name
v.8.0 Product version
mysql-v.8.0-hardened- tar version of the hardened
container.tar container built
mysql-v.8.0-checksum checksum of the untar version
of the container
README.md README file to describe the
container, warn if this a
commercial product or not, etc.
Config Config folder optional
script files
documentation Documentation folder optional
PDF files
compliance Policy compliance folder
result files All HTML/PDF results from
container security scanners
accreditation Accreditation folder optional
PDF files Risk management files
examples Example folder optional
misc. files Documentation that shows how
to use the container
license License text file describing
license of the product; if
commercial, a POC must be
listed for vendor questions
changelog Changes from previous version
Helm charts or Kubernetes operators Containers can include Helm
charts and Kubernetes operators
to facilitate adoption.
v.5.7
repeat Replicate structure as v.8.0
v.5.6
repeat Replicate structure as v.8.0

16
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

4. APPENDIX B: DOD HARDENED CONTAINERS CYBERSECURITY

REQUIREMENTS
• Comply with initial and ongoing DOD Cybersecurity accreditation regulations/
frameworks.
o The container base OS image must be STIGed, assuming a STIG is available. If an
OS STIG is not available (Alpine, for example), use the generic UBI STIG or DOD
scratch or DOD distroless. Many of these STIGs were designed prior to the existence
of containers. If a specific hardening recommendation does not make sense for a
container (e.g., Install CAC library to a container that does not allow person entities
to connect using SSH), it is accepted to document these as nonapplicable.
o NIST 800-53v5 moderate controls plus FedRAMP+ IL 6 controls.
o Risk Management Framework (RMF) process and required documentation.
o Containers must be compliant with DISA STIGs that exist for container technology
and consistent with NIST SP 800-190.
• Documentation:
o Generate and automate necessary documentation for Risk Management.
▪ RMF Controls.
▪ Data Flows.
• Enable TLS on all PaaS tools that have UI or send data. HTTP will be redirected and
FIPS 140.2 used.
• Where personal-entity authentication and authorization are required, leverage DOD
ADFS CAC authentication.
• Whenever possible, prohibit processes and containers from running as root.

17
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

5. APPENDIX C: SECURITY CONTROL INHERITANCE

PaaS/Platform Host providers rely on technical concepts such as process isolation, service
routing, redundancy, firewall controls, and many other security layers. These typically align with
DOD security concepts “out of the box”. Security overlays should always be leveraged (STIG,
NIST 800-53, etc.). Ensure the selected host operating system has significant DISA STIG
involvement, including security guidance/standards where available.

Leverage hardened Infrastructure as Code and Configuration as Code from Repo One whenever
available to install various Kubernetes distributions supported by the Container Hardening team.

With a properly locked down hosting environment, containers inherit most of the security
controls and benefits from infrastructure to host OS-level remediation requirements. The focus
then shifts to container security requirements and application security requirements (e.g., static
code analysis, unit testing, library Common Vulnerabilities and Exposure [CVE] testing, etc.).

18
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

6. APPENDIX D: CONTAINER SECURITY/REMEDIATION CONSIDERATIONS

6.1 False Positives Commentary

The preferred approach to container security and remediation is to use tool standards such as
Palo Alto Prisma/StackRox, Anchore, OpenSCAP, etc. If an OpenSCAP scan returns
noncompliant result(s), always evaluate the validity of those findings. False positives are
common within major host OS-based containers, as the security profiles normally account for all
host-level controls potentially not applicable to a container build (e.g., GUI, CAC authentication,
etc.). In addition to false positives, many of the base OS STIG requirements are not applicable in
the containers either.

For false positives or nonapplicable items, there are two options: either remediate to force the
scanner to detect it as corrected or modify scanning profiles to mark specific components as
nonapplicable. For example, there are 363 configuration settings applicable to RHEL 7 base OS,
and 93 of these controls are not inherited and/or applicable. If any of the 93 controls need to be
remediated, 85 of them can be automated. Always automate all container-hardening processes
leveraging CI/CD pipelines whenever possible. Manual processes should be avoided if possible.
As stated previously, it is very important to select a proper base image. Refer to Section 2.1
Container Hardening Pre-Process Steps.

For example:
• If a container requires a base OS (such as RHEL/Alpine), the DoD hardened-base image
of these OSs must be used.
• If a container needs OpenJDK such as a Java application or a COTS product using Java,
the DOD OpenJDK base image must be reused whenever possible. This ensures that
hardening of JDK is centralized and consolidated across all containers by leveraging
inheritance with those base images.

For containers determined to be a true positive, always remediate when able.

19
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

7. APPENDIX E: VISUAL PROCESS FLOW

Figure 7-1: Visual Iron Bank Flow Diagram

7.1 Iron Bank Steps

1. Hardening/Dependency Download
a. Contributor updates application.
b. Contributor submits a feature branch to Gitlab. The branch will include the
Download.json, Dockerfile, ReadMe, and a license. Once the branch is ready, the
Contributor will submit a pull request to the Development Branch.
c. Iron Bank Container Hardeners will review the pull request with eyes on code. Once
the hardeners validate that the pull request meets criteria specified, they will approve
the pull request and merge the feature branch into the development branch.

20
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

d. The action of merging into the development branch will inform the CI server to start
orchestrating the pipeline.
e. The first CI Runner will have egress to the Internet. It will look at the Download.json
file to identify the components necessary to pull the contributors information into the
environment securely. Once in the environment signatures and checksums will be
validated to ensure providence.
f. Each item downloaded will be sent through a Clam AV scan. If there are threats
identified, the download will be quarantined.
g. If there are no threats detected, dependencies will be pushed into a private Container
Registry.
2. Build Container
a. After dependencies have been validated, the CI server will start another CI Runner
without any egress to perform the build operations.
b. The runner will connect to the Container Registry and pull down the scanned
dependencies.
c. The runner will build the contributor's container without Internet access.
d. After a successful build, the container will be pushed into the Container Registry
3. Evaluate Container
a. After a successful build, the runner will execute an OpenSCAP/InSpec,
Prisma/StackRox, and Anchore scans.
b. Results of the scans will be uploaded to the Vulnerability Assessment Tracker (VAT)
c. Contributor will connect to the VAT and justify any findings from the scans.
d. Iron Bank CVE Approvers will review all the justifications submitted and validate the
information as accurate and appropriate to satisfy the finding.
4. Approve Container
a. With the findings of the scans validated, the AO or the AO Designated Representative
(DR) will review the entire body of evidence and make the decision to approve the
container.
5. Publish Container
a. Once approved, the Vulnerability Assessment Tracker (VAT) will merge the
Development Branch into the Master Branch.
b. This will trigger the CI server to start a publish pipeline. Another CI Runner without
egress will be started to perform the actions.
c. The runner will pull the container in, sign the container, generate a checksum, and
pull the body of evidence.
d. The package will be pushed to multiple locations segregating the check sum and
public key from the container and body of evidence.
6. Deliver Container
a. The Iron Bank application will retrieve container information from the storage
location utilized by the VAT.
b. Users will be able to access the Iron Bank application and obtain the body of
evidence and containers.

21
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

c. Kubernetes clusters will have a container that connects to the Iron Bank or Registry
One (new container registry) authenticating with a machine-to-machine certificate
and synchronize containers.

22
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

8. APPENDIX E: CONTAINER BRANCHING STRATEGY

Figure 8-1: Container Branching Process

23
UNCLASSIFIED
 UNCLASSIFIED
Container Hardening Process Guide, V1R2 DISA
24 August 2022 Developed by DISA for the DOD

Figure 8-2: Process Flow

24
UNCLASSIFIED