4 ms·

I was just playing with Grafana a few days ago, their cloud version. When you install agent, it opens up ports with unprotected metrics on a public IP. Opens up

by comboy 6y ago

I was just playing with Grafana a few days ago, their cloud version. When you install agent, it opens up ports with unprotected metrics on a public IP. Opens up ports on your production without info about it whatsoever, because it is in theory a push agent. Why would you do that? Support response: "Regarding your second message about port 12345 on the Grafana Agent -- the HTTP server only exposes the Agent's internal metrics and provides an API for the Agent's status. The gRPC server is used for agents to communicate with one another, if the scraping service is used. It does not allow anyone to get access to their metrics. That said there's we understand the concern and upon review will look at documenting that agents listen on 0.0.0.0 by default, and that you can change it by setting http_listen_address and grpc_listen_address in the Agent's server config to 127.0.0.1: (...)" Also, sometimes I feel like I'm the only person in the world who is not comfortable in running tons of untrusted docker containers. If I put a link to a binary here and tell you to run it, I doubt any HN reader would. But 400MB of binaries? No worries, I have just the right tools to run them as root.

kevinsundar 5y ago
Not sure what your comment about docker containers is trying to say. In docker you need to specify port mappings before ports are exposed outside the container, so this wouldn't happen without you explicitly knowing. Containers are by default untrusted and access to network and filesystem is mediated. In fact, if you linked to a docker container I'd have less qualms running than a binary.
- comboy 5y ago
  Yes, you have and that is reasonable. It is assumed that it is safely contained environment that cannot maliciously affect your host system. Yet every virtualization and container solution we've seen so far had been exploited. "But is there a vulnerability at the moment that can be exploited?" "None that we know of" Containers also often get generous access rights and internet access, even assuming container solution being intact. Security of the system inside is a whole big surface of attack that you have little control of (unless you meticulously analyze each docker full fucking system image every time you run them), and necessarily affects your systems because otherwise you would have no use for this container. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=docker https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=docker
- takeda 5y ago
  The filesystem is restricted, but network generally not. You can have a malicious container connect to rest of your network. The ports don't need to be open either, it can phone home (like how most bots do). Certain data centers restrict access to outside network (i.e. Internet), with now popular public cloud. It's actually hard to place such restriction, because majority tooling, including official images are expecting to be connected outside.

by comboy 6y ago

kevinsundar 5y ago

Not sure what your comment about docker containers is trying to say. In docker you need to specify port mappings before ports are exposed outside the container, so this wouldn't happen without you explicitly knowing. Containers are by default untrusted and access to network and filesystem is mediated. In fact, if you linked to a docker container I'd have less qualms running than a binary.

comboy 5y ago
Yes, you have and that is reasonable. It is assumed that it is safely contained environment that cannot maliciously affect your host system. Yet every virtualization and container solution we've seen so far had been exploited. "But is there a vulnerability at the moment that can be exploited?" "None that we know of" Containers also often get generous access rights and internet access, even assuming container solution being intact. Security of the system inside is a whole big surface of attack that you have little control of (unless you meticulously analyze each docker full fucking system image every time you run them), and necessarily affects your systems because otherwise you would have no use for this container. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=docker https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=docker
takeda 5y ago
The filesystem is restricted, but network generally not. You can have a malicious container connect to rest of your network. The ports don't need to be open either, it can phone home (like how most bots do). Certain data centers restrict access to outside network (i.e. Internet), with now popular public cloud. It's actually hard to place such restriction, because majority tooling, including official images are expecting to be connected outside.