OpenShift enforces a 'restricted' PodSecurityPolicy by default, requiring UIDs/GIDs to fall within a range defined in the namespace's annotations. If the pod manifest does not specify a UID/GID, OpenShift automatically assigns appropriate values. However, when using kube-inject, the sidecar may default to a user ID of 1337 in some cases. Such manifests may fail on an OpenShift cluster unless the UID/GID is manually corrected.

istioctl kube-inject allows for the manual injection of sidecars into Kubernetes workloads and can be used in two main ways.

1. Applying the command directly to a deployment/manifest in a live cluster.

   kubectl get deployment -o yaml | istioctl kube-inject -f - | kubectl apply -f - 

1. Using configuration captured from a live cluster to create a persistent deployment manifest with the sidecar for future use.

   # Capture cluster configuration for later use with kube-inject
     kubectl -n istio-system get cm istio-sidecar-injector  -o jsonpath="{.data.config}" > /tmp/inj-template.tmpl
     kubectl -n istio-system get cm istio -o jsonpath="{.data.mesh}" > /tmp/mesh.yaml
     kubectl -n istio-system get cm istio-sidecar-injector -o jsonpath="{.data.values}" > /tmp/values.json
   
     # Use kube-inject based on captured configuration
     istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml \
       --injectConfigFile /tmp/inj-template.tmpl \
       --meshConfigFile /tmp/mesh.yaml \
       --valuesFile /tmp/values.json 

OSSM 3.x supports the first method when the namespace is specified. However, manifests generated using the second method may not work in all cases.

This Jira has been created to assess whether a warning message should be added to the OCP build of istioctl to alert users about the second category.