Nomad ACL Configuration: Defining Anonymous Token Permissions to Prevent Public Access

Answer: Capabilities that expose the cluster when granted to the anonymous token

When ACLs are enabled, any request without an X-Nomad-Token header is mapped to the anonymous token. If that token is given capabilities that allow reading or writing cluster state, unauthenticated users can access those APIs.

Confirmed risky capabilities

• job namespace with write, submit, or read – allows public job submission, modification, or listing.
• node namespace with read – exposes node metadata, attributes, and driver details.
• allocation, evaluation, deployment with read – leaks job placement, status, and scheduling information.
• agent or system with read – can reveal runtime configuration, runtime stats, or cluster health.

Granting any of the above to the anonymous token effectively makes those endpoints publicly accessible.

How to configure an empty capability set for the anonymous token

The safest approach is to ensure the anonymous token is bound to a policy that grants no capabilities. The exact method depends on your Nomad version:

1. Nomad ≥ 0.9 (anonymous token feature present):
   • Create an ACL policy file (e.g., anonymous-empty.hcl) with an empty capabilities block:

   # anonymous-empty.hcl
   anonymous "" {
     policy = ""
   }
   

   • Upload the policy: nomad acl policy apply anonymous-empty anonymous-empty.hcl
   • Bind the anonymous token to this policy (or leave it unbound, which results in an empty set):
     • If your version supports explicit binding: nomad acl token update -anonymous -policy-name=anonymous-empty
     • Otherwise, ensure the anonymous token has no policies assigned (check with nomad acl token list).
2. Nomad < 0.9 (no anonymous token):
   • Requests without a token are rejected by default when acl.enabled = true. No extra configuration is needed.

Important: Do not assign a policy that includes any of the risky blocks listed above, and avoid using a wildcard "*" policy for the anonymous identity.

Verification steps – confirming the anonymous token is effectively denied

Perform these checks after applying the empty policy:

1. Confirm ACLs are enabled and a management token exists:

nomad acl bootstrap
# note the management token

2. Test a sensitive endpoint without any token (expect denial):

curl -s -o /dev/null -w "%{http_code}" http://:4646/v1/jobs
# should return 403 or 401
curl -s -o /dev/null -w "%{http_code}" http://:4646/v1/nodes
# should return 403 or 401

3. Repeat the same calls with a valid management token (expect success):

curl -s -H "X-Nomad-Token: " -o /dev/null -w "%{http_code}" http://:4646/v1/jobs
# should return 200
curl -s -H "X-Nomad-Token: " -o /dev/null -w "%{http_code}" http://:4646/v1/nodes
# should return 200

4. Optionally inspect the anonymous token directly:

nomad acl token list
# find the token with Accessor ID "anonymous" and verify Policies list is empty

If any of the unauthenticated calls return a 2xx response containing job specs, node attributes, allocation details, etc., the anonymous token still possesses excessive capabilities and must be tightened.

Missing diagnostic detail

To give a version‑specific recommendation, please confirm the exact Nomad OSS/Enterprise version you are running (e.g., nomad version output). The policy binding syntax differs between releases.