add an option for skipping tls verifiation on logs requests

[deads2k]

Insecure Backend Proxy for pods/logs

• If a client chooses, it is possible to bypass the default behavior of the kube-apiserver and allow the kube-apiserver to skip TLS verification of the kubelet to allow gathering logs

• Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1295-insecure-backend-proxy

• Discussion Link: This KEP predates the template. I have no memory of where this is

• Primary contact (assignee): @deads2k

• Responsible SIGs: apimachinery, auth

• Enhancement target (which target equals to which milestone):

  • Alpha release target (x.y):
  • Beta release target (x.y): 1.17
  • Stable release target (x.y): 1.21

• Alpha

  • KEP (k/enhancements) update PR(s):
  • Code (k/k) update PR(s):
  • Docs (k/website) update PR(s):

• Beta

  • KEP (k/enhancements) update PR(s):
  • Code (k/k) update PR(s):
  • Docs (k/website) update(s):

• Stable

  • KEP (k/enhancements) update PR(s): update insecure-backend-proxy feature to target GA. Add PRR #2237
  • Code (k/k) update PR(s):
  • Docs (k/website) update(s):

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

When trying to get logs for a pod, it is possible for a kubelet to have an expired serving certificate. If a client chooses, it should be possible to bypass the default behavior of the kube-apiserver and allow the kube-apiserver to skip TLS verification of the kubelet to allow gathering logs. This is safe because the kube-apiserver's credentials are always client certificates which cannot be replayed by an evil-kubelet and risk is contained to an evil-kubelet returning false log data. If the user has chosen to accept this risk, we should allow it for the same reason we have an option for --insecure-skip-tls-verify.

On self-hosted clusters it is possible to end up in a state where a kubelet's serving certificate has expired so a kube-apiserver cannot verify the kubelet identity, but the kube-apiserver's client certificate is still valid so the kubelet can still verify the kube-apiserver. In this condition, a cluster-admin may need to get pod logs to debug his cluster.

@kubernetes/sig-api-machinery-feature-requests
@kubernetes/sig-cli-feature-requests
@kubernetes/sig-auth-feature-requests

https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190927-insecure-backend-proxy.md

[mrbobbytables]

@deads2k Is this an Enhancement that should be tracked for 1.17? If so, can you reformat the issue with the KEP Issue template?

# Enhancement Description
- One-line enhancement description (can be used as a release note):
- Kubernetes Enhancement Proposal: (link to kubernetes/enhancements file, if none yet, link to PR)
- Primary contact (assignee):
- Responsible SIGs:
- Enhancement target (which target equals to which milestone):
  - Alpha release target (x.y)
  - Beta release target (x.y)
  - Stable release target (x.y)

_Please to keep this description up to date. This will help the Enhancement Team track efficiently the evolution of the enhancement_

[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

[palnabarun]

/remove-lifecycle stale

[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

[palnabarun]

/remove-lifecycle stale