Container Considerations

Container Considerations

The release container is the fastest way to try HarrierOps Azure without installing a local binary.

It is also a different auth environment than your host.

When you run:

docker run --rm ghcr.io/harriersecurity/ho-azure:v1.2.0 help

that works because help does not need Azure credentials.

Live Azure commands need credentials inside the container.

What The Container Can See

The container can see:

• environment variables you pass into the container
• files already inside the image
• files or directories you mount into the container

The container cannot automatically see:

• your host Azure CLI login state
• your host ~/.azure directory
• local Terraform, OpenTofu, .env, or SDK auth files
• IDE token caches or shell profile exports

Docker isolation is doing what it is supposed to do. The container only gets the auth material you intentionally pass or mount.

Recommended Container Auth Path

For live Azure commands, the simplest container auth path is service-principal environment credentials:

docker run --rm \
  -e AZURE_TENANT_ID \
  -e AZURE_CLIENT_ID \
  -e AZURE_CLIENT_SECRET \
  ghcr.io/harriersecurity/ho-azure:v1.2.0 \
  whoami --subscription <subscription-id>

Set those variables in your shell first, then pass them through with -e.

HarrierOps Azure does not print those secret values in command output.

Azure CLI Login State

The release image is intentionally small. It includes the ho-azure binary and the runtime pieces needed to make HTTPS requests, but it does not include Azure CLI.

That means a local host login such as:

az login

does not automatically help the container.

Even if you mount ~/.azure into the container, V1 does not treat that as a supported live auth path unless Azure CLI is available and can issue a token. The normal local-binary path is still the cleanest way to reuse Azure CLI login state.

File-Backed Credential Sources

The v1.3 auth-source work adds ho-azure foundcredentials for identifying explicit environment and file-backed credential sources that HO-Azure can reuse without printing secrets.

That still will not make the container see host files by magic.

For a container to use a file-backed source, the operator will still need to mount the file into the container intentionally and select it explicitly with --auth <id>. The command reports metadata and usability, not secret values.

Practical Rule

Use the container when you want a quick, isolated runtime and you can pass credentials explicitly.

Use the local binary when you want HarrierOps Azure to reuse an existing host Azure CLI login without extra container setup.