running container as ContainerAdmin is unsafe; change the co

Error message

running container as ContainerAdmin is unsafe; change the container user, set task configuration to privileged or enable windows_allow_insecure_container_admin to disable this check

What it means

The Nomad Docker driver on Windows blocks running a container as ContainerAdmin (or as the default user when that resolves to ContainerAdmin) unless the task is explicitly privileged, an hyper-v isolation is used, or windows_allow_insecure_container_admin is set in the driver config. This guards against containers escaping isolation via administrator privileges on Windows hosts.

Source

Thrown at drivers/docker/driver_windows.go:30

)

// Currently Windows containers don't support host ip in port binding.
func getPortBinding(ip string, port string) nat.PortBinding {
	return nat.PortBinding{HostIP: "", HostPort: port}
}

var containerAdminErrMsg = "running container as ContainerAdmin is unsafe; change the container user, set task configuration to privileged or enable windows_allow_insecure_container_admin to disable this check"

func validateImageUser(user, taskUser string, taskDriverConfig *TaskConfig, driverConfig *DriverConfig) error {
	// we're only interested in the case where isolation is set to "process"
	// (it's also the default) and when windows_allow_insecure_container_admin
	// is explicitly set to true in the config
	if driverConfig.WindowsAllowInsecureContainerAdmin || taskDriverConfig.Isolation == "hyper-v" {
		return nil
	}

	if user == "ContainerAdmin" && (taskUser == "ContainerAdmin" || taskUser == "") && !taskDriverConfig.Privileged {
		return errors.New(containerAdminErrMsg)
	}
	return nil
}

View on GitHub (pinned to 482b49bf1a)

Solutions

Set a non-admin user in the task config: user = "ContainerUser" (or use an image whose default user is not ContainerAdmin)
Set task driver config privileged = true if admin rights are genuinely required
Use isolation = "hyper-v" in the task config
Explicitly accept the risk with the driver option windows_allow_insecure_container_admin = true in the client config

Example fix

// before
task "app" {
  driver = "docker"
  config { image = "mcr.microsoft.com/windows/servercore:ltsc2022" }
}
// after
task "app" {
  driver = "docker"
  user = "ContainerUser"
  config { image = "mcr.microsoft.com/windows/servercore:ltsc2022" }
}

Defensive patterns

Strategy: validation

Validate before calling

user := task.User
if user == "" { user = imageDefaultUser } // e.g. ContainerAdmin for many Windows images
insecure := driverConfig.WindowsAllowInsecureContainerAdmin
privileged := taskCfg.Privileged
if user == "ContainerAdmin" && !privileged && taskCfg.Isolation != "hyper-v" && !insecure {
    return fmt.Errorf("task would run as ContainerAdmin; set user=ContainerUser, privileged, hyper-v isolation, or windows_allow_insecure_container_admin")
}

Prevention

Explicitly set user = "ContainerUser" for Windows Docker tasks
Audit Windows images for ContainerAdmin defaults before deploying
Prefer hyper-v isolation for workloads that need elevated rights
Avoid windows_allow_insecure_container_admin unless the risk is accepted

When it happens

Trigger: Starting a Docker task on Windows where the image's default user or the task's `user` field is ContainerAdmin, task config `privileged` is false, isolation is not hyper-v, and the driver option windows_allow_insecure_container_admin is not true — detected in validateImageUser during task validation/start.

Common situations: Windows images (e.g. nanoserver/servercore variants) that default to ContainerAdmin; jobs migrated from Linux where root defaults were fine; upgrading Nomad after the safety check was introduced.

Related errors

AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04). Data as JSON: /api/errors/24ba44eb2f3cf484. Report an issue: GitHub.