Hostmetrics example for k8s can be exploited for privilege escalation.

[petermajn]

What needs to be changed?

The documentation for important k8s components shows an example that mounts the whole hostfs from root /. This can be exploited in k8s to gain access to the kubeconfig and the credentials for the node to communicate with the k8s API. Using the principle of least privilege, it should only mount the absolutely necessary paths it need for its job. Right now, I don't know which these are, but can post an update once I figured that out.

What is the name + path of the page that needs changed? docs/kubernetes/collector/components.md#host-metrics-receiver

[svrnm]

Thank you for reporting this @petermajn

@open-telemetry/operator-approvers please take a look

[TylerHelmuth]

This would also be a problem with the helm chart: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/1c82d9fa4d86a324291a24f6b73b7d11274193a5/charts/opentelemetry-collector/templates/_pod.tpl#L166-L170

  {{- if .Values.presets.hostMetrics.enabled }}
  - name: hostfs
    hostPath:
      path: /
  {{- end }}

@dmitryax @jinja2 @povilasv this is there an alternative way we should be mounting the host metrics receiver?

[jinja2]

It should be okay to mount only certain paths from host filesystem. As a reference, the Splunk distro chart here mounts some select paths. We can update upstream with these, but I haven't checked if same set of scrapers are configured by the 2 charts. I doubt we can prune the list of host paths mounted further than the one linked, while still keeping it workable for different OSes.

I wonder if it would be possible to update the hostmetric receiver's documentation to list the sources of information for different scrapers, even just for linux would be great since one could find equivalent files on other systems. That would make it easier for users to customize which host fs path is mounted based on the scrapers/metrics they want.

Regarding access to kubelet's config/credentials being mounted in the container, taking the example of kubeadm being used to bootstrap a k8s cluster, the kubelet certs are in /etc/kubernetes/* directory. From a quick look at the hostmetrics receiver, it looks like the etc host path is used to get the os info. Users running linux nodes could make just the /etc/os-release path available for reading instead of the /etc/ directory to the collector. But this would be environment specific and we can't accommodate all possible paths in the chart. Other kubelet config can be found in /var/lib/kubelet/*. The hostmetrics receiver reads user info from the path /var/run/utmp, and I think that is the only info it reads from the var directory so mounting just that should be good enough.

[TylerHelmuth]

@jinja2 getting those specific mount-paths upstream would be great.

[petermajn]

I wonder if it would be possible to update the hostmetric receiver's documentation to list the sources of information for different scrapers, even just for linux would be great since one could find equivalent files on other systems. That would make it easier for users to customize which host fs path is mounted based on the scrapers/metrics they want.

I think that would be a good step. I am currently trying to figure out which paths are needed for which scrapers on linux. In principle that seems to work as long as the hostfs files are not symlinks.

[matej-g]

Hey folks, is there any updates on this one? cc @petermajn

[petermajn]

No further updates from my side. I did not find time to work on this unfortunately.

[svrnm]

All, is this something we can resolve here in docs or does this need fixes in the collector modules first? Do we need a disclaimer on the website around potential security concerns?

[svrnm]

help wanted, what needs to be done:

• figure out the absolute necessary paths that need to be mounted and verify with host metrics receiver component owner that this list is correct
• Update the documentation accordingly

As an alternative, a quick fix would be a note that highlights the risk of mounting the whole rootfs