Description of problem:
ALBO needs a prerequisite secret provisioned before its installation. This secret is used to fetch VPC ID and to tag the subnets (optional). Both of these AWS resources are needed before the managed controller can be spawned.
On non STS OCP clusters the secret contains the static AWS credentials: access key and access secret. The current implementation is ready to consume the static type of the secret: only AWS_SHARED_CREDENTIALS_FILE environment variable needs to point to the credentials file.
However in OCP cluster with STS the prerequisite credentials secret is not self sufficient - it only contains the links to the other resources: ARN of the IAM role which has to be created in AWS and a valid web identity token which again has to be present in the container consuming the secret (see this doc for the format of the secret). OCP created in manual mode using STS has all its service account tokens signed by AWS therefore valid for the authentication against AWS. So, it's enough to mount the service account of the POD which needs to use the AWS credentials into the path predefined (see the format link mentioned before).

ALBO doesn't have its POD's service account mounted into the path defined by the OCP on STS mode which causes the following error at the operator installation:

{"error": "failed to list VPC with tag "kubernetes.io/cluster/${cluster_name}": operation error EC2: DescribeVpcs, failed to sign request: failed to retrieve credentials: failed to refresh cached credentials, failed to retrieve jwt from provide source, unable to read file at /var/run/secrets/openshift/serviceaccount/token: open /var/run/secrets/openshift/serviceaccount/token: no such file or directory"}

Version-Release number of selected component (if applicable):
0.0.1

How reproducible:

Permanently

Steps to Reproduce:
1. Create an OCP cluster in manual mode with AWS STS (doc)
2. Create a pre-requsite secret from CredentialsRequest using ccoctl tool
3. Deploy ALBO from the OperatorHub (channel stable-v0.1)

Actual results:
ALBO POD is not starting in aws-load-balancer-operator namespace due to the error in the description.

Expected results:
ALBO POD running and ready.

Additional info:
The initial PR was created by the reporter of the bug: https://github.com/openshift/aws-load-balancer-operator/pull/78. It was taken over by https://github.com/openshift/aws-load-balancer-operator/pull/82.