Allow Multiple AWS Credential Provider in AWS Signing Auth Plugin

[abhisek]

Currently the awsSigningAuthPlugin validates that there can only be 1 signing credential
https://github.com/open-policy-agent/opa/blob/main/plugins/rest/rest_auth.go#L568-L572

The plugin is used to add authentication credentials into a prepared HTTP request and not used to make any AWS API calls. But it would be very useful if multiple signing credentials can be supported for example:

• Profile
• Environment
• Metadata
• [...]

This helps in cases where the same configuration is used in different environment. For example:

• Developer local using profile or environment credentials
• Deployed / Higher environments using IMDS

What part of OPA would you like to see improved?

awsSigningAuthPlugin REST Auth plugin enhanced to support multiple s3_signing credentials provider.

Describe the ideal solution

When s3_signing is enabled with a config such as:

s3_signing: {}

Try out all the supported credential provider in a order that is consistent with AWS SDK behaviour. Example Java DefaultAWSCredentialsProviderChain

Fallback to current behavior if a credential provider is explicitly configured.

Describe a "Good Enough" solution

To be backward compatible extend the existing config schema with additional providers:

s3_signing:
  profile_credentials: {}
  environment_credentials: {}
  metadata_credentials: {}

Maintain an internal order for credential providers and try each credential provider from config till success. Fail if none are successful in obtaining a signing credential.

Additional Context

Proposed approach to do this:

• Enhance validateConfig to accept new behaviour
• Refactor signv4 to accept an array of credential provider and accept credentials from the first successful provider
• Implement an util method to provide an ordered list of credential provider from config
• Misc refactoring required to support multiple providers
• Update test cases

[anderseknert]

Thanks @abhisek! I think I like the "good enough" solution better than the "ideal" one, as I think it offers less surprises to keep things explicitly defined. Any particular reason not to do it that way?

(Also, yes — we'll need to ensure existing configurations keep working like previously)

Is this something you'd like to work on? 😃

[srenatus]

I agree with less surprises. The only caveat I see in the "good enough" solution is that you could think that the location in the config determines the order in which they're tried -- but we can't do that since it's object keys and objects aren't ordered. So the ordering will have to be hardcoded, but the appearance of keys there (profile_credentials, environment_credentials etc) will determine which of them are tried in that order.

[abhisek]

Thanks @anderseknert @srenatus for your feedback.

Should we go ahead with Good Enough solution? We can maintain an internal ordering for the credentials provider in line with default AWS SDK behavior.

I can take this up. Feel free to assign it to me.

[anderseknert]

Go for it! 👍 Feel free to use the #development channel on the OPA slack should you have any questions in the process. Or here , of course :)