Nomad UI Stop Button Works without ACL's if ACL's aren't enabled.

[hvindin]

If you have a question, prepend your issue with [question] or preferably use the nomad mailing list.

If filing a bug please include the following:

Nomad version

Nomad v0.8.3+ent (ab6f867)

Operating system and Environment details

$ cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.2 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="7.2"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.2 (Maipo)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.2:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.2
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.2"

Issue

When accessing the nomad UI with ACL's disabled the "stop job" button is available.

Clicking the stop job button displays an error message saying that I do not have sufficient ACL permissions, but the job is then stopped and becomes un-registered from the consul cluster.

Reproduction steps

Configure nomad with the ui enabled (and consul and all that jazz if you want to), enable some sort of proxy to point to the UI (ie. an nginx on a seperate box proxying to give visibility to the UI)

Click the stop job button.

Watch the jobs disappear from consul despite the error saying that you do not have permission.

[DingoEatingFuzz]

Thanks for the bug report!

This has been fixed in #4319 and will go out with the next release. As it looks like you have already deduced on your own, the UI error message is shown in error. The job will still stop successfully with no unexpected side-effects.

[hvindin]

So, to clarify, if we make the UI available to unauthenticated users with ACL's turned off the expected behavior is that:

1. No error message will be displayed
2. The job will be stopped?

If that is the case is there any way to disable the stop button? We have setup a server which provides users with access to the nomad dashboard so they can see what's going on in the cluster, however due to the TLS requirements this dashboard needs to authenticate via the regular client certificate.

This was all basically fine because we could block potentially dangerous API endpoints by just including location blocks in nginx config like

location / {
  limit_except GET {
    deny  all;
  }
    proxy_ssl_certificate /etc/ssl/local/nomad/client.global.nomad.pem;
    proxy_ssl_certificate_key /etc/ssl/local/nomad/client.global.nomad.key;
    proxy_pass https://nomadui;
}

The implication of this change is that I'm either going to need to actually spend some time figuring out to ACL's thing 😞 or look into if there is any way to limit access based on the certificate provided for mutual authentication. (I've noticed in recent examples that a "cli" certificate is suggested which has no CN and no SAN's but is just signed by the right CA... so I'm wondering if there's some way to limit that).

Alternatively, is there any way to disable the "stop" button functionality?

[DingoEatingFuzz]

So, to clarify, if we make the UI available to unauthenticated users with ACL's turned off the expected behavior is that:

1. No error message will be displayed
2. The job will be stopped?

Yes, this is the expected behavior.

This was all basically fine because we could block potentially dangerous API endpoints by just including location blocks in nginx config like

The stop job button works by making a DELETE request, so something like this could still work in theory.

Alternatively, is there any way to disable the "stop" button functionality?

ACLs are essentially the way to disable the stop button. A good place to start with ACLs is the guide, which includes a section on the Anonymous Policy.

You would want to make the anonymous policy have read-only permissions. This way anyone who uses the UI and doesn't provide a more privileged token to use will not be able to stop jobs. You can also do things like block access to the servers and clients lists if that's desired.

[hvindin]

Ok, makes sense to me. We're essentially trying to make everything visible to everyone but just stop anyone making changes. So an anonymous policy with read only access to everything sounds like it''s definitely a good place to start, and it's probably better than having nginx hackery in place 👍

[hvindin]

@DingoEatingFuzz your advice has essentially closed this off form me. Temporary hack: nginx limitation on Delete requests. Proper solution: go implement ACLs.

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.