Both namespaces and ACL policies can filter Nomad objects from an operator access. This can occasionally lead to confusion when a job with the same name is running in multiple namespaces. ACLs will filter the views down to objects that are accessible via the provided token (or the anonymous policy).
Depending on the size of your team and the details of your Nomad deployment, you may wish to control which features different internal users have access to. You can enforce this with Nomad's access control list (ACL) system.
Nomad starts with ACLs disabled by default, which means all features—read and write—are available to all users of the Web UI out of the box. Visit the Secure Nomad with Access Control collection to learn how to configure your Nomad cluster for ACLs.
Although the Web UI lets users submit jobs in an ad hoc manner, Nomad was deliberately designed to declare jobs using a configuration language. It is recommended to treat your job definitions, like the rest of your infrastructure, as code.
By checking in your job definition files as source control, you will always have a log of changes to assist in debugging issues, rolling back versions, and collaborating on changes using development best practices like code review.