AWS Credentials with No File IO possible

Question

I have an application that runs inside a framework. The framework does not permit FILE IO and throws all kinds of security exceptions killing my application.

I can pass the accessKeyId and secretAccessKey via system properties and they are passed correctly.

The problem I have is that no matter what I do the default in the AWS SDK always tries to get the credentials via File IO first (looking for its ~/.aws/credentials) and thus kills everything.

Is there anyway to inhibit that file attempt ? Or another way to do this ?

I am using aws java SDK2. Weirdly SDK1 seems to work OK but but is too big as it can no be broken into modules like SDK2 can be.

        private SqsClient initialiseClient() {
        System.out.println(System.getProperty("aws.accessKeyId")); // this works
        System.out.println(System.getProperty("aws.secretAccessKey"));  // this works

        return SqsClient.builder()
                .credentialsProvider(SystemPropertyCredentialsProvider.create())
                .region(Region.EU_WEST_1)
                .build());
        }

Stack Trace:

    Exception in thread "Thread-28" java.security.AccessControlException: access denied ("java.io.FilePermission" "C:\Users\username\.aws\credentials" "read")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
    at java.security.AccessController.checkPermission(AccessController.java:884)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
    at sun.nio.fs.WindowsPath.checkRead(WindowsPath.java:792)
    at sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(WindowsFileAttributeViews.java:49)
    at sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(WindowsFileAttributeViews.java:38)
    at sun.nio.fs.WindowsFileSystemProvider.readAttributes(WindowsFileSystemProvider.java:193)
    at java.nio.file.Files.readAttributes(Files.java:1737)
    at java.nio.file.Files.isRegularFile(Files.java:2229)
    at software.amazon.awssdk.profiles.ProfileFileLocation.lambda$resolveIfExists$1(ProfileFileLocation.java:128)
    at java.util.Optional.filter(Optional.java:178)
    at software.amazon.awssdk.profiles.ProfileFileLocation.resolveIfExists(ProfileFileLocation.java:128)
    at software.amazon.awssdk.profiles.ProfileFileLocation.credentialsFileLocation(ProfileFileLocation.java:78)
    at software.amazon.awssdk.profiles.ProfileFile.addCredentialsFile(ProfileFile.java:138)
    at software.amazon.awssdk.utils.builder.SdkBuilder.applyMutation(SdkBuilder.java:61)
    at software.amazon.awssdk.profiles.ProfileFile.defaultProfileFile(ProfileFile.java:90)
    at software.amazon.awssdk.core.client.builder.SdkDefaultClientBuilder.mergeGlobalDefaults(SdkDefaultClientBuilder.java:196)
    at software.amazon.awssdk.core.client.builder.SdkDefaultClientBuilder.syncClientConfiguration(SdkDefaultClientBuilder.java:149)
    at software.amazon.awssdk.services.sqs.DefaultSqsClientBuilder.buildClient(DefaultSqsClientBuilder.java:27)
    at software.amazon.awssdk.services.sqs.DefaultSqsClientBuilder.buildClient(DefaultSqsClientBuilder.java:22)
    at software.amazon.awssdk.core.client.builder.SdkDefaultClientBuilder.build(SdkDefaultClientBuilder.java:124)
    at net.something.fdDataExchange.messageHandlers.QMessageHandlerV2.lambda$initialiseClient$0(QMessageHandlerV2.java:66)
    at java.security.AccessController.doPrivileged(Native Method)
    at net.something.fdDataExchange.messageHandlers.QMessageHandlerV2.initialiseClient(QMessageHandlerV2.java:63)
    at net.something.fdDataExchange.messageHandlers.QMessageHandlerV2.connect(QMessageHandlerV2.java:52)
    at net.something.fdDataExchange.messageHandlers.QMessageHandlerV2.<init>(QMessageHandlerV2.java:47)
    at net.something.fdDataExchange.MessageHandler.receiveDirectMsg(MessageHandler.java:28)
    at net.something.fdDataExchange.commandProcessors.QCommandProcessor.run(QCommandProcessor.java:19)
    at java.lang.Thread.run(Thread.java:748)

