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

Make it possible to set custom securityContext fields in the Helm chart #1286

Open
lindhe opened this issue Aug 30, 2022 · 4 comments
Open

Comments

@lindhe
Copy link

lindhe commented Aug 30, 2022

Is your feature request related to a problem? Please describe.

To comply with our organization's security standards, we must set some specific configuration in the securityContext object for pods and/or containers.
Today it is not possible to set all of the possible securityContext fields, since the templates only uses hard coded values.
Being able to customize this would be a huge improvement.

Here's an example of what the pod's SecurityContext is in the core/core-dpl.yaml file:

spec:
  securityContext:
    runAsUser: 10000
    fsGroup: 10000

Describe the solution you'd like

I would like there to be a podSecurityContext and a containerSecurityContext object for each component, and that the template for any Pod, Deployment, StatefulSet or DaemonSet should include them if they are defined.

Describe the main design/architecture of your solution

In the values.yaml file, it would look like this:

core:
  podSecurityContext:
    runAsUser: 10000
    fsGroup: 10000
  containerSecurityContext:
    runAsUser: 10000
    fsGroup: 10000

Template files should use it like this:

[…]
    spec:
      {{- with .Values.core.podSecurityContext }}
      securityContext:
        {{ toYaml . }}
      {{- end }}
      containers:
        - name: core
          {{- with .Values.core.containerSecurityContext }}
          securityContext:
            {{ toYaml . }}
          {{- end }}
[…]

Note that we are careful to not include the object if it is undefined.

Describe the development plan you've considered

This should be pretty straight-forward to implement by just adding the template code I suggested in the right places, since this is added functionality and not changed functionality.
And as long as we transfer the current hard-coded values to the values.yaml file, the default values should not change at all in the releases.

@naitmare01
Copy link

+1 for this suggestion.

@MinerYang
Copy link
Collaborator

I will transfer this at the harbor-helm repo. We will track over there.

@MinerYang MinerYang transferred this issue from goharbor/harbor Sep 5, 2022
@MinerYang MinerYang reopened this Sep 5, 2022
@zyyw
Copy link
Collaborator

zyyw commented Sep 8, 2022

@lindhe unfortunately, we have no plan to configure this in harbor-helm. The main reason for that is because some of the Dockerfile is hardcode with some specific user code number.

@lindhe
Copy link
Author

lindhe commented Sep 12, 2022

I don't understand your argument there. You could still have the same default values as today, just that you would include the entire object from Values. Can you please elaborate or give an example?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants