AWS

Islo can give a sandbox access to your AWS account without ever putting long-lived credentials inside the sandbox. You register an IAM role you own, and the sandbox assumes it via STS.

Any tool that uses the AWS SDK default credential chain — AWS CLI, boto3, the Go/JS SDKs, mount-s3, Terraform — works out of the box. No env vars, no ~/.aws/credentials, no per-tool configuration.

How it works

1. You create an IAM role in your AWS account with a trust policy that allows Islo to assume it.
2. You register that role with Islo as a cloud role, which returns an External ID you paste into the trust policy.
3. You attach the cloud role to a gateway profile.
4. Any sandbox attached to that gateway can call AWS APIs as that role, with no credentials in the sandbox.

Prerequisites

• An Islo account and API key — see Authentication.
• Permission to create IAM roles in the target AWS account.

1. Create the IAM role in AWS

Create a role in your AWS account with whatever permissions the sandbox should have. The example below scopes to a single S3 bucket; substitute any other AWS service.

Permissions policy (example — read/write a bucket):

1
{
2
  "Version": "2012-10-17",
3
  "Statement": [{
4
    "Effect": "Allow",
5
    "Action": ["s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
6
    "Resource": [
7
      "arn:aws:s3:::my-bucket",
8
      "arn:aws:s3:::my-bucket/*"
9
    ]
10
  }]
11
}

Trust policy — leave <ISLO_PRINCIPAL_ARN> and <EXTERNAL_ID> as placeholders for now; you’ll fill them in after step 2.

1
{
2
  "Version": "2012-10-17",
3
  "Statement": [{
4
    "Effect": "Allow",
5
    "Principal": {"AWS": "<ISLO_PRINCIPAL_ARN>"},
6
    "Action": "sts:AssumeRole",
7
    "Condition": {"StringEquals": {"sts:ExternalId": "<EXTERNAL_ID>"}}
8
  }]
9
}

The Islo Principal ARN is shown in the dashboard under Integrations → AWS.

2. Register the role with Islo

1
from islo import Islo
2
3
client = Islo()  # picks up ISLO_API_KEY
4
5
role = client.cloud_roles.create_cloud_role(
6
    provider="aws",
7
    role_arn="arn:aws:iam::123456789012:role/IsloAccessRole",
8
    session_duration_seconds=3600,  # optional — STS session lifetime
9
)
10
print(role.external_id)

Copy role.external_id and paste it into the trust policy you wrote in step 1, then save the IAM role.

3. Attach the role to a gateway profile

1
gateway = client.gateway_profiles.create_gateway_profile(
2
    name="aws-access",
3
    internet_enabled=True,
4
    cloud_role=role.id,
5
)

You can attach the same cloud role to multiple gateway profiles, or scope different gateways to different roles for least-privilege access.

4. Attach the gateway to a sandbox

1
client.sandboxes.create_sandbox(
2
    name="my-sandbox",
3
    gateway_profile=gateway.id,
4
)

That’s it. Inside the sandbox, any AWS SDK will discover credentials automatically.

Using AWS from inside the sandbox

Any AWS CLI or SDK call just works:

$
# AWS CLI without any AWS_* env vars set
$
aws s3 ls s3://my-bucket/
$
$
# boto3
$
python -c "import boto3; print(boto3.client('s3').list_buckets())"

Example: mount an S3 bucket with mount-s3

Mountpoint for Amazon S3 (mount-s3) is AWS’s official FUSE client. It uses the default credential chain, so once the gateway is attached, it works without any extra configuration.

Install it via a setup script when the sandbox is created:

1
from islo.types.setup_script import SetupScript
2
3
install_mount_s3 = (
4
    "set -e && cd /tmp && "
5
    "curl -fsSL -O https://s3.amazonaws.com/mountpoint-s3-release/latest/x86_64/mount-s3.deb && "
6
    "sudo apt-get update -y && sudo apt-get install -y ./mount-s3.deb"
7
)
8
9
client.sandboxes.create_sandbox(
10
    name="my-sandbox",
11
    gateway_profile=gateway.id,
12
    setup_scripts=[SetupScript(name="install-mount-s3", script=install_mount_s3)],
13
)

Then mount the bucket once the sandbox is up:

1
client.sandboxes.exec_in_sandbox(
2
    sandbox_name="my-sandbox",
3
    command=["bash", "-lc",
4
        "sudo mkdir -p /mnt/s3 && "
5
        "sudo mount-s3 my-bucket /mnt/s3 "
6
        "--region us-east-1 "
7
        "--allow-overwrite --allow-delete --allow-other "
8
        "--uid $(id -u islo) --gid $(id -g islo)"
9
    ],
10
)

/mnt/s3 is now the bucket. The --uid/--gid flags map file ownership to the islo user, and --allow-other lets islo read/write through the root-owned mount.

Troubleshooting

No signing credentials available / no creds discovered — the gateway isn’t attached to the sandbox, or you’re calling AWS too early (e.g. from a setup script, before the sandbox is fully up). Make the call after sandbox creation via exec_in_sandbox.

AccessDenied from S3 / DynamoDB / etc. — the IAM role’s permissions policy doesn’t grant the action you’re attempting. Check CloudTrail in the target AWS account for the exact denied action.

AccessDenied from STS during gateway provisioning — Islo couldn’t assume your role. Verify the trust policy: the Principal must match the Islo principal shown in the dashboard, and the ExternalId condition must match the value create_cloud_role returned.