kubernetes / kubernetes

Production-Grade Container Scheduling and Management
https://kubernetes.io
Apache License 2.0
111.18k stars 39.69k forks source link

NCC-E003660-MRE: API Server Proxy Disables TLS Certificate #119625

Open reylejano opened 1 year ago

reylejano commented 1 year ago

NCC-E003660-MRE: API Server Proxy Disables TLS Certificate

Validation This issue was reported in the Kubernetes 1.24 Security Audit Report

Impact An attacker suitably positioned on the network may be able to intercept TLS connections being made to pods, services or nodes from the API server proxy.

Description When the proxy functionality in the Kubernetes API server is used, the TLS certificate for the pod, service or node being accessed will not be checked by the API server. This could allow an attacker suitably positioned on the network to intercept the TLS connection to read or modify the traffic. The level of risk this presents will depend on the network architecture of a particular cluster.

Note that this discussion refers to the connection made by the API server to the pod, service or node which is the target of the proxy connection. The connection from the client to the API Server is not affected by this issue.

For an example, please see the original finding on page 29 of the Kubernetes 1.24 Security Audit Report

Recommendation Consider whether it is possible to implement TLS certificate validation for pod, service and node proxying. This would require a means of specifying the expected server certificate or trust store.

If this is not possible, ensure that documentation for the relevant APIs makes it clear that these connections are potentially vulnerable to man-in-the-middle attacks.

Component kube-apiserver

Location Function CreateProxyTransport() in file release-1.24 server.go:L224

Anything else we need to know? See umbrella issue #118980 for current status of all issues created from these findings. The vendor gave this issue an ID of NCC-E003660-MRE and it was finding 8 of the report under the kube-apiserver section. The vendor considers this issue Medium Risk, High Impact, Low Exploitability To view the original finding, begin on page 29 of the Kubernetes 1.24 Security Audit Report

Test Environment Kubernetes 1.24.3

reylejano commented 1 year ago

/sig security

liggitt commented 1 year ago

/sig api-machinery

cici37 commented 1 year ago

/cc @jpbetz @deads2k for security audit report /triage accepted

AhmedGrati commented 1 year ago

/assign

AhmedGrati commented 1 year ago

@reylejano My initial thinking is to add another argument to the api-server where we can pass the caBundle that can be used for the TLS certificates validation by the proxy. Can it be a possible solution? wdyt? (I want to gather your input before jumping into implementation.)

k8s-triage-robot commented 2 weeks ago

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

You can:

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

/remove-triage accepted