Should we set insecureSkipTLSVerify: false in the APIService for production clusters and how do we provide a proper certificate?

[mdzhigarov]

I couldn't help but notice that the APIService manifest https://github.com/kubernetes-sigs/prometheus-adapter/blob/master/deploy/manifests/api-service.yaml#L12 uses insecureSkipTLSVerify: true.

This means that the K8s Aggregator API would not verify the Prometheus' Adapter tls certificate.
In a production cluster, does it make sense to set the insecureSkipTLSVerify to false and instead provide a caBundle within the APIService? Is this how we're supposed to secure this connection?

I am not confident I understand how caBundle is supposed to work. Who is responsible for generating the caBundle certificates? How are those certificates getting injected into the Prometheus' adapter itself once we set them to the APIService caBundle?

In general, is there a documentation that explain best practices around how to setup prometheus adapter property for production clusters?

[dgrisonnet]

/triage accepted

[dgrisonnet]

We sadly don't have enough resources to look after support issues for prometheus-adapter right now.

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten