Nomad ACL Configuration for Read-Only Integration Testing

Question

The objective is to establish a testing environment for a Nomad integration that operates without production credentials, ensuring that the integration can query cluster state without the ability to modify workloads.

While Nomad supports namespace-scoped permissions, it is unclear how to strictly enforce a read-only boundary that prevents job submission and secret injection while still allowing the integration to verify job status and plan results. There is further uncertainty regarding whether the Nomad dev agent's default state allows for this level of granular permission testing without a full production-like ACL setup.

Can an ACL policy be defined to grant read-only access to a specific namespace while explicitly blocking job execution? How does the dev agent handle namespace isolation when ACLs are enabled for testing purposes? Is there a documented configuration to prevent accidental cross-namespace job submission during integration tests?

Tasadduq Burney · Answer

Read‑only ACL policy for a Nomad namespace

An ACL policy can grant namespace‑scoped read capabilities while explicitly omitting job submission and secret write permissions. The following structure reflects the likely configuration, with version‑dependent caveats noted.

Likely explanation

Define a policy that includes jobs.read, jobs.status, secrets.read, and nodes.read for a specific namespace path.
Omit jobs.submit, jobs.modify, and secrets.write to block job execution and injection.
Scope the policy to the integration test namespace using a path prefix (e.g., test-infra/) and avoid empty‑string or wildcard namespace assignments.

Confirmed facts

The nomad agent -dev command only enforces ACL policies when started with the -acl flag; without it, the default root token retains all capabilities.
Namespace isolation is achieved by binding the policy to a non‑empty, specific namespace path, which prevents accidental cross‑namespace job submission during integration tests.
ACL capability sets may vary between Nomad releases (e.g., 1.5.x vs 1.6+); the exact read‑only capability names should be validated against the target version.

Verification steps

Start the dev agent with ACL enforcement:
```
nomad agent -dev -acl
```

Create a read‑only policy file (read-only.hcl):

path "test-infra/*" {
  capabilities = ["jobs.read", "jobs.status", "secrets.read", "nodes.read"]
}

Apply the policy and derive a token:

nomad policy apply read-only read-only.hcl
nomad token create -policy=read-only

Test read access:

nomad job status -namespace=test-infra <token>

should succeed.

Test job submission denial:
```
nomad job run -namespace=test-infra <token>
```
should be rejected with an ACL denial error.

Diagnostic detail needed: Which Nomad version are you targeting? Capability names and behavior differ between major releases, and the recommendation may change based on the version-specific ACL schema.

Nomad ACL Configuration for Read-Only Integration Testing

1 answer

Read‑only ACL policy for a Nomad namespace

Likely explanation

Confirmed facts

Verification steps

Your perspective belongs here.

0 question comments