Docker Enterprise 2.x Linux/UNIX STIG

Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide

The Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (V2 R2) has 101 STIG checks. New to STIG checklists? Read What is a STIG checklist?, CKL vs CKLB, and STIG vs SCAP benchmark.

Find STIG checks

101STIG checks

Search filters this STIG's checks locally. Separate terms must all match (use quotes for an exact phrase). A search you ran on the Search page carries over here.

Severity

Version

V2 · R2

CurrentPublished Wed Jul 24 2024 What changed in V2R2

A policy set using the built-in role-based access control (RBAC) capabilities in the Docker Trusted Registry (DTR) component of Docker Enterprise must be set.

Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide

Assessment Title

Rule Text

A policy set using the built-in role-based access control (RBAC) capabilities in the Docker Trusted Registry (DTR) component of Docker Enterprise must be set.

Description

Discussion Text

Both the Universal Control Plane (UCP) and DTR components of Docker Enterprise leverage the same authentication and authorization backplane known as eNZi. eNZi provides UCP and DTR with role-based access control functionality to enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. These policies are defined in the System Security Plan along with organization information, application user roles, system resources and access requirements. The eNZi backplane includes its own managed user database, and also allows for LDAP integration in UCP and DTR. While role-based access control mechanisms are provided regardless of whether or not LDAP integration is enabled, it is recommended to enable LDAP integration to better meet the requirements of this control.

Satisfies: SRG-APP-000033, SRG-APP-000243, SRG-APP-000246, SRG-APP-000247, SRG-APP-000267, SRG-APP-000328, SRG-APP-000340, SRG-APP-000342, SRG-APP-000378, SRG-APP-000380, SRG-APP-000384, SRG-APP-000038, SRG-APP-000039, SRG-APP-000080, SRG-APP-000311, SRG-APP-000313, SRG-APP-000314

New to STIG checklists? Read What is a STIG checklist? and CKL vs CKLB.

Objective

V-235782

Rule

SV-235782r960792_rule

Severity

medium

Rule Version

DKER-EE-001180

Documentable

false

IA Controls

NIST SP 800-53

Rev 5

Assessment Procedure

Check Text

This check only applies to the DTR component of Docker Enterprise.

Verify that the organization, team and user permissions in DTR are configured per the System Security Plan (SSP). Obtain and review SSP. Identify organization roles, teams and users.

via UI:

As a Docker EE Admin, navigate to "Organizations" and verify the list of organizations and teams within those organizations are setup per the SSP. Navigate to "Users" and verify that the list of users are assigned to appropriate organizations, teams and repositories per the SSP. 

If the organization, team and user permissions in DTR are not configured per the SSP, this is a finding.

via CLI:

Linux (requires curl and jq): As a Docker EE admin, execute the following commands on a machine that can communicate with the DTR management console:

AUTHTOKEN=$(curl -kLsS -u <username>:<password> "https://[dtr_url]/auth/token" | jq -r .token)

Execute the following command to verify that the teams associated with an organization have access to the appropriate repositories per the System Security Plan:

curl -k -H "Authorization: Bearer $AUTHTOKEN" -X GET "https://[dtr_url]/api/v0/accounts/[org_name]/teams/[team_name]/repositoryAccess"

Execute the following commands on a machine that can communicate with the UCP management console to verify that the members of the team with access to these repositories is appropriate per the SSP:

AUTHTOKEN=$(curl -sk -d '{"username":"[ucp_username]","password":"[ucp_password]"}' https://[ucp_url]/auth/login | jq -r .auth_token)
curl -sk -H "Authorization: Bearer $AUTHTOKEN" https://[ucp_url]/accounts/[orgNameOrID]/teams/[teamNameOrID]/members

If the organization, team and user permissions in DTR are not configured per the SSP, this is a finding.

Implementation Procedure

Fix Text

This fix only applies to the DTR component of Docker Enterprise.

Verify that the applied organization, team and user permissions in DTR are configured per the SSP.

via UI:

As a Docker EE Admin, navigate to "Organizations" and setup the list of organizations and teams within those organizations per the requirements set forth by the SSP. Navigate to "Users" and assign users to appropriate organizations, teams and repositories per the SSP. 

via CLI:

Linux (requires curl and jq): As a Docker EE admin, execute the following commands on a machine that can communicate with the DTR management console:

AUTHTOKEN=$(curl -kLsS -u <username>:<password> "https://[dtr_url]/auth/token" | jq -r .token)

Execute the following command to give teams in an organization access to the appropriate repositories per the System Security Plan:

curl -k -H "Authorization: Bearer $AUTHTOKEN" -X PUT "https://[dtr_url]/api/v0/repositories/[namespace]/[reponame]/teamAccess/[teamname]"

Execute the following commands on a machine that can communicate with the UCP management console to add/remove members to/from the team with access to these repositories as appropriate per the SSP:

AUTHTOKEN=$(curl -sk -d '{"username":"[ucp_username]","password":"[ucp_password]"}' https://[ucp_url]/auth/login | jq -r .auth_token)

Add: curl -sk -H "Authorization: Bearer $AUTHTOKEN" -X PUT https://[ucp_url]/accounts/[orgNameOrID]/teams/[teamNameOrID]/members/[memberNameOrID]
Remove: curl -sk -H "Authorization: Bearer $AUTHTOKEN" -X DELETE https://[ucp_url]/accounts/[orgNameOrID]/teams/[teamNameOrID]/members/[memberNameOrID]

STIG check 8 of 101 in the Docker Enterprise 2.x Linux/UNIX STIG checklist

← Previous · V-235781A policy set using the built-in role-based access control (RBAC) capabilities in the Universal Control Plane (UCP) component of Docker Enterprise must be configured.Next · V-235783 →Docker Enterprise sensitive host system directories must not be mounted on containers.