Adds business metrics for credential providers

[cenedhryn]

Motivation and Context

Tracking how credentials were resolved

Modifications

• Adds a number of new business metrics feature IDs representing credential sources
• Changes existing providerNames to the new metrics values
• Adds more combinations and sources of credential providers
• Introduces a new public API param source on some builders for credential providers. It's the only non-trivial way to link more than one metrics value together

Deviations from specs:

• Not using SSO legacy u because it doesn't make sense - It's already tracked as legacy via theCREDENTIALS_PROFILE_SSO_LEGACY t value. Once in the SSO provider legacy doesn't really matter. The regular CREDENTIALS_PROFILE_SSO value of s can be used for both cases. You can't really set a legacy client without coming from the profile
• Not tracking the exact parent provider for source profile and/or named provider / credential_source use cases. The method (source profile or named provider) is tracked in both the source provider call and the final credential provider call, but the final credential provider call will not emit exactly what the source provider was. For instance, if named provider with IMDS is used, we should track p,0 for the imds call and p,0,i for the credential metrics: named provider followed by imds followed by assume role. Instead, we'll have p,0 and p,i for the imds call and the assume roll call respectively.
• Not tracking named provider where the source provider is env vars provider. It's an unusual case and doesn't warrant rewriting the provider.

Testing

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[sonarqubecloud]

Quality Gate failed

Failed conditions
79.3% Coverage on New Code (required ≥ 80%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[dagnir]

Not tracking the exact parent provider for source profile and/or named provider / credential_source use cases. The method (source profile or named provider) is tracked in both the source provider call and the final credential provider call, but the final credential provider call will not emit exactly what the source provider was. For instance, if named provider with IMDS is used, we should track p,0 for the imds call and p,0,i for the credential metrics: named provider followed by imds followed by assume role. Instead, we'll have p,0 and p,i for the imds call and the assume roll call respectively.

Can you elaborate further on why getting p,0,1 is not possible or difficult? I don't think I quite understood from this explanation.

[dagnir]

Probably missed something, but why are we checking for m/D here? (D being RETRY_MODE_LEGACY).

[cenedhryn]

I think there is a pretty large bug in how the user agent is constructed, putting credential provider business metrics in auth source but not in m.

[dagnir]

Why did we remove this test?

[cenedhryn]

Because there is also a SystemSettingCredentialsProvidersTest that is more extensive 🙄

[dagnir]

The javadoc implies this this might better as a List<String>, any reason it isn't?

[cenedhryn]

See the general comment. I think the question of List or not List will become clearer if I go through the APIs for source again.

[cenedhryn]

Not tracking the exact parent provider for source profile and/or named provider / credential_source use cases. The method (source profile or named provider) is tracked in both the source provider call and the final credential provider call, but the final credential provider call will not emit exactly what the source provider was. For instance, if named provider with IMDS is used, we should track p,0 for the imds call and p,0,i for the credential metrics: named provider followed by imds followed by assume role. Instead, we'll have p,0 and p,i for the imds call and the assume roll call respectively.

Can you elaborate further on why getting p,0,1 is not possible or difficult? I don't think I quite understood from this explanation.

When I look at the code again, I think it will work. In this example, ideally the user agent should contain p,0,i for the main call. First, the profile credentials provider is called and in ProfileCredentialsUtils, the use case for named provider is selected based on the settings in roleAndCredentialSourceBasedProfileCredentialsProvider. That's where the p is recorded. Then, the code selects the base credentials provider. This is where I went astray before, but retrieving the source from the base credentials provider, 0 should be doable, and then concatenate with the p, and submitting p,0 to STS.

Overall the question of whether composite sources should be concatenated String or List - I'm still leaning towards concatenated String.

There is a fair amount of refactoring that needs to be done because toString cannot and should not be used to retrieve the business metric. I have to roll back some weird code.