kubectl proxy should warn about dangerous configurations #122816
Conversation
Problem: In AquaSec recent research, they have identified a common misconfiguration related to the use of the kubectl proxy command in Kubernetes clusters. This misconfiguration can expose the Kubernetes API server to unauthorized access and poses significant security risks. Scope: The misconfiguration occurs when practitioners run the kubectl proxy command with specific flags, such as --address=0.0.0.0 --accept-hosts .*. This configuration causes the proxy on the workstation to listen and forward authorized and authenticated requests to the API server from any host that has HTTP access to the workstation. Importantly, the privileges granted to the kubectl proxy command are the same as those of the user who ran it. Risks: This misconfiguration can lead to unauthorized access to the Kubernetes cluster, potentially compromising the security of the cluster and the applications running on it. Threat actors can exploit this exposure to gain access to sensitive information, secrets, and other critical resources. Proposed Solution: To address this issue and mitigate the risks associated with misconfigured kubectl proxy commands, we propose the following steps: Kuberenetes warning: Running kubectl proxy with wide-open configurations can expose your Kubernetes cluster to potential security threats. Attackers could exploit this vulnerability to gain unauthorized access to your cluster and its resources. Add one section check o.address and acceptHosts in https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kubectl/pkg/cmd/proxy/proxy.go#L151 Securing kubectl proxy: Ensure that the kubectl proxy is not exposed to the internet, and set it up within a secure network environment accessible only by authenticated and authorized users. Additional Information: This issue highlights the security risks associated with misconfigured kubectl proxy commands and provides recommendations for addressing these risks. It's crucial for Kubernetes users to be aware of the potential dangers and take appropriate precautions to secure their clusters. References: https://blog.aquasec.com/kubernetes-exposed-one-yaml-away-from-disaster
k8s-ci-robot
added
size/XS
|
Welcome @blackzlq! |
k8s-ci-robot
added
do-not-merge/needs-sig
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
Hi @blackzlq. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
k8s-ci-robot
added
the
needs-priority
k8s-ci-robot
added
area/kubectl
sig/cli
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: blackzlq The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
release-note
|
/kind documentation |
k8s-ci-robot
added
kind/documentation
|
/ok-to-test |
k8s-ci-robot
added
ok-to-test
|
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
Could you link the fix? @kumarankit999 |
| } | ||
| // string contains will use exact match, not regex. | ||
| if strings.Contains(o.acceptHosts, ".*") { | ||
| klog.Warning("--accept-hosts will accept any host, which may expose cluster access via the proxy to anyone who can access your network.") |
There was a problem hiding this comment.
this warning isn't necessarily true. .*\.example.com contains .* but does not accept any host
There was a problem hiding this comment.
I think .*\.example.com will still accept kind of any. The range is too wide. But we can modify the warning sentence to be --accept-hosts will accept a wide range of hosts, which may expose cluster access via the proxy to anyone who can access your network. What do you think
There was a problem hiding this comment.
I think .*.example.com will still accept kind of any.
I don't think it does? It only accepts subdomains of example.com, right?
The range is too wide
Not if you're intending to allow all subdomains of example.com, right?
There was a problem hiding this comment.
I think there's two heuristics we can apply here (we could do both):
- actually attempt to match a random host string we construct ("$(random-uuid).$(random-uuid)" or something) against the acceptHosts pattern... if it gets accepted that's a good sign any host would be accepted
- detect
.*and warn generically about a broad accept-hosts setting as you indicated in kubectl proxy should warn about dangerous configurations #122816 (comment)
There was a problem hiding this comment.
I think .*.example.com will still accept kind of any.
I don't think it does? It only accepts subdomains of example.com, right?
The range is too wide
Not if you're intending to allow all subdomains of example.com, right?
Discussed with Michael, we think the sub domain is still very broad. What about we do both check. random match pattern OR contains .*
There was a problem hiding this comment.
Warning for allowing any subdomain is too broad imo. We should stick to warnings for allowing the world and not try to get in the weeds of what constitutes "appropriately restricted" because this will be different for every organization.
| @@ -185,6 +185,13 @@ func (o *ProxyOptions) Complete(f cmdutil.Factory) error { | |||
| RejectMethods: proxy.MakeRegexpArrayOrDie(o.rejectMethods), | |||
| } | |||
| } | |||
| if o.address == "0.0.0.0" { | |||
There was a problem hiding this comment.
@aojea should this be something net.ParseIP(o.address).IsUnspecified() to catch ipv6 "listen to all" addresses as well?
There was a problem hiding this comment.
Does this address apply to ipv6? @aojea
There was a problem hiding this comment.
what Jordan says https://pkg.go.dev/net#IP.IsUnspecified
The reality is that the address is "all zeros", 0.0.0.0 or :: are the representations , you have to use net.ParseIPSloppy() to avoid the linter problems
| @@ -185,6 +185,13 @@ func (o *ProxyOptions) Complete(f cmdutil.Factory) error { | |||
| RejectMethods: proxy.MakeRegexpArrayOrDie(o.rejectMethods), | |||
| } | |||
| } | |||
| if o.address == "0.0.0.0" { | |||
| klog.Warning("kubectl proxy will serve on all network interfaces (0.0.0.0), which may expose cluster access via the proxy to anyone who can access your network.") | |||
There was a problem hiding this comment.
| klog.Warning("kubectl proxy will serve on all network interfaces (0.0.0.0), which may expose cluster access via the proxy to anyone who can access your network.") | |
| klog.Warningf("kubectl proxy will serve on all network interfaces %s, which may expose cluster access via the proxy to anyone who can access your network.", o.address) |
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
What this PR does / why we need it:
In AquaSec recent research, they have identified a common misconfiguration related to the use of the kubectl proxy command in Kubernetes clusters. This misconfiguration can expose the Kubernetes API server to unauthorized access and poses significant security risks.
Scope:
The misconfiguration occurs when practitioners run the kubectl proxy command with specific flags, such as --address=0.0.0.0 --accept-hosts .*. This configuration causes the proxy on the workstation to listen and forward authorized and authenticated requests to the API server from any host that has HTTP access to the workstation. Importantly, the privileges granted to the kubectl proxy command are the same as those of the user who ran it. Risks:
This misconfiguration can lead to unauthorized access to the Kubernetes cluster, potentially compromising the security of the cluster and the applications running on it. Threat actors can exploit this exposure to gain access to sensitive information, secrets, and other critical resources.
Which issue(s) this PR fixes:
To address this issue and mitigate the risks associated with misconfigured kubectl proxy commands, we propose the following steps:
Kuberenetes warning:
Securing kubectl proxy:
Special notes for your reviewer:
This issue highlights the security risks associated with misconfigured kubectl proxy commands and provides recommendations for addressing these risks. It's crucial for Kubernetes users to be aware of the potential dangers and take appropriate precautions to secure their clusters. References:
https://blog.aquasec.com/kubernetes-exposed-one-yaml-away-from-disaster
Does this PR introduce a user-facing change?