What:
Allow 3Scale to use STS for authentication for S3 bucket usage.
This would require changes in the System component, to support authentication with AWS using a mounted file that contains signed token(which is automatically rotated every few minutes) and a AWS Role (role ARN would be passed in).
3Scale operator would have to support this alternative set of AWS credentials as well. With small assistance, RHOAM eng team would be able to contribute this part if necessary.
Please see also the attached issue MGDAPI-4140 and the doc that is attached to that issue.

Why:
OSD and ROSA products are introducing support for clusters that use AWS STS service for authentication, and don't use any IAM accounts. As a result, we are introducing support for these clusters in RHOAM addon (Epic brief). Previously we used OpenShifts Cloud Credentials Operator(CCO) to create an IAM account for 3Scale to grant access to the S3 bucket. This won't be possible on a cluster that uses STS because CCO won't create that IAM account for us.

How:
From a quick look at porta repo of 3Scale it looks like S3 bucket access is done via "paperclip 5.3.0" package' . This poses a few issues:
a) it seems like STS support was never merged into this package
b) this package is deprecated
P.S: the 5.3.0 version of paperclip package is more than 3 years old at this point.

Dev Notes

This is a rather big task and we have other pressing tasks at hand.
Looking at paperclip code, as pointed out, it can't pass down `:session_token`. Also in my understanding this option wouldn't be enough because that will be present in a file and the value will change every few minutes, so passing it down as a value will not help anyway.
My guess is that System must use tokens with the AssumeRoleWithWebIdentity mechanism. Let me know if this is the case.
This should be possible to do with current version of aws-sdk-core that we use in the fips branch. By generating AssumeRoleWebIdentityCredential. Also I assume `role_arn` will need to be provided somehow to system.
If all these assumptions are correct, we can investigate how that can be passed down to the S3 client with or without the help of Paperclip.
In either case, we have some pressing issues to take care of. It better stays for a 2.13.1 release, to avoid unnecessary delay of the fips feature, also limit the scope of possible regressions. This will also double the number of combinations of S3 configuration that QE will have to develop tests for.

Some historic info https://github.com/3scale/porta/pull/2601
See also this comment about permissions.
Documentation for configuring amazon S3 for 3scale 2.13 is here.