Security in shared environments

[collimarco]

I am building a Rails application that manages different K8s clusters for different customers.

Basically the Rails application works like this:

1. The tenant writes some YAML files for configuring his own cluster
2. The Rails app connects to the cluster of the customer and applies the new configuration

Is it safe to use this gem for this use case?

Example:

• Can a malicious YAML file passed to this gem produce file access, environment variables access, arbitrary code execution, etc. on the server that makes the API call to K8s?
• Can a malicious K8s response to a request made by this gem cause similar security issues?

It would be useful to document whether this gem is appropriate or not to be used in shared / multi-tenant environments with untrusted inputs (YAML configuration, etc).

Thanks in advance

[cben]

Have you seen the readme section about config security?

File access (EDIT: and arbitrary command execution!) can be disabled (at the cost that configs referencing external certs etc. won't work).

We've closed a yaml deserialization hole before. We use safe_load now but hard to be 100% certain there are no other holes... More fundamentally, malicious config can cause various http requests not necessarily to the cluster - e.g. can trivially set up MITM - so you might leak data, both on connect and later (e.g. you create a Secret => mitm attacker now knows it); generally it's hard to recommend...

[cben]

If your use case takes zero inputs from your server, all data comes from customer, then its maybe ok, as in a customer can only attack themselves. But there's still quesdion of isolation between customers. If you run them all from same ruby process, that's up to ruby bugs (and side channels)... IMHO cluster credentials are too sensitive for that, if you can say run a per-customer container that feels better. [disclaimer: i'm not an security professional]

[collimarco]

Thanks for the reply.

Our use case: if a customer defines a YML file from our dashboard, we will apply that to the customer K8s cluster.

Said that:

• If we send the YML with an HTTP request (REST API) directly to K8s, there isn't any security issue.
• Now I just wonder if this library is like a wrapper of the K8s rest api, and thus is safe, or if it does something more, something strange, like env variable interpolation or execution of YML, that can be a security issue.

Let's see each point in your answer:

malicious config can cause various http requests not necessarily to the cluster

This is not a security issue because the customer is exposing his own data (voluntary) to a different cluster or server.

so you might leak data

What data? The YML file is already owned by the customer. The only problem would be some kind of interpolation or variable loading made by this library on the YML config... But as you said it uses safe_load.

isolation between customers. If you run them all from same ruby process, that's up to ruby bugs

Ok, this is out of scope... Obviously anything can have security bugs, including Ruby, OS, etc. but that is an entire different topic. You just need to apply the normal security patches when there's a CVE.

[collimarco]

It would be interesting to know more about this:

Config.new(data, nil) is better but Kubeclient was never reviewed for behaving safely with malicious / malformed config. It might crash / misbehave in unexpected ways... https://github.com/abonas/kubeclient#security-dont-use-config-from-untrusted-sources

I wonder what makes the original developer think that it might misbehave. A practical example would be interesting.