Helm updates for v1.4

[puckpuck]

Tracking list of issues on the OpenTelemetry Helm chart repo for the demo to create a v1.4 release.

• Not support arm64 images bug Something isn't working
• Add support for OpenShift
• [Demo] Add support for env from secrets
• [demo] Add Security Context for all demo components
• [demo] startup order/dependency for components
• [demo] add LivenessProbe and SecurityContext to values schema
• [demo] add more CI tests and examples

[puckpuck]

Adding SecurityContext to each pod is based on challenges for getting the demo to work in OpenShift. Those 2 tasks are related to each other.

Is anyone aware of a free OpenShift cluster we can use to do some testing? I would need kubectl/helm access to the cluster.

[styblope]

This service-account SCC policy attachment works ok for me:

oc adm policy -n otel-demo add-scc-to-user anyuid -z my-otel-demo

As the above command modifies existing cluster-wide clusterrolebinding system:openshift:scc:anyuid it isn't Helm friendly. A role+rolebinding with the SCC use would work for Helm.

I also like to add a route:

oc create route edge my-otel-demo --service my-otel-demo-frontendproxy

[puckpuck]

OpenShift, by default, is quite restrictive, and any of our services that specify a USER in the Dockerfile will fail to start. The Demo has several services with this specified, which is done for various reasons. I see 2 options we can take to overcome this.

Option 1:
OpenShift Security Context Constraints (SCC) can be applied to the Demo service account to enable the Demo to start up and work. Enabling these capabilities requires a user with elevated permissions in OpenShift. Once set, the Demo can be installed by a standard developer user with all other restrictions. We need to add some minor changes to our Helm chart for the frontend and paymentservice as well to work in this method.

For this option, we need to make the required changes to the Helm chart for frontend and paymentservice, and include additional instructions for an OpenShift administrator to run the proper oc adm policy add-scc-to-user ... commands to apply the appropriate SCC, to allow a developer to install the Demo.

Option 2
We need to modify the Dockerfile for each service that specifies USER, and allow the service to startup by any non-root user, which OpenShift will assign when it starts the container. This may require doing additional permission changes in the Dockerfile. We also need to remove the securityContext definition on each service in Helm since OpenShift will control that aspect for each container/pod. The services that specify USER in the Dockerfile are: frontend, frontendProxy, paymentservice, quoteservice, ffs-postgres, kafka, and redis.

Recommendation
Of the 2 options, the second option contains significantly more effort and risk. As such, I recommend we do Option 1. This isn't ideal since it still requires an OpenShift Administrator to enable some permissions. Still, it will allow us to provide an option for people in OpenShift to use the Demo. I still see a future where we have this work without requiring administrator assistance, just not for the upcoming 1.4 release.

[puckpuck]

This PR in the Helm charts repo implements Option 1 above