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.
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.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 var | Required | Description | Supported values | Default value when missing |
|---|---|---|---|---|
DD_AUTH_ACCOUNT_LOCKOUT_MAX_ATTEMPTS | ⚪ | Max failed login attempts per account before temporary lockout | Positive integer (> 0) | 5 |
DD_AUTH_IP_LOCKOUT_MAX_ATTEMPTS | ⚪ | Max failed login attempts per client IP before temporary lockout | Positive integer (> 0) | 25 |
DD_AUTH_LOCKOUT_WINDOW_MS | ⚪ | Rolling window (milliseconds) used to count failed login attempts | Positive integer (> 0) | 900000 |
DD_AUTH_LOCKOUT_DURATION_MS | ⚪ | Lockout duration (milliseconds) once a threshold is reached | Positive integer (> 0) | 900000 |
DD_AUTH_LOCKOUT_PRUNE_INTERVAL_MS | ⚪ | Interval for pruning expired lockout entries from memory and the persisted lockout sidecar file | Positive integer (> 0) | 60000 |
DD_AUTH_LOCKOUT_MAX_TRACKED_IDENTITIES | ⚪ | Maximum number of unique account/IP identities tracked before older entries are pruned | Positive 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=trueBehavior matrix
| Scenario | Result |
|---|---|
Fresh install, no auth configured, no DD_ANONYMOUS_AUTH_CONFIRM | Starts fail-closed — protected API requests return 401; auth discovery/status stays public; /health returns 503 |
Fresh install, DD_ANONYMOUS_AUTH_CONFIRM=true | Anonymous access allowed |
Upgrade, no auth configured, no DD_ANONYMOUS_AUTH_CONFIRM | Starts fail-closed — protected API requests return 401; auth discovery/status stays public; /health returns 503 |
Upgrade, DD_ANONYMOUS_AUTH_CONFIRM=true | Anonymous 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
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:
- Configure authentication — set
DD_AUTH_BASIC_<name>_USERandDD_AUTH_BASIC_<name>_HASH(or use OIDC). - Explicitly opt in to anonymous access — set
DD_ANONYMOUS_AUTH_CONFIRM=true.
connect.sid → drydock.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
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=trueandDD_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.