You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.
Is your feature request related to a problem? Please describe.
Consul components running with insecure kubernetes config.
Feature Description
Include secure defaults for the containerSecurityContext fields in the Helm chart.
Hi. A few weeks back I raised #602 and submitted #620 to allow the securityContext on the containers in the server and client Pods to be configured through the Helm chart.
I said once we (Microsoft Azure for Operators) had tested configuring these and found the most secure values they could take, we'd contribute those back as defaults to the chart.
It turns out our use case only needed to deploy the Consul servers via the Helm chart so we've only tested setting server.containerSecurityContext.
without affecting the functioning of the Consul server.
We haven't tested setting this for the client Pod. Looking at the client-daemonset.yaml template my guess would be that the consul container will be OK with the same securityContext as the server above.
For the initContainers client-acl-init & client-tls-init you might have to relax readOnlyRootFileSystem to false. It seems from your Pod spec that these initContainers write files to mounted volumes. I can't recall if readOnlyRootFileSystem prevents that or not, I can't tell from the docs. Something to test.
Use Case(s)
All those who deploy with the Helm chart can get the most secure container secuirtyContext values by default.
Contributions
We could contribute these defaults for the server, but I imagine you'd want to implement the "secure defaults" for the client Pod containers too, which we haven't tested.
The text was updated successfully, but these errors were encountered:
Closing as we added readOnlyRootFilesystem back in with this PR: #2909. We also addressed some other security concerns in Consul K8s 1.5.0. Please file a new issue as this issue is now quite old.
Community Note
Is your feature request related to a problem? Please describe.
Consul components running with insecure kubernetes config.
Feature Description
Include secure defaults for the containerSecurityContext fields in the Helm chart.
Hi. A few weeks back I raised #602 and submitted #620 to allow the securityContext on the containers in the server and client Pods to be configured through the Helm chart.
I said once we (Microsoft Azure for Operators) had tested configuring these and found the most secure values they could take, we'd contribute those back as defaults to the chart.
It turns out our use case only needed to deploy the Consul servers via the Helm chart so we've only tested setting
server.containerSecurityContext
.We found these can be set to:
without affecting the functioning of the Consul server.
We haven't tested setting this for the client Pod. Looking at the
client-daemonset.yaml
template my guess would be that theconsul
container will be OK with the same securityContext as the server above.For the initContainers
client-acl-init
&client-tls-init
you might have to relaxreadOnlyRootFileSystem
tofalse
. It seems from your Pod spec that these initContainers write files to mounted volumes. I can't recall ifreadOnlyRootFileSystem
prevents that or not, I can't tell from the docs. Something to test.Use Case(s)
All those who deploy with the Helm chart can get the most secure container secuirtyContext values by default.
Contributions
We could contribute these defaults for the server, but I imagine you'd want to implement the "secure defaults" for the client Pod containers too, which we haven't tested.
The text was updated successfully, but these errors were encountered: