Limit metadata service

Rancher 1.x
1

been playing with the meta dataservice within a container, and it strikes me as very odd (and insecure) that a container can get all the information it needs about all other services and containers

surely a container should only see information about itself and it’s service ?

Is there any way of limiting the metadata service to only returning information about it’s service / stack , or turning it off altogether ?

Any user with shell access (or even curl access) can get all the information about the entire rancher deployment at the moment

1 Like
2

That would break many use-cases and existing catalog templates. The scope for user’s access control and metadata is an environment.

What specifically do you think is in metadata that should be secret, and can’t be easily obtained from e.g. port-scanning the overlay network subnet (10.42/16)?

3

Hi Vincent, I would have thought that adding an option to disable metadata would not break any existing use-case (default is current behaviour, “disabled” is turned off entirely “service” and “container” only data valid for that service/container)

apart from that, any metadata, labels or names from every other service are easily obtainable - for example I’ve seen use-cases where people pass in credentials as labels - for example, the labels

labels:
_ io.rancher.container.create_agent: true_
_ io.rancher.container.agent.role: environment_

generate variables CATTLE_URL, CATTLE_ACCESS_KEY, and CATTLE_SECRET_KEY

if these can be grabbed by another container by simply querying the metadata of all containers I would imagine this to be a potential security threat

Quite apart from that, I don’t want a developer to know about the containers, services and names of every other user / developer on the system

4

Environment variables are not included in metadata. Credentials are often provided with environment variables, yes, and those labels request the creation of a set of them to be provided as environment variables. Those credentials let you do nothing more than you already could already do directly if you have the ability to create a container (with those labels set) in the first place.

Access control is at the environment level. If you want users isolated from each other they need separate environments, which will have separate sets of metadata.

5

not exposing the env vars is a good thing :wink:

I still feel, though, (and feel free to flame) that it would be a good thing to be able to restrict the meta-data service to self at the very least …

it’s like when someone sends a group email, and puts everyones email in the to field, rather than bcc’ing them. Whilst not actually a disaster, it feels … wrong …