fsGroup auto populated as 1

[madhuresh04]

We have observed while submitting workflows with securityContext:{} that the pods of the workflows are having the following securityContext. Is it a desired behaviour that even if we don't provide fsGroup , it takes it as 1 by default.
securityContext: fsGroup: 1 supplementalGroups: - 1

Consequence : In our use-case, we run CI pipelines, for which we attach pv (having huge no. of files) in every pod of the workflow and due to fsGroup as 1 (auto-injected in pods), whenever a pv is mounted the change in ownership happens, causing the below warning in the events log. The pod stays in this state for a long time causing undesired delay in every pod.
Unable to attach or mount volumes: unmounted volumes=[${volume}], unattached volumes=[ ${all-volumes} ]: timed out waiting for the condition

Is this config driven ? Please suggest, what should be approach taken to overcome this pod scheduling issue. Please let me know if I missed something that is causing this issue or if its already known.