feature - metadata authorization

[rbucker]

if I have a farm of workers call them 'A' and another farm of workers 'B'....(both sharing the same etcd cluster) if a user logged into one of the 'A' nodes the user should not be able to create a fleet target for node of type 'B'.

[mischief]

there's not really any concept of identity, so how would that work?

an alternative might be to use different etcd key prefixes.

[rbucker]

I thought the metadata was baked in with the cloud-config? If the metadata in the cloud-config does not match the metadata in the fleet unit file then do not let the fleet command complete.

[mischief]

someone could still sidestep fleet and poke a systemd unit directly into etcd, easily bypassing this check of the metadata of the caller.

what would this metadata check even look like? how would normal metadata be differentiated from this 'authorization metadata'?

[rbucker]

the only way someone should be able to sidestep the cloud-config metadata setting would be to have root or equivalent permissions. To be clear I'm trying to prevent fleet from launching a service on a machine who's metadata does not match the origin? Systemctl launches services on the local machine not across the net to a remote system.

if on the etcd cluster then send any fleet command to any nodes in the worker domain.
if in worker domain A then only launch fleet commands in domain A.
if in worker domain B then only launch fleet commands in domain B.
Never in domain A and launching in B.