add openshift resources to chart

[jonmosco]

Motivation

Running LocalStack on OpenShift requires specific Security Context Constraints (SCC) to be applied to ensure proper deployment and operation.

Changes

• Added conditional logic in the Helm chart templates to include OpenShift-specific configurations when deploying on an OpenShift cluster.
• The Route template now includes a condition that checks if both .Values.openshift and .Values.route.enabled are set to true before applying the Route.
• The RoleBinding template was updated to conditionally apply OpenShift-specific settings.
• Updated the values.yaml to include new parameters for controlling OpenShift-specific behavior (openshift: true and route.enabled: true).

This change ensures that the Helm chart can be more flexibly deployed across different environments, applying OpenShift-specific configurations only when necessary.

[alexrashed]

Hi @jonmosco!
Thanks for your contribution!
But I think this needs a bit more discussion before we can move forward...
Imho OpenShift (or any other derivatives of K8s) should not be first-class-citizens in this chart itself, but we should definitely facilitate deploying the chart in these orchestrators.
I think the best way moving forward would be to:

• Implement the possibility to set arbitrary SCCs in this chart
  • Not all users would like to use the anyuid SCC and most parts of LocalStack do not require root permissions.
• Afterwards you can use the Chart as subchart which deploys LocalStack with the proper roles (by setting the config of this chart / the subchart in our scenario) and the route (from your own chart).

What do you think about that?

[jonmosco]

Thank you for the feedback @alexrashed, appreciate the insights.

I agree that making OpenShift (other K8s derivatives) first-class citizens in the chart might not be necessary.

• Implementing the option to set arbitrary SCCs would provide the flexibility needed while keeping the chart generic.
• Using this Chart as a subchart to set the proper roles seems like a viable approach.

I think this is a good idea, and I'm interested in helping expand the documentation for OpenShift. I believe the community would benefit from the helm approach, in addition to the DevSpaces method described here.

[alexrashed]

Perfect, so that basically means that we just need a new section in the values.yaml which allows defining arbitrary SCC roles, which is then used in the template for the roles.yaml.
Do you want to change your PR accordingly? Maybe also add a section to the README on how to use this chart in OpenShift?

[jonmosco]

Yes, I will update the PR to include these changes, and I will also add a section to the README on how to use this chart in OpenShift.

Thanks for the suggestion!

[alexrashed]

@jonmosco Coming back to this PR, do you need any help with implementing the changes we discussed? :)

[jonmosco]

Not yet; just had a few things to work on and hopefully, will have a PR soon. Thank you!

[alexrashed]

Thanks a lot for addressing the comment! I think it would be great if we could generalize it even a bit more (see the comment). What do you think?

[alexrashed]

I think it would be great if we could generalize this even a bit more by allowing arbitrary configs here, similar to the extraEnvVars here:

helm-charts/charts/localstack/templates/deployment.yaml

Lines 188 to 190 in d896940

	{{- if .Values.extraEnvVars }}
	{{- include "common.tplvalues.render" (dict "value" .Values.extraEnvVars "context" $) | nindent 12 }}
	{{- end }}

Something like extraRoles would allow us to enable the usage in OpenShift, while not committing to a specific derivate.
Waht do you think?

[jonmosco]

Sounds good to me! I will work on these changes. Thanks for the feedback.

[jonmosco]

Just so I understand, if the SCCs were to be created without OpenShift, do you mean something like Pod Security Policies, Pod Security Admission, or custom roles that basically mirror what the SCC would provide?

[alexrashed]

I would really just "move the value template to one level higher", meaning that you would not set the resource names for a pre-defined / hard coded rule, but that you can add arbitrary complete rule entries.

So basically your value file would look something like this:

role:
  extraRules:
    - apiGroups: ["security.openshift.io"]
      resources: ["securitycontextconstraints"]
      resourceNames: ["anyuid"]
      verbs: ["use"]

We already do the same thing with the extraEnvVars linked above (where we even have template evaluation of the entries), so it should be fairly straight forward to implement.

And in the whole chart there would be no mention of OpenShift (because the chart would stay derivate-agnostic).
But it would still be great to have it explained how it works for OpenShift in the readme (thanks for the push on the docs)!

[jonmosco]

Ok, I think i'm getting closer to what you are describing. Let me know if you like this diff.

[alexrashed]

I feel like there was a bit of back-and-forth with the discussion, and your previous commit unfortunately didn't really produce a valid roles.yml.
I hope it's okay, but since I was already at it / testing it, I just adjusted your solution to what I meant / we discussed.
You can see in the commit (78a5552) that it's actually less complex (only 1 line) but also allows template substitution in the values (with the common.tplvalues.render feature).

Thanks a lot for your contribution, I'll directly merge the PR and create a new release.

[jonmosco]

This looks good to me! Thanks for the explanations and for merging this!