Sign inSign up

phirumseng/knetrahub-pam-worker

By phirumseng

•Updated 7 days ago

KNetraHub Privileged Access worker: background jobs only, no HTTP endpoint.

Image
0

746

phirumseng/knetrahub-pam-worker repository overview

⁠phirumseng/knetrahub-pam-worker

Privileged Access worker — the background half of Privileged Access.

KNetraHub is a self-hosted IT operations portal: a Docker Swarm console, full-stack monitoring, work management, privileged access management, IP address management and a database workspace, behind one sign-in. It ships two ways — as a single monolith image, or as the split stack of one image per service that this image belongs to.

šŸ“– Documentation: https://sengphirum.github.io/KNetraHub/documentation⁠


⁠What this image does

Credential rotation/verification worker, grant and JIT expiry sweeps, due rotations, discovery scans, risk evaluation, signed audit checkpoints.

It bundles the server code of pam and nothing else, so the image carries only the module it is named after.

⁠How it works

Runs no HTTP listener at all. It claims work from a durable queue with FOR UPDATE SKIP LOCKED and, for the jobs that must run once cluster-wide, a lease that one replica holds at a time — so replicas cooperate instead of duplicating. On SIGTERM it stops claiming, finishes what it already holds and hands the rest back to the queue, which is why its stop_grace_period is generous.

⁠What it deliberately does not do

The ingress never routes to it and it answers no request. Losing it delays work; it does not fail a page load.

⁠Privileges

Runs unprivileged with cap_drop: [ALL] and nothing added back.

⁠Which image do I want

ImageServes HTTPRuns background jobsScale it with
knetrahub-pam-worker (this image)noyesjob volume
knetrahub-pam-api⁠yesnorequest load
knetrahub-app⁠yesyesnothing — it is one process

Scale this with job volume. The matching pam-api image handles the requests, and the two scale on completely different signals.

⁠Settings

Read straight from the stack file that deploys this service, so the list is what the image actually takes. Optional entries ship commented out.

VariableDefault
NUXT_DB_HOSTtimescaledbset
NUXT_DB_PORT5432set
NUXT_DB_NAMEknetrahubset
NUXT_DB_USERknetrahubset
NUXT_DB_PASSWORD_FILE/run/secrets/knetrahub_db_passwordset
NUXT_APP_REPLICAS2set
NUXT_MODULE_POOL_REPLICAS3set
NUXT_DB_POOL_MAX6set
NUXT_JWT_SECRET_FILE/run/secrets/knetrahub_jwt_secretset
NUXT_PAM_MASTER_KEY_FILE/run/secrets/knetrahub_pam_master_keyset
NUXT_PAM_RECORDING_SIGNING_KEY_FILE/run/secrets/knetrahub_pam_recording_signing_keyset
NUXT_PAM_CONNECTOR_SIGNING_KEY_FILE/run/secrets/knetrahub_pam_connector_signing_keyset
NUXT_PAM_WORKER_NAMEswarm-workerset

Anything ending in _FILE reads its value from that path instead, which is how the stack passes Docker secrets.

⁠Deploying it

This is one service of a stack, not a standalone container: it expects the portal database and its siblings on the same overlay network. Deploy it with the stack file that owns it rather than with docker run.

docker stack deploy -c docker/docker-compose.pam.yml knetrahub

Pin a tag or a registry for this one service with KNETRAHUB_PAM_WORKER_IMAGE, which the stack file reads:

export KNETRAHUB_PAM_WORKER_IMAGE=phirumseng/knetrahub-pam-worker:0.1.11

⁠Supported tags

  • latest — the most recent release
  • x.y.z (e.g. 0.1.11) — immutable release versions

Pin the version in production. A rollback needs a tag that does not move, and every image in the stack is released under the same version so the whole set can be pinned together.

⁠The rest of the stack

Each service is its own image, so one can be updated without restarting the others:

⁠License

Proprietary — Ā© Seng Phirum. All rights reserved.

Tag summary

Content type

Image

Digest

sha256:ef9604e5a…

Size

59.7 MB

Last updated

7 days ago

docker pull phirumseng/knetrahub-pam-worker