Need it to work on fargate

I think while not as explicit, the patch attached should do what you're looking for...
Rather than requiring extras config to explicitly define what config provider to use, i suggest we leave this to the defaultProvider and let AWS worry about the logic.

The patch simply checks to see if either the access or secret keys are empty.. if either is, don't define $config['credentials'] at all...
This leaves the heavy lifting to the following...

Aws\Credentials\CredentialProvider::defaultProvider is the default credential provider. This provider is used if you omit a credentials option when creating a client. It first attempts to load credentials from environment variables, then from an .ini file (an .aws/credentials file first, followed by an .aws/config file), and then from an instance profile (EcsCredentials first, followed by Ec2 metadata).

https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/guide_credent...

I've left `use instance profile` intact but realistically we could remove this and leave it as standard, allowing people to not define credentials at all.

Hi,

I think, To work this module with fargate, it will be a part of the s3fs module configuration. So while configuring the module developer can also choose this to run with the fargate.

Reroll the previous patch as it failed to apply

https://aws.amazon.com/about-aws/whats-new/2020/04/aws-fargate-launches-... says:

Fargate tasks now support Amazon Elastic File System (EFS) endpoints

You can now launch Fargate tasks with persistent EFS storage using platform version 1.4.0. This new capability enables applications that require data persistence and shared storage by mounting EFS volumes inside your Fargate task. Customers can now migrate applications to Fargate like content management systems (e.g. WordPress and Drupal) or applications that share a common data set.

So maybe S3FS isn't necessary anymore.

I'm not sure why this module is trying to do so much of the heavy lifting with getting credentials. It would work a lot better if it would just call CredentialProvider::defaultProvider() in the SDK and let the SDK determine where the credentials are living. That would save a lot of headache and make this module more widely usable.

Right now it seems like the module is deliberately trying to limit us to using an EC2 box.

Here's how I did it without any extra code in the module:

1. Use Systems Manager to create Parameters to store your keys
2. Register those parameters as Environment Variables in your ECS Task Definition
3. Use the Environment Variables in your settings file

@J2:

It would work a lot better if it would just call CredentialProvider::defaultProvider() in the SDK and let the SDK determine where the credentials are living.

Isn't that the way how the patch from zach.bimson in #3 is working? If use_instance_profile and (access_key || secret_key) are not set; as stated in #3:

Aws\Credentials\CredentialProvider::defaultProvider is the default credential provider. This provider is used if you omit a credentials option when creating a client.

Anyway, for #3 the function s3fs_requirements() needs to be adjusted.

EDIT:

I guess #3121830: Use CredentialProvider::defaultProvider rather than individual providers is what J2 meant.

EDIT2:

Patch from #9 needs to memoize the credentials, see documentation/example for ecsCredentials provider:

$provider = CredentialProvider::ecsCredentials();
// Be sure to memoize the credentials
$memoizedProvider = CredentialProvider::memoize($provider);

I investigated a bit more and although #3 is a nice solution, it requires modifications in more places, for example in the install file in function s3fs_requirements() and the validation callback. For now I prefer a similar aproach to #9, adding a new options to the config form, but using CredentialProvider::defaultProvider() instead of CredentialProvider::ecsCredentials(). The patch does not have much in common with #9 therefore I didn't add an interdiff.

I am not sure if we need the option 'Use EC2 Instance Profile Credentials' for backward compatibility, otherwise I would prefer to remove that and have just the default provider as recommended by J2 in #12 and, of course, the credentials in the settings file, which will be necessary (in addition to #3121830: Use CredentialProvider::defaultProvider rather than individual providers), as not all sites are running on amazon infrastructure).

The current solution worked for me. Before removing 'Use EC2 Instance Profile Credentials' I would like to have some feedback. If both options should be kept, I guess it would be better to use radio buttons instead of two checkboxes hiding the other one – but that requires implementing an update hook.

I missed some checks in S3fsService::validate() and s3fs_requirements().

The test testS3fsConfigurationForm() seems to not work anymore, does it?

(just restored the issue summary to the state before J2 change)

I believe this should be fixed by the changes made in #3121830: Use CredentialProvider::defaultProvider rather than individual providers

That issue is a culmination of information pulled from this issue and several others.