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

Set secure defaults for containerSecurityContext fields #751

Closed
tarquin-the-brave opened this issue Sep 29, 2021 · 1 comment · Fixed by #2789
Closed

Set secure defaults for containerSecurityContext fields #751

tarquin-the-brave opened this issue Sep 29, 2021 · 1 comment · Fixed by #2789
Labels
type/enhancement New feature or request

Comments

@tarquin-the-brave
Copy link
Contributor

Community Note

  • 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.

We found these can be set to:

server:
  containerSecurityContext:
    privileged: false
    capabilities:
      drop:
        - ALL
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true

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.

@david-yu
Copy link
Contributor

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.

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

Successfully merging a pull request may close this issue.

2 participants