Self-Hosted Worker — Security and Operator Responsibilities

This page is the security and deployment guidance that accompanies the OneWare Self-Hosted Worker. Read it before your first production deployment, and re-check it after each upgrade.

For installation and configuration, see Self-Hosted ONE AI Worker.

The worker's inbound API is not authenticated

This is a deliberate design decision, not an oversight. The worker is a backend compute component intended to run inside a network perimeter that you operate. Authentication, authorisation, transport encryption and rate limiting are provided by the perimeter you place in front of it.

If you cannot meet the network placement requirement below, do not deploy the worker. An internet-reachable worker allows anyone to submit jobs, consume your GPU capacity, and read or write job data.

Division of responsibility

The worker is designed to be operated by you, on your infrastructure. That gives you control over your data — and it also means part of the security boundary is yours. This table makes that split explicit.

	ONE WARE GmbH is responsible for	You, the operating organisation, are responsible for
Software	Building the worker image, its dependencies and the embedded ONE AI runtime	Deploying only supported versions and applying updates
Supply chain	Dependency scanning, SBOM generation, vulnerability handling, advisories	Consuming advisories and acting on them
Vulnerabilities	Remediating product vulnerabilities within the published targets	Reporting suspected vulnerabilities to security@one-ware.com
Network exposure	Documenting the ports and protocols the worker uses	Preventing the worker from being reachable from untrusted networks
Authentication	Authenticating the worker's outbound calls to ONE WARE Cloud	All authentication and authorisation of inbound requests
Transport encryption	TLS for outbound communication	TLS termination for inbound traffic
Data at rest	— job data is not encrypted inside the container	Disk or volume encryption on the host
Host	—	OS patching, container runtime, isolation, monitoring, backups

Required network placement

This section is mandatory. Everything after it is strongly recommended.

The worker listens on TCP port 5000 with no authentication. Therefore:

1. Never publish port 5000 to the public internet.

2. Bind to a private interface. In Docker, publish to a specific address rather than to every interface:

ports:
  - "127.0.0.1:5000:5000"     # this host only
  # or
  - "10.0.0.12:5000:5000"     # a private network interface only

- "5000:5000" binds to all interfaces. On a host with a public IP address, that exposes the worker to the internet.

3. Put an authenticating reverse proxy in front of it if anything beyond the host must reach it. The proxy should terminate TLS and authenticate every request — mutual TLS, a bearer token, or your existing gateway — before forwarding.

4. Restrict outbound traffic to what the worker actually needs: https://cloud.one-ware.com, oneware.azurecr.io and DNS. It does not need general internet access.

5. Use a dedicated network segment rather than a flat network shared with unrelated workloads.

One worker per trust domain

The worker has no tenant isolation. Every job it receives is treated as equally trusted, and all jobs share the same filesystem paths and the same GPU context.

Run a separate worker deployment for each group of users who should not be able to see each other's datasets or models.

Running the worker safely

Non-root execution

Current worker images run as a fixed unprivileged account, UID/GID 10001. Do not override this with user: root.

If you bind-mount a host directory instead of using a named volume, set its ownership to match, or the worker cannot write to it:

sudo chown -R 10001:10001 /path/to/worker-data

The UID is fixed deliberately, so you can set this once and it stays valid across image updates.

Container hardening

cap_drop:
  - ALL
security_opt:
  - no-new-privileges:true

Do not run the container with --privileged. GPU access does not require it — use your container runtime's device support instead.

Scope GPU access

Grant access to the GPUs the worker should use, rather than to all devices:

deploy:
  resources:
    reservations:
      devices:
        - driver: nvidia
          device_ids: ["0"]      # instead of count: all
          capabilities: [gpu]

Keep the host NVIDIA driver and container toolkit patched. They run with kernel privileges and are outside the worker image.

Set resource limits

Because the worker itself does not authenticate inbound requests, a fault or a mistake upstream can exhaust the host. Set memory and CPU limits on the container so a runaway job degrades one worker rather than the whole machine.

Data handling

• Job data is not encrypted at rest by the worker. Datasets, trained models and intermediate artifacts are written in the clear to /app/selfhost_projects. If that data is sensitive, enable full-disk or volume encryption on the host.
• Job data persists until you remove it. Define your own retention and deletion schedule for the worker's project directory.
• Logs may contain file paths, job identifiers and model metadata. Treat worker logs as internal and apply your own access controls and retention.
• Backups inherit the sensitivity of the data they contain, and should be encrypted and access-controlled accordingly.

Verify what you deploy

• Pull images only from oneware.azurecr.io. Do not use third-party rebuilds.
• Pin an explicit version tag in production, for example oneware-worker-selfhost:1.6.14.172. Avoid latest — you cannot tell what you are running, and you cannot reproduce it during an incident.
• Pin by digest (@sha256:...) where your tooling supports it.
• Record the deployed version. You will need it to decide whether a security advisory affects you.

A software bill of materials (SBOM) is produced for every release, covering the .NET packages, the base image, the embedded Python/ONE AI environment and the CUDA/ML libraries. Request it from security@one-ware.com if you need it for your own vulnerability management.

Verify the image signature

Worker images are signed at publication using cosign keyless signing. There is no public key to distribute or rotate — the signature is bound to the GitHub Actions workflow that built the image.

cosign verify \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github\.com/one-ware/OneWare\.Cloud/\.github/workflows/publish-selfhost-worker\.yml@' \
  oneware.azurecr.io/oneware-worker-selfhost:<version>

If verification fails, the image was not published by ONE WARE's release pipeline. Do not run it — contact security@one-ware.com.

Images are signed by digest, so a signature always attests to specific content rather than to a tag that could be repointed later.

Updates

Security updates are delivered as updated container images. There is no in-place auto-update — the worker will not update itself, and pulling and redeploying is your responsibility.

What ONE WARE does

• Publishes security advisories.
• Notifies known deployment contacts directly for High and Critical issues.
• Provides security updates free of charge during the support period.

What you should do

• Subscribe to the advisory channel, and give us a monitored contact address so direct notification can reach you.
• Redeploy promptly after a security release. Suggested targets: Critical within 72 hours, High within 7 days.
• Re-check this page's configuration guidance after each upgrade.

Deployment checklist

• Port 5000 is not reachable from the internet.
• Inbound access is authenticated, or restricted to a trusted network path.
• TLS terminates in front of the worker for any non-loopback traffic.
• Outbound traffic is restricted to ONE WARE Cloud, the registry and DNS.
• The worker serves a single trust domain.
• The container runs as UID 10001, not root, and not --privileged.
• Bind-mounted directories are owned by 10001:10001.
• Capabilities dropped and no-new-privileges set.
• GPU access scoped to the intended devices.
• Memory and CPU limits set.
• Host disk or volume encryption enabled if job data is sensitive.
• A specific image version — ideally a digest — is pinned, not latest.
• The deployed version is recorded.
• A monitored contact address has been given to ONE WARE for advisories.
• Host OS, container runtime and GPU driver are on a patch schedule.
• Log retention and access controls are defined.

Reporting a security problem

Report suspected vulnerabilities to security@one-ware.com with the subject Security. Please do not open a public issue. See Product Security for the full policy.

If you believe a worker you operate has been compromised, isolate it from the network first and preserve the container and host logs, then contact us — after a redeploy those logs are usually the only evidence left.