opentelemetry-helm-charts
opentelemetry-helm-charts copied to clipboard
Add support for OpenShift
Add support for the OpenShift cloud application deployment and hosting platform.
OpenShift is currently not supported.
TODO
- [ ] Replace the PostgreSQL image with the RedHat managed image
- [ ] Replace the Kafka deployment
- [ ] Prevent the images from writing on disk during startup (no write access)
- [ ] Update the security context configurations
A work in progress howto guide is here
https://gist.github.com/realtimetodie/c69563c6b9398f22e6621083f6027dba
Related
- https://github.com/open-telemetry/opentelemetry-helm-charts/issues/665
- https://github.com/open-telemetry/opentelemetry-helm-charts/issues/634
Can you expand on the security context requirements?
What SCC does your demo run under?
What security context configs aside of those that are already included (envoy, postgres, kafka, redis, quoteservice) in the default values.yaml
do you think are needed to be updated?
Are you able to set the following SCC for the demo service account and verify if the reported issues persist?
oc adm policy -n otel-demo add-scc-to-user nonroot -z my-otel-demo
In my on-prem OpenShift install, the demo runs fine with the above config and the default Helm security context.
Update:
I've added an explicit security context in my values.yaml for the nonroot scc to work as something seems to have changed in the below two services since I last tested this (container coimplained about /.npm
access rights:
frontendservice
securityContext:
runAsUser: 1001 # nextjs
runAsGroup: 1001
runAsNonRoot: true
paymentservice
securityContext:
runAsUser: 1000 # node
runAsGroup: 1000
runAsNonRoot: true
@styblope I now have OpenShift running locally, and working on getting this all figured out. I also came to similar conclusions. Is there a way to encode this command as a Kubernetes resource that gets applied by the Helm chart?
oc adm policy -n otel-demo add-scc-to-user nonroot -z my-otel-demo
@styblope Unfortunately, setting rolebinding with oc is not possible in highly restricted enterprise environments. But using an empty securityContext
works, as the security context is assigned by OpenSift automatically.
securityContext: {}
@puckpuck Again, the goal of adding OpenShift support should be to install the helm chart without requiring the user to run any oc commands as these commands will fail in highly restricted enterprise environments.
@puckpuck we could add the required SCC to an RBAC Role for the demo ServiceAccount. This would involve creating Role and RoleBinding manifests in Helm. Adding SCC to a Role is decribed here
@realtimetodie How do people in super restricted OpenShift environments install Prometheus or Grafana which require ClusterRoles in order to work?
About this issue comment on the Demo repo.
For now, we will provide instructions on the oc adm policy add-sdd-to-user ...
commands to run for OpenShift as an Administrator. I understand this isn't ideal, but it allows us to unblock at least some install scenarios of the Demo.
The Demo has 7 different services that specify a non-root user in the Dockerfile. Modifying all of them so OpenShift can dynamically assign a non-root user to run the container is a significant effort with plenty of risks. I'm going to open another issue, specifically in the Demo repo, to track this, listing the 7 services that need to be updated and the other tasks listed here.