Skip to main content

Linux Docker Policy

Updated today

The Linux Docker Policy in Swif lets you control which Docker images can run on Linux devices. You can explicitly allow trusted images and block risky or unwanted ones. This policy works on both company-owned and BYOD Linux machines.

What this policy does

When the Linux Docker Policy is applied to a device, Swif:

  • Checks Docker images that users try to run on Linux.

  • Compares them against your:

    • Allowed Docker Images list (whitelist)

    • Blocked Docker Images list (blacklist)

  • Enforces your rules so only compliant images are permitted.

This helps you:

  • Standardize which images are used in your environment.

  • Block known-vulnerable or unapproved images.

  • Reduce the risk of shadow IT and untracked containers running on devices.

Supported platforms

  • Operating system: Linux

  • Device types:

    • Company-owned devices

    • BYOD (Bring Your Own Device)

Key concepts

The policy manages two main lists:

  1. Allowed Docker Images (whitelist)

  2. Blocked Docker Images (blacklist)

Each list is made up of entries that describe Docker images using the same set of fields:

  • Repository (required for most patterns)

  • Tag (optional)

  • Image ID (optional)

You can use any combination of these to target the images you want to control.

Fields in the Linux Docker Policy

1. Allowed Docker Images (whitelist)

Field name: whitelist
​Label in UI: Allowed Docker Images
​Type: List of Docker image entries

Images listed here are explicitly allowed to run on Linux devices. Typical use cases:

  • Allow only official or internal images.

  • Permit specific versions of critical services.

  • Gradually roll out new image tags while blocking others.

Each entry in the whitelist can include:

Repository

  • Field name: repository

  • What it is: The full Docker image repository name to match.

  • Examples:

    • docker.io/library/nginx

    • ghcr.io/company/app

    • gcr.io/my-project/service-api

  • Usage tips:

    • Use the full path as shown in your Docker pull commands.

    • This is usually the main field you will configure.

Tag (optional)

  • Field name: tag

  • What it is: The Docker image tag to match.

  • Examples:

    • latest

    • 1.27

    • stable

  • Behavior:

    • If left empty, Swif will match any tag for this repository (or image ID).

    • Use it when you need to pin to specific versions or channels.

  • Usage tips:

    • Use immutable or versioned tags (e.g., 1.27.3) rather than latest when you need strict control.

Image ID (optional)

  • Field name: imageId

  • What it is: A specific Docker image ID or digest for an exact match.

  • Example:

    • sha256:abcd1234...

  • Behavior:

    • Use this when you require an exact image reference and want to avoid ambiguity across tags.

  • Usage tips:

    • Ideal for high-security workloads where you only trust a particular digest.

2. Blocked Docker Images (blacklist)

Field name: blacklist
​Label in UI: Blocked Docker Images
​Type: List of Docker image entries

Images listed here are blocked and restricted on Linux devices.

Typical use cases:

  • Block images with known vulnerabilities or malware.

  • Prevent usage of public images when you require internal registries.

  • Stop deprecated or insecure versions from running.

Each entry in the blacklist uses the same subfields as the whitelist:

  • Repository (e.g., docker.io/library/nginx)

  • Tag (e.g., 1.25, beta, latest)

  • Image ID (e.g., sha256:abcd1234...)

You can:

  • Block a specific repository (all tags),

  • Block a specific tag,

  • Or block a precise image digest.

Matching behavior and examples

You can mix and match the repository, tag, and imageId fields to fit your policy:

Example 1: Allow all tags from a trusted repository

  • Allowed Docker Images entry:

    • Repository: ghcr.io/company/app

    • Tag: (leave empty)

    • Image ID: (leave empty)

Effect: Any tag from ghcr.io/company/app is allowed.

Example 2: Allow only a specific version

  • Allowed Docker Images entry:

    • Repository: docker.io/library/nginx

    • Tag: 1.27

    • Image ID: (leave empty)

Effect: Only docker.io/library/nginx:1.27 is allowed. Other tags (e.g., latest, 1.26) are not allowed unless separately whitelisted.

Example 3: Block a risky tag

  • Blocked Docker Images entry:

    • Repository: docker.io/library/nginx

    • Tag: beta

    • Image ID: (leave empty)

Effect: docker.io/library/nginx:beta is blocked. Other tags remain allowed or subject to your other rules.

Example 4: Block an exact compromised image

  • Blocked Docker Images entry:

    • Repository: ghcr.io/company/app

    • Tag: (optional – can be empty)

    • Image ID: sha256:abcd1234...

Effect: That specific digest is blocked, even if the tag changes or is reused.

Best practices

  • Prefer internal registries or organization-controlled repositories in your whitelist.

  • Use specific tags or image IDs for sensitive workloads.

  • Regularly review and update your Blocked Docker Images list as new vulnerabilities are discovered.

  • Combine this policy with other Linux policies in Swif to maintain a strong device posture.

Related Articles
Linux Software Update Policy
Linux-specific MDM policies available in Swif
Installing Swif's Linux MDM via Package Manager
Linux Application Block Policy
Linux Firefox Extension Policy
Did this answer your question?