Is your feature request related to a problem? Please describe.
The current IBM provider implementation allows to override the IAM endpoint for the authentication steps only for the authentication based on Trusted Profiles (containerAuth), while for IAM APIkey authentication (secretRef) the IAM endpoint cannot be overridden.
As a result, only the authentication flow using Trusted Profile can be customized to leverage on IBM Cloud private endpoints, by customizing the provider with the private service endpoints of IAM and the Secret Manager instance
The APIkey authentication flow cannot be currently configured to go through the private service endpoints as on Secrets Manager endpoint can be customized but the IAM endpoint cannot be overridden.
As a direct result, in the case of a deployment on a cluster with more than one worker pools and the need to use IAM public service endpoint, the operator needs to be deployed on the worker pool with access to the public network, with the related security hardening concerns.

Describe the solution you'd like
Provide a way to customize IAM endpoint for the secretRef in the same way it is currently allowed for containerAuth:

ibm:
      serviceUrl: "https://<SECRETS_MANAGER_ID>.<REGION>.secrets-manager.appdomain.cloud"
      auth:
        containerAuth:
          profile: "test container auth profile"
          tokenLocation: "/var/run/secrets/tokens/sa-token"
          iamEndpoint: "https://iam.cloud.ibm.com"

It would mean something like:

spec:
          provider:
            ibm:
              serviceUrl: "https://<SECRETS_MANAGER_ID>.<REGION>.secrets-manager.appdomain.cloud"
              auth:
                secretRef:
                  secretApiKeySecretRef:
                    name: "<APIKEY secret name>"
                    key: apiKey
                    namespace: "<ESO namespace>"
                    iamEndpoint: "<IAM endpoint URL>"

Describe alternatives you've considered
As alternatives currently available:

• configure the ESO pods to leverage on a cluster proxy (downside, it is not possible to detect changes on the cluster proxy IP and to update the ESO proxy configuration
• enroll the operator in istio servicemesh: currently failing with external-secrets-webhook validation, temporary workaround would be to disable webhook and certManager