Reason for insecureSkipTLSVerify in APIService

[etherandrius]

Currently (v0.3.6) APIService v1beta1.metrics.k8s.io enables insecureSkipTLSVerify: true

If we disable it we are not able to retrieve any metrics.
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)

1. Why is it necessary to enable insecureSkipTLSVerify ?
2. Why is this not a security issue ?

The manifest in question:

apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100

/triage support

[serathius]

Thanks for asking this question. If your interested in security of metrics server I would really appreciate your feedback about current configuration, options and documentation available. It would be really great if we could improve things.

Ad 1
Requests for metrics in k8s (e.g. kubectl top) are sent to apiserver which proxies them to Metrics Server. This is done via kubernetes api agregation (https://github.com/kubernetes/kube-aggregator). insecureSkipTLSVerify controls if apiserver should validate certificate served by Metrics Server.

Disabling this flag would require users to generate certificates to Metrics Server and correctly pass them to both Metrics Server and Apiserver. In vast majority of cases this is hard (complicates configuration, requires users to setup up certificate rotation etc) or impossible (users run on Kubernetes as a Service platform without access to apiserver). For ease of use default configuration just sets this flag to false. For super users that want 100% security I started to write a guide how to setup MS https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md#how-to-run-metrics-server-securely. I think we should add instruction to set insecureSkipTLSVerify.

Ad 2: Having insecureSkipTLSVerify set to true potentially allows for attack disrupting cluster workloads by serving incorrect metrics that would be used by Horizontal Pod Autoscaler or Vertical Pod Autoscaler. It is a security issue, but not something that most users are worried about making it acceptable default.

[serathius]

Created #545

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[serathius]

Closing as original question was answered