Amazon S3 Connector Authentication

The MuleSoft Amazon S3 Connector supports several authentication methods. Choosing the right one depends on where your Mule application is deployed. The golden rule is: use an IAM Role whenever possible, never hardcode credentials.

Authentication Methods

The connector offers three connection types:

Recommendation by Deployment Target

CloudHub 2.0 / Runtime Fabric on AWS — IAM Role (Best Practice)

When your Mule workers run on your own EC2 or ECS nodes, attach an IAM Role directly to the compute resource. The AWS SDK picks it up automatically through the Default Credentials Provider Chain — no credentials to configure, rotate, or risk leaking.

Configure the connector with the default-connection type:

1
2
3
<amazon-s3:config name="s3-config">
    <amazon-s3:default-connection region="eu-west-1"/>
</amazon-s3:config>

No accessKey or secretKey attribute in the config at all. This is the recommended approach because it eliminates long-lived credentials entirely.

CloudHub 1.0 — IAM User with Secure Properties

CloudHub 1.0 runs on MuleSoft-managed infrastructure, so you cannot attach an IAM Role to the worker directly. Use a dedicated IAM User with programmatic access, but always store credentials using the Mule Secure Properties module or Anypoint Secrets Manager:

1
2
3
4
5
6
<amazon-s3:config name="s3-config">
    <amazon-s3:basic-connection
        accessKey="${secure::aws.s3.accessKey}"
        secretKey="${secure::aws.s3.secretKey}"
        region="eu-west-1"/>
</amazon-s3:config>

Never use plain ${aws.s3.secretKey} for sensitive values. The secure:: prefix ensures the value is decrypted at runtime and never stored in plaintext.

Runtime Fabric On-Premises / Non-AWS Deployments

Use a dedicated IAM User with Access Key and Secret, stored in Anypoint Secrets Manager. Treat these credentials the same as CloudHub 1.0.

Decision Guide

Is your deployment on CloudHub 2.0 or Runtime Fabric running on AWS?
├── YES → IAM Role attached to the node group
│         Use Default Credentials Provider Chain in connector config
│         No credentials in Anypoint at all
└── NO  → Dedicated IAM User
          Store credentials in Anypoint Secrets Manager
          Reference via ${secure::...} in global.xml
          Rotate keys every 90 days

Required IAM Permissions

Whether you use an IAM Role or IAM User, the attached policy should follow least privilege. Scope it to the specific bucket and only the actions your flow actually performs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BucketLevel",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::your-bucket-name"
    },
    {
      "Sid": "ObjectLevel",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:CopyObject",
        "s3:GetObjectMetadata"
      ],
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

Only add s3:ListAllMyBuckets on "Resource": "*" if your flow uses the List Buckets operation and genuinely needs to enumerate all buckets.

Trust Policy for IAM Role

If you are using an IAM Role (Runtime Fabric on AWS), the role needs a trust policy that allows the compute service to assume it:

1
2
3
4
5
6
7
8
9
10
11
12
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Replace ec2.amazonaws.com with ecs-tasks.amazonaws.com for ECS/Fargate deployments.

What to Avoid

Summary

The IAM Role approach is always preferred because it removes long-lived credentials from the equation entirely. When you must use an IAM User, use ${secure::...} properties and rotate keys on a regular schedule.