Add securityContext to the init jobs

[ansell]

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.

I tried to deploy using the Consul Helm charts to a cluster that requires securityContext's on every pod and job to prevent the use of the root user inside of containers. It failed due to the tls-init job not having a securityContext attached to it.

Feature Description

My fix was to apply the same securityContext as the server to the tls-init-cleanup-job.yaml and tls-init-job.yaml files. There are possibly other init templates that it may also need to be applied to.

The fix for me was to modify both files inside of the spec: section to include the same securityContext as the server pods:

spec:
  template:
    spec:
      ....
      securityContext:
        {{- toYaml .Values.server.securityContext } nindent 8 }}

Use Case(s)

Consul on Kubernetes where there are security policies in place that restrict the use of the root user inside of containers.

Contributions

Yes, see above.

[t-eckert]

Hi @ansell,

I think this would be a great addition. Our processes do not run as root, but certain clusters can block on definitions not stating this explicitly using securityContext. If you would like to make this change and open a pull request, we would be happy to review it.

[david-yu]

This is now implemented via this PR: https://github.com/hashicorp/consul-k8s/pull/2525. Closing this issue, thank you for your feedback.