Whitelist vs blacklist for security options

[jellevandenhooff]

I wonder if the security options introduced in #970 and #978 would be better as whitelists instead of blacklists. Since those features haven't been released yet, right now seems the time to consider changing them. With blacklists, I worry that it is too easy to accidentally miss a bad option and open an accidental security hole. The downside of whitelists is that they require more effort, but that effort might just be worth it in a security context.

[dadgar]

Hey, I am glad you are that actively engaged in Nomad 👍 So we gave this some thought and we think the blacklist approach for this will work for users and env vars because there is a small subset of things you don't want to allow (privileged users and secrets/tokens). These are both specific to the environment and known in advance so an operator can have one config on all machines.

For users is also nice that the operator can create new, unprivileged users and not have to worry about updating the config and restarting the Nomad client.

[jellevandenhooff]

Glad to hear you're thinking about the right problems :)

My concern with the blacklist approach is that most operators will never setup the blacklist properly. I agree that an operator could likely come up with a single blacklist that works across all nodes in a cluster environment. However, I worry that because the default configuration allows almost everything, jobs will just work with Nomad and operators won't ever think about or modify the blacklist and forget to blacklist an important secret.

You could argue that for those users the default blacklist covers enough of the dangerous variables that secrets will be safe in most environments. But you can turn that argument around and conclude instead that a default whitelist would cover most important variables to make the out of the box setup work without friction for almost all environments. With that in mind, I think the failure mode of having to change a configuration file to get an application to start is much better than the failure mode of having a secret leak into a compromised container.

The use case of creating new users without restarting the agent is something I haven't thought about too much. I would imagine most production environments to run with a static set of users, with operators SSH-ing to machines to dynamically generate users. However, if you have some system that generates new users for different jobs, I could imagine a whitelist that specifies a pattern on allowed usernames, like allow job-*.

Your call, of course, but those are my 2 cents.

[dadgar]

Your points are 100% valid don't get me wrong. There are just multiple factors at play. The blacklist gives the operator full control because the environment variables of Nomad should be fairly static as you will deploy it in your upstart script. Further operating systems and libraries are rather annoying and rely on specific environment variables existing. This results in application failures that are incredibly hard to debug and hurt the UX of operating inside a cluster manager because people are used to their application inheriting env vars.

[jellevandenhooff]

Fair enough, and for the extra-cautious, running with env -i seems like a fine workaround.

[ikryten]

Can this be revisited? Currently having to use CM to generate a blacklist of hundreds of accounts. Not very pretty.

[dadgar]

@ikryten Yeah we would accept a PR

[ashald]

Probably the same as #2158.

@dadgar I'd do a PR. How would you like it done? An extra option next to an existing one? If yes, then how we should handle cases when both lists are present (and a suer mentioned in both of them)?
Or we should aim to merge this by the time for next "major" release and change it to 2 options likes users and mode where mode is either whitelist or blacklist?

[dadgar]

@ashald Thanks for tackling those. I think we can keep both and document that if both are specified the whitelist is preferred.

[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.