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

When ACLs are enabled in a Nomad cluster, the default deny policy protects resources, but the anonymous token can still be assigned a policy that grants certain capabilities. The goal is to ensure that the anonymous token does not inadvertently allow public read or write access to sensitive endpoints such as job submission or node metadata, especially when the cluster network may be exposed.

Uncertainty remains about which specific capabilities constitute a risk for public exposure and how the ACL block should express an empty or restrictive policy for the anonymous token. Clear guidance on the boundary between permissible anonymous access and unintended leakage is needed.

What capabilities, if granted to the anonymous token, would enable unintended public access to job submission or node details? How should the ACL block be configured to ensure the anonymous token possesses an empty capability set? Which API endpoints should be examined to confirm that the anonymous token is effectively denied?