Description of problem:

I recently had a conversation with a member of SRE (todabasi.openshift) about why must-gather was failing to run. see this slack thread

In short i don't think our docs are clear; in explaining to a user what happens when a pod starts (thus IDK if this is an issue to be fixed in the must-gather docs section([enterprise-4.14] Issue in file support/gathering-cluster-data.adoc) or the authentication/authorization sections of the docs ([enterprise-4.14] Issue in file authentication/using-service-accounts-in-applications.adoc)). So I will outline the issue as best I can.

In short when must-gather (or any pod) starts, that pod is run as the 'default' service account associated with the namespace in which the pod is running (IE: the pod get's/assumes those permissions). Unless a specified (override) service account is given to the pod, see https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ (which must-gather doesn't do, nor does it provide a way to do so).

• Note: This makes me wonder if [enterprise-4.14] Issue in file authentication/using-service-accounts-in-applications.adoc needs to state what the upstream docs state, about service accounts.

Thus while: [enterprise-4.14] Issue in file support/gathering-cluster-data.adoc states:

Optionally, you can run the oc adm must-gather command in a specific namespace by using the --run-namespace option.

It may not be overtly clear to a user why must-gather (or any pod) can't run/execute; if the starting user (the user executing the `oc` command) was given sufficient (ie: 'cluster-admin') permissions. Thus we may need to better explain; what happens when you start a pod (and what that flow looks like).