Skip to content
ConfigurationAuthentication

Authentication

drydock requires authentication by default on fresh installs.

Since v1.4.0, drydock requires authentication on fresh installs. If no auth strategy is configured and no explicit anonymous opt-in is present, protected API requests return 401 Unauthorized; public auth discovery/status routes remain available so the login surface can explain the problem.

You can enable 1 or multiple authentication strategies using DD_AUTH_* env vars.

Authentication protects protected API routes and UI data unless anonymous access is enabled. Fresh installs and upgrades alike must opt in with DD_ANONYMOUS_AUTH_CONFIRM=true — without it, an instance with no auth configured starts fail-closed. Protected API requests return 401, auth discovery/status remains public, and /health returns 503. The SPA shell may still load, but it cannot read protected application data.
For OIDC setups, session-cookie policy is controlled by DD_SERVER_COOKIE_SAMESITE in server configuration. Default lax works for most IdP callback flows.

Login lockout controls

To limit brute-force attempts on POST /auth/login, drydock tracks failed logins per account and per client IP and can temporarily lock access when thresholds are exceeded. Per-account controls use DD_AUTH_ACCOUNT_LOCKOUT_*; per-IP controls use DD_AUTH_IP_LOCKOUT_*.

Env varRequiredDescriptionSupported valuesDefault value when missing
DD_AUTH_ACCOUNT_LOCKOUT_MAX_ATTEMPTSMax failed login attempts per account before temporary lockoutPositive integer (> 0)5
DD_AUTH_IP_LOCKOUT_MAX_ATTEMPTSMax failed login attempts per client IP before temporary lockoutPositive integer (> 0)25
DD_AUTH_LOCKOUT_WINDOW_MSRolling window (milliseconds) used to count failed login attemptsPositive integer (> 0)900000
DD_AUTH_LOCKOUT_DURATION_MSLockout duration (milliseconds) once a threshold is reachedPositive integer (> 0)900000
DD_AUTH_LOCKOUT_PRUNE_INTERVAL_MSInterval for pruning expired lockout entries from memory and the persisted lockout sidecar filePositive integer (> 0)60000
DD_AUTH_LOCKOUT_MAX_TRACKED_IDENTITIESMaximum number of unique account/IP identities tracked before older entries are prunedPositive integer (> 0)5000

If a lockout value is missing or invalid, drydock falls back to the corresponding default.

Currently, the following strategies are supported:

Anonymous access

On previous versions of drydock (and upstream WUD), the dashboard was accessible without any login. Starting with v1.4.0, anonymous access must be explicitly opted into on fresh installs.

DD_ANONYMOUS_AUTH_CONFIRM

Set DD_ANONYMOUS_AUTH_CONFIRM=true to explicitly allow anonymous (unauthenticated) access to the dashboard and API.

DD_AUTH_ANONYMOUS_CONFIRM=true is also accepted as an alias. DD_ANONYMOUS_AUTH_CONFIRM is the canonical name.

environment:
  - DD_ANONYMOUS_AUTH_CONFIRM=true

Behavior matrix

ScenarioResult
Fresh install, no auth configured, no DD_ANONYMOUS_AUTH_CONFIRMStarts fail-closed — protected API requests return 401; auth discovery/status stays public; /health returns 503
Fresh install, DD_ANONYMOUS_AUTH_CONFIRM=trueAnonymous access allowed
Upgrade, no auth configured, no DD_ANONYMOUS_AUTH_CONFIRMStarts fail-closed — protected API requests return 401; auth discovery/status stays public; /health returns 503
Upgrade, DD_ANONYMOUS_AUTH_CONFIRM=trueAnonymous access allowed

Drydock detects an upgrade by the presence of an existing store file (/store/dd.json). If the file exists, the install is treated as an upgrade; if it does not, it is treated as a fresh install.

Upgrading

Upgrades fail closed exactly like fresh installs — there is no more warn-and-continue grace period. If an upgrading instance has no authentication configured (or anonymous auth is enabled but not explicitly confirmed), the container runs while protected API requests return 401, auth discovery/status remains public, and /health returns 503. The SPA shell may still load, but it cannot read protected application data. This replaces the previous warning plus open dashboard.

To restore access, either:

  1. Configure authentication — set DD_AUTH_BASIC_<name>_USER and DD_AUTH_BASIC_<name>_HASH (or use OIDC).
  2. Explicitly opt in to anonymous access — set DD_ANONYMOUS_AUTH_CONFIRM=true.
This release also renames the session cookie (connect.siddrydock.sid), which signs out every existing session once on upgrade — Basic and OIDC alike. There's nothing to migrate; users just log back in.

Fail-closed auth enforcement

Since v1.4.0, drydock enforces fail-closed authentication across registries, triggers, and the Docker entrypoint. If auth is configured and fails, drydock raises an error instead of silently falling back to anonymous or unauthenticated access.

This affects three areas:

  • Registry bearer-token flows — When a token exchange endpoint returns an error (network failure, invalid credentials, expired token), the registry call fails immediately. In older versions (and upstream WUD), this would silently fall through to anonymous access, which could cause missed updates on private images or confusing inconsistencies between authenticated and unauthenticated results.
  • HTTP trigger auth — If an HTTP trigger specifies an unsupported auth type, the trigger errors instead of sending an unauthenticated request.
  • Docker entrypoint root mode — Running as root requires both DD_RUN_AS_ROOT=true and DD_ALLOW_INSECURE_ROOT=true. Setting only one flag fails closed at startup. See Docker Socket Security.

If you are upgrading from WUD or an earlier drydock version and see new auth errors, verify that your credentials are valid and that outbound HTTPS to the token endpoint is not blocked. The errors are intentional — they surface problems that were previously hidden.

Remember me

The login form includes a Remember me checkbox. When checked, the session cookie is extended to 30 days so the browser stays logged in across restarts. When unchecked, the cookie expires when the browser is closed (default session lifetime is 7 days).

Remember-me works with both Basic and OIDC authentication strategies. The preference is stored server-side in the authenticated session via POST /auth/remember.