Skip to content
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.

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

Configure securityContext by default for implementing Pod Security Standard #325

Open
avthart opened this issue Sep 5, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request feature-request

Comments

@avthart
Copy link

avthart commented Sep 5, 2024

In compliant Kubernetes clusters, workloads should run as secure as possible.
Therefore, it would be great if hivemq and the operator can be compliant with the Pod Security Standard restricted profile (if possible).

See https://kubernetes.io/docs/concepts/security/pod-security-standards/

@avthart
Copy link
Author

avthart commented Sep 5, 2024

Currently it is possible to set the podSecurityContext but it is not possible to set the containerSecurityContext (e.g. drop all capabilities, allowPrivilegeEscalation to false).

@afalhambra-hivemq afalhambra-hivemq self-assigned this Sep 5, 2024
@afalhambra-hivemq
Copy link
Contributor

Thanks @avthart - Indeed, that's a valid point to improve the Pod Security Standard of our platform.
That's something we are not directly supporting via our Helm charts. I will work on this to provide support for the Container Security Context as well.

In the meantime, if you need that, you can always override the whole StatefulSet as mentioned in our HiveMQ documentation. Bear in mind, that doing so, you need to align the different service configuration you also may have in your custom chart values with the ones you define in your override StatefulSet.

@avthart
Copy link
Author

avthart commented Sep 5, 2024

Thanks. Will look into this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feature-request
Projects
None yet
Development

No branches or pull requests

2 participants