Change:
This is a Feature Request The chapter that describes volume should mention field and recommend to use it when possible. What would you like to be should mention field Why is this needed This improves cluster security and should be always used when possible. Without a warning users might not know or just forget to specify this flag. Comments We might use a warning from as a draft and modify it accordingly. /sig auth /kind documentation
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : This is a Feature Request The chapter that describes volume should mention field and recommend to use it when possible. should mention field This improves cluster security and should be always used when possible. Without a warning users might not know or just forget to specify this flag. We might use a warning from as a draft and modify it accordingly. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten Still working on this?
/sig security
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Adding the PSS as is the future as K8S 1.21 is deprecating PSP. All Documentation for mention Read Only should also be covered in this docf from now on.
/sig storage /remove-sig auth
does this mean that readonly for hostpath is allowed and working but just not documented ?
yes, exactly
that is ownsome I was just going to rule out this solution because of the security issue. Thanks for your answer I'll test it right away.
well, I am using this manifest but I get this error
the VolumeMount on the pod spec allows a readonly setup but not on the Volume definition.
You're right and that's what I meant. Perhaps, I explained it a little vague.
well in that case I think you should close this issue as it is not an issue? the hostpath volume type does not support readonly but the container volume mount supports it and is documented here :
My point was that we can promote best practices by adding a hint to the documentation. Most of the people, don't read API specifications, they google and find a page with documentation. In this case, an advise of other options might be useful.
/remove-lifecycle stale
Would very much have appreciated if suggestion had been implemented; would have saved me a bunch of time looking for a way to mount a hostPath readonly.
/assign I can add a note in

Discussion:
### hostPath {#hostpath} <ins> {{< warning >}} HostPath volumes present many security risks, and it is a best practice to avoid the use of HostPaths when possible. When a HostPath volume must be used, it should be scoped to only the required file or directory, and mounted as ReadOnly. If restricting HostPath acccess to specific directories through AdmissionPolicy, `volumeMounts` MUST be required to use `readOnly` mounts for the policy to be effective. {{< /warning >}} </ins> A `hostPath` volume mounts a file or directory from the host node's filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications.

Watch out when using this type of volume, because: <ins> * HostPaths can expose privileged system credentials (such as for the Kubelet) or privileged APIs (such as container runtime socket), which can be used for container escape or to attack other parts of the cluster. </ins> * Pods with identical configuration (such as created from a PodTemplate) may behave differently on different nodes due to different files on the nodes * The files or directories created on the underlying hosts are only writable by root. You