I’m wondering if there is a way to constrain containers that are execute on the host from the host side.
I know using labels, I can restrict a service to execute on certain hosts, but what I’m looking for is a way to say that a host only accepts containers with a certain label. This would allow me to do some scheduling without having to add a specific label to each and every service definition.
The use case here is that I want to deploy a new host into my cluster, let’s say it’s a machine in AWS that I am providing a specific IAM profile to to allow access to certain resources.
I then want to specify a label on this host that would prevent any containers from running on it unless the the service had the matching label. This would prevent other services expect those explicitly whitelisted from being executed on the host and thus gaining the elevated IAM permissions from the host.
This inverse scheduling does not exist. You could open an issue on Github, but I would still recommend using the service to host scheduling via labels.
If you’re worried about services being scheduled on hosts with more IAM permissions, for those services you could use an anti-affinity rule and basically blacklist the ability to schedule service on the hosts with that label. You just need to make sure you add this label onto the host when added into the environment.
@denise that’s the exact situation I’m trying to avoid. By doing the scheduling from service labels then I would be required to have a label on EVERY container telling it to not run on a particular host.
This is not realistic. It begs for a situation where somebody forgets the label and then a service is exposed to a host it should never be on.
I think it’s definitely a need to have a way to say that a host will only accept services that have a matching set of labels, so if the labels are forgotten then you don’t accidentally get some scenario where a service is running where it shouldn’t be.