Are you implying that the code snippet you have in your question still tries to access `~/.aws/credentials`? — Jacob G., Apr 10 '20 at 18:03
Yes it appears that all of the options seem to that I have tried from here at least. https://docs.aws.amazon.com/sdk-for-java/v2/developer-guide/credentials.html#credentials-explicit — DevilCode, Apr 10 '20 at 18:05
Are you sure you're running the latest version of your code? I looked at the source code for `SystemPropertyCredentialsProvider`, and it doesn't look like any attempt is made to access `~/.aws/credentials` — Jacob G., Apr 10 '20 at 18:07
Yes . We had look as well and the only reference to aws credentials is in profiles. we are also confused and nearly out of hair to pull out. — DevilCode, Apr 10 '20 at 18:12
@JacobG The AWS SDK does some sneaky pointless auto-initialization that absolutely wrecks the system in all sorts of situations (such as having IAM credentials for local use that your application magically misadopts). OP, please post the entire stack trace to see where that's getting thrown from. — chrylis -cautiouslyoptimistic-, Apr 10 '20 at 18:12
Is your `initialiseClient` method different from the `initClient` method you have in your question? — Jacob G., Apr 10 '20 at 18:19
Have the same issue with : StaticCredentialsProvider.create(AwsBasicCredentials.create(accessKey, secretKey)) — DevilCode, Apr 10 '20 at 18:27
This could very well be a bug on AWS' end. Could you try replacing your `credentialsProvider` with: `StaticCredentialsProvider.create(AwsBasicCredentials.create(System.getProperty("aws.accessKeyId"), System.getProperty("aws.secretAccessKey")))`? — Jacob G., Apr 10 '20 at 18:40
Yes - we tried this but it still fires off a check for Files (~/.aws/credentials). Am at a loss unless we can rewrite the SDK2 library class. — DevilCode, Apr 10 '20 at 20:08
@JacobG. Is the SDK open-source ? Would it be possible to rewrite that bit so we don't have the issue ? — DevilCode, Apr 10 '20 at 22:49

ricky roy · Answer 1 · 2020-04-10T18:50:41.543

You can try to implement a custom provider instead of using the system credential provider. Here is a small example to connect to S3 but it holds for any service for AWS. And here is the link for your reference: https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html

BasicAWSCredentials awsCreds = new BasicAWSCredentials("access_key_id", "secret_key_id");
AmazonS3 s3Client = AmazonS3ClientBuilder.standard()
                        .withCredentials(new AWSStaticCredentialsProvider(awsCreds))
                        .build();

For SDK2 maybe this should work:

To explicitly supply credentials to an AWS client

Instantiate a class that provides the AwsCredentials interface, such as AwsSessionCredentials. Supply it with the AWS access key and secret key to use for the connection.

Create an StaticCredentialsProvider with the AwsCredentials object.

Configure the client builder with the StaticCredentialsProvider and build the client.

The following example creates a new service client that uses credentials that you supplied:

AwsSessionCredentials awsCreds = AwsSessionCredentials.create(
    "your_access_key_id_here",
    "your_secret_key_id_here",
    "your_session_token_here");

S3Client s32 = S3Client.builder()
                       .credentialsProvider(StaticCredentialsProvider.create(awsCreds))
                       .build();

Source: https://docs.aws.amazon.com/sdk-for-java/v2/developer-guide/credentials.html

Hope it helps!

Thanks, however we still see the same issue. All methods seam to force the File IO check for the ~/.aws/credentials file. Your code would work otherwise. We are unfortunate in that the checking or use of file io kills our application due to the frameworks security parameters. — DevilCode, Apr 11 '20 at 00:07

AWS Credentials with No File IO possible

1 Answers1