Skip to content

Update the KEP with clarity around localhost probes #5444

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
+27 −11
Closed

Update the KEP with clarity around localhost probes #5444

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 27 additions & 11 deletions keps/sig-auth/4940-psa-block-host-field-in-probes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,8 @@ lead to blind SSRF attacks.
### Goals

* Add Pod Security Admission (PSA) to enable admins to restrict
users from creating probes with the `Host` field set.
users from creating probes with the `Host` field set to disallowed
values. The only allowed values will be `127.0.0.1` and `::1`.
Copy link
Member

@liggitt liggitt Jul 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

127.0.0.1 in a probe means localhost on the node host network.

Isn't that only valid for host network pods? The baseline pod security policy forbids hostNetwork: true and hostPort: ... pods, so I'm not sure why we'd allow probes that only work for host network pods.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree with @liggitt based on what was mentioned kubernetes/kubernetes#125271 (comment) I don't think we need to add this update to the enhancement. Original version looks good.

* The Baseline Pod Security Standard (PSS) will be updated to enforce
blocking this field so that it helps with easier adoption for
workload operators given this is a known issue we want to prevent.
Expand All @@ -108,10 +109,19 @@ we do not plan to offer it in the new types.

Meanwhile, the older API is never going to go away. So we also want to
add PSA to allow admins to be able to restrict users from creating
probes with the Host field set when using the (about to be deprecated) API.
This is implemented by [kubernetes PR 125271](https://github.com/kubernetes/kubernetes/pull/125271)
probes with the Host field set with disallowed values when using the
(about to be deprecated) API. This is implemented by
[kubernetes PR 125271](https://github.com/kubernetes/kubernetes/pull/125271)
that does exactly that.

Given there is still a use case where admins might be deploying the apiserver
or any controlplane host-networked pod service to have probes with `.Host` field set to
localhost (127.0.0.1). This is because there could be firewall rules blocking access to public nodeIP
for good reasons. Hence we would continue to allow for this use case meaning the only values
allowed on the `.Host` field would be `127.0.0.1` and `::1`. See [this snippet] for example.

[this snippet]: https://github.com/kubernetes/kops/blob/5dd2f468b46fda43f3a63ba1e6dc7c55c21919eb/nodeup/pkg/model/kube_apiserver.go#L603

### Risks and Mitigations

There might be users who depend on the `Host` field in
Expand All @@ -123,7 +133,9 @@ the PSA to block it.
## Design Details

Add a Baseline APILevel Pod Security Admission policy to allow admins of the
cluster to block users from setting `.host` field in:
cluster to block users from setting `.host` field to disallowed values in the
following fields. The only allowed values will be `127.0.0.1` and `::1` and everything
else will be blocked.

* spec.containers[*].LivenessProbe.ProbeHandler.HTTPGet.Host
* spec.containers[*].ReadinessProbe.ProbeHandler.HTTPGet.Host
Expand Down Expand Up @@ -168,10 +180,11 @@ Current test coverage status for the package is:

The following integration tests will be added to verify the PSA validation logic:

1. Test that pods with `.host` field set in probes are rejected when PSA is enabled with baseline level
2. Test that pods without `.host` field set in probes are allowed when PSA is enabled with baseline level
3. Test that existing pods with `.host` field set continue to work when PSA is enabled
4. Test that pods with `.host` field set are allowed when PSA is disabled or using an older version
1. Test that pods with `.host` field set to disallowed values in probes are rejected when PSA is enabled with baseline level
2. Test that pods with `.host` field set to allowed values in probes are accepted when PSA is enabled with baseline level
3. Test that pods without `.host` field set in probes are allowed when PSA is enabled with baseline level
4. Test that existing pods with `.host` field set continue to work when PSA is enabled
5. Test that pods with `.host` field set are allowed when PSA is disabled or using an older version

These tests will be added to:
- `test/integration/auth/podsecurity_test.go`
Expand All @@ -198,9 +211,12 @@ All related code will land within the same single release

### Upgrade / Downgrade Strategy

Any older pods with this field set should not be affected
with the above solution. Only newer pods getting created
with the field will be alerted.
Any older pods with this field set to allowed values should
not be affected with the above solution.

Any older pods with this field set to disallowed values should
not be affected with the above solution. Only newer pods getting
created with the field will be alerted.

Users who are using this field can switch to using exec
probes moving forward which should unblock them given exec
Expand Down