During the creation of a project or namespace, OpenShift assigns a User ID (UID) range, a supplemental group ID (GID) range, and unique SELinux MCS labels to the project or namespace. When a Pod is deployed into the namespace, by default, OpenShift will use the first UID and first GID from this range to run the Pod. Any attempt by a Pod definition to specify a UID outside the assigned range will fail and requires special privileges.
In most scenarios, there is no need for special privileges as long as the docker image is built with the above security restrictions in mind. But if you are pulling in a third party docker image which requires to run with a special UID, you can control the permissions and capabilities granted to a Pod using Security Context Constraints (SCC). But restrict the SCC only to a specific ServiceAccount and use that ServiceAccount to run the pod.
To add anyuid SCC to a ServiceAccount:
oc -n <ns> adm policy add-scc-to-user anyuid -z <service_account>
To remove anyuid SCC from a ServiceAccount:
oc -n <ns> adm policy remove-scc-from-user anyuid -z <service_account>
In case you are wondering what is happening behind the scene when you run oc -n <ns> adm policy add-scc-to-user anyuid -z <service_account>. It will create a RoleBinding called system:openshift:scc:anyuid in <ns> with <service_account> as a Subject. You can verify it with:
oc -n <ns> get RoleBinding system:openshift:scc:anyuid -o yaml
For more details on the topic: https://www.openshift.com/blog/a-guide-to-openshift-and-uids