Host Ports description at Pod Security Standards contradicts spec for that field

[joebowbeer]

This is a Bug Report

Problem:
The Host Ports baseline Pod Security Standard lists 0 as one of the allowed values, but the Container spec excludes the value 0. According to the container spec, the hostPort must be in the range 0 < x < 65536.

• ports.hostPort (int32)
  Number of port to expose on the host. If specified, this must be a valid port number, 0 < x < 65536.

Proposed Solution:
In the Host Ports baseline policy spec, either remove 0 from the allowed list, or add an explanation as to why 0 should be allowed even though it is not in the valid range.

Page to Update:
https://kubernetes.io/docs/concepts/security/pod-security-standards

[joebowbeer]

Relates to #36938

[dipesh-rawat]

/language en
/sig auth

[ghost]

@joebowbeer I think rather that removing 0 mentioning reason for it would be great for compatibility and consistency for the space. This would even clear the issue of why the value is used.

[ibihim]

/triage accepted

[k8s-triage-robot]

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

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

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

/remove-triage accepted

[k8s-ci-robot]

@joebowbeer: The label triage/accepted cannot be applied. Only GitHub organization members can add the label.

In response to this:

/triage accepted

Can someone suggest additional wording?

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-sigs/prow repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[joebowbeer]

@dipesh-rawat @ibihim @ritazh Can someone suggest additional wording?

Should I take a stab?

I don't entirely understand the explanation here:

kyverno/policies#842 (comment)

[ritazh]

Go for it!