Some of our operators might hardcode user id, group id, fsgroup or other security context related things. We need to move away from that.
The detailed explanation can be found in the parent issue.
Step 1: Identify affected operators
Step 1 of this issue is to identify all operators that are "affected" and this seems to be the list:
I ran a search for "1000" and "run_as_user" on these operators.
[x] Airflow
[x] Druid
[x] HBase
[x] Hadoop HDFS
[x] Hive
[x] Kafka
[x] NiFi
[x] Spark
[x] Superset
[x] Trino
[x] ZooKeeper
[ ] Commons
[ ] Listener
[x] OPA
[ ] Secret
[ ] Hello World
TODO: For the ones not affected I want to double check by deploying and inspecting the pods
[ ] Commons
[ ] Listener
[ ] Secret
[ ] Hello World
Step 2: Remove hardcoded ids and test
Only remove user id and group id usage from these operators.
Leave the fsGroup in for now as that needs a more sophisticated solution.
Not hardcoding user id and group id means they'll fall back to the values from the docker image.
See https://github.com/stackabletech/issues/issues/645 for details.
Some of our operators might hardcode user id, group id, fsgroup or other security context related things. We need to move away from that.
The detailed explanation can be found in the parent issue.
Step 1: Identify affected operators
Step 1 of this issue is to identify all operators that are "affected" and this seems to be the list:
I ran a search for "1000" and "run_as_user" on these operators.
TODO: For the ones not affected I want to double check by deploying and inspecting the pods
Step 2: Remove hardcoded ids and test
Only remove user id and group id usage from these operators. Leave the fsGroup in for now as that needs a more sophisticated solution. Not hardcoding user id and group id means they'll fall back to the values from the docker image. See https://github.com/stackabletech/issues/issues/645 for details.