apache/hadoop · error · CredentialInitializationException

getCredentials failed: {e}

Error message

getCredentials failed: {e}

What it means

CredentialInitializationException from AssumedRoleCredentialProvider.resolveCredentials(): the retrying call to the STS provider's resolveCredentials (AssumeRole) raised an IOException that is not an SdkClientException, so it is wrapped as 'getCredentials failed'. The credentials used with STS come from the inner chain fs.s3a.assumed.role.credentials.provider (default: SimpleAWSCredentialsProvider + EnvironmentVariableCredentialsProvider).

Source

Thrown at hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/auth/AssumedRoleCredentialProvider.java:187

  /**
   * Get credentials.
   * @return the credentials
   * @throws StsException if none could be obtained.
   */
  @Override
  @Retries.RetryRaw
  public AwsCredentials resolveCredentials() {
    try {
      return invoker.retryUntranslated("resolveCredentials",
          true,
          stsProvider::resolveCredentials);
    } catch (IOException e) {
      // this is in the signature of retryUntranslated;
      // its hard to see how this could be raised, but for
      // completeness, it is wrapped as an Amazon Client Exception
      // and rethrown.
      throw new CredentialInitializationException(
          "getCredentials failed: " + e,
          e);
    } catch (SdkClientException e) {
      LOG.error("Failed to resolve credentials for role {}",
          arn, e);
      throw e;
    }
  }

  /**
   * Propagate the close() call to the inner stsProvider.
   */
  @Override
  public void close() {
    S3AUtils.closeAutocloseables(LOG, stsProvider, credentialsToSTS, stsClient);
  }

  @Override

View on GitHub (pinned to 2add963021)

Solutions

  1. Inspect the wrapped IOException - it carries the underlying STS failure detail
  2. Verify the inner chain resolves base credentials (simple/env providers by default) and its keys are valid
  3. Check network access to STS (sts.<region>.amazonaws.com): create a VPC endpoint or set fs.s3a.assumed.role.sts.endpoint and fs.s3a.assumed.role.sts.region
  4. Confirm the role's trust policy allows this principal and session options (name, duration, policy) are valid

Example fix

# before: locked-down VPC, no STS egress -> getCredentials failed

<!-- after: point S3A at an STS VPC endpoint -->
<property>
  <name>fs.s3a.assumed.role.sts.endpoint</name>
  <value>https://vpce-0abc.sts.eu-west-1.vpce.amazonaws.com</value>
</property>
<property>
  <name>fs.s3a.assumed.role.sts.region</name>
  <value>eu-west-1</value>
</property>
Defensive patterns

Strategy: try-catch

Validate before calling

// Preflight STS reachability before jobs depend on assumed-role auth
new URL("https://sts." + region + ".amazonaws.com")
    .openConnection().setConnectTimeout(3000); // throws on no route

Try / catch

catch CredentialInitializationException with message 'getCredentials failed'; unwrap getCause() to get the STS detail - fix network/endpoint/inner-credentials rather than retrying (the provider already retried)

Prevention

When it happens

Trigger: Assumed-role auth where the STS AssumeRole call keeps failing through retries: no route to the STS endpoint, a misconfigured fs.s3a.assumed.role.sts.endpoint/region, the inner provider chain erroring with an IOException, or invalid session parameters.

Common situations: VPC without internet egress or STS endpoint; custom STS endpoint typos or wrong region; role trust policy rejecting the caller; base credentials for the inner chain missing so STS cannot be signed; proxies blocking STS.

Related errors


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/860558aa4e8e4949. Report an issue: GitHub.