Hello Kubernetes Community,
A security issue was discovered with Kubernetes that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack.
This issue has been rated Low severity (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), and assigned CVE-2021-25740.
Am I vulnerable?
If a potential attacker can create or edit Endpoints or EndpointSlices in the Kubernetes API, they can potentially direct a LoadBalancer or Ingress implementation to expose backend IPs the attacker should not have access to.
Importantly, if the target’s NetworkPolicy already trusts the Load Balancer or Ingress implementation, NetworkPolicy can not be used to prevent exposure from other namespaces, potentially bypassing any security controls such as LoadBalancerSourceRanges.
This issue is a design flaw that cannot be fully mitigated without user-facing changes. With this public announcement, we can begin conversations about a long-term fix.
Affected Versions
All Kubernetes versions are affected.
How do I mitigate this vulnerability?
There is no patch for this issue, and it can currently only be mitigated by restricting access to the vulnerable features. To mitigate the exposure, we recommend restricting write access to Endpoints and EndpointSlices by updating the system:aggregate-to-edit role using the attached file. This will remove write access to Endpoints from the admin and edit roles:
Allow kubectl auth reconcile to work
kubectl annotate --overwrite clusterrole/system:aggregate-to-edit rbac.authorization.kubernetes.io/autoupdate=true
Test reconcile, then run for real if happy
kubectl auth reconcile --remove-extra-permissions -f aggregate_to_edit.yaml --dry-run
kubectl auth reconcile --remove-extra-permissions -f aggregate_to_edit.yaml
Prevent autoreconciliation back to old state
kubectl annotate --overwrite clusterrole/system:aggregate-to-edit rbac.authorization.kubernetes.io/autoupdate=false
Note: This will prevent new versions of Kubernetes from reconciling new default permissions to this role. No new default permissions have been added to this role since v1.14.0, but we recommend you remove the autoupdate=false annotation as soon as a fix or other mitigation is possible.
For use-cases that need to edit these resources, we recommend creating a new purpose-built Role with the desired permissions, and using it only for those cases.
Detection
Services with an empty selector rely on custom endpoints and are vulnerable to the attack described above. We recommend manually auditing any such usage. The following kubectl command will list all Services in a cluster with their selector:
kubectl get svc --all-namespaces -o=custom-columns=‘NAME:metadata.name,NAMESPACE:metadata.namespace,SELECTOR:spec.selector’
Note: Some Services without selectors specified may have their Endpoints managed by other controllers or tools. For example, endpoints for the default/kubernetes Service are managed by the Kubernetes API Server.
If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io
Additional Advisory
A similar attack is possible using Ingress implementations that support forwarding to ExternalName Services. This can be used to forward to Services in other namespaces or, in some cases, sensitive endpoints within the Ingress implementation. If you are using the Ingress API, we recommend confirming that the implementation you’re using either does not support forwarding to ExternalName Services or supports disabling the functionality.
Additional Details
See the GitHub issue for more updates: https://github.com/kubernetes/kubernetes/issues/103675
Thank You,
Rob Scott on behalf of Kubernetes SIG Network and CJ Cullen on behalf of the Kubernetes Product Security Committee
(Attachment aggregate_to_edit.yaml is missing)