Process mining log extraction from cloud storage fails due to IAM permissions

BPM Mendix
, , , , , , , ,
1

We’re running process mining jobs in our cloud-deployed Mendix 9.18 environment, pulling event logs from AWS S3 buckets. The extraction consistently fails with AccessDenied errors when the process mining module attempts to read CSV files from our designated S3 bucket. We’ve verified the IAM role attached to our Mendix runtime has S3 read permissions, but the bucket policy seems to be blocking access. Additionally, we suspect VPC endpoint restrictions might be interfering with the connection.


Error: AccessDenied - Status Code: 403
Bucket: process-logs-prod
Key: mining/event_logs_2025_Q1.csv

The same configuration worked perfectly in our on-premise test environment. Has anyone encountered similar IAM policy conflicts when deploying process mining to Mendix Cloud?

2

I’ve seen this exact issue before. The problem is usually that your IAM policy allows S3 actions, but the bucket policy explicitly denies requests that don’t come through the VPC endpoint. Check if your S3 bucket has a condition like aws:SourceVpce that restricts access. Your Mendix Cloud environment needs to route through the correct VPC endpoint ID.

3

Update: I got the VPC endpoint ID from Mendix support and added it to the bucket policy condition. Still getting AccessDenied though. I’m wondering if the issue is with how the process mining module authenticates to S3. Does it use the runtime’s IAM role automatically, or do I need to configure credentials somewhere in the module settings?

4

One thing that’s often overlooked - check if your bucket policy has the Principal set correctly. If it’s too restrictive and only allows specific IAM users rather than roles, that could cause the AccessDenied. Your Mendix runtime assumes a role, not a user. Make sure the bucket policy includes the role ARN that Mendix uses, and that the IAM policy attached to that role grants the necessary S3 permissions. The intersection of both policies determines actual access.

5

You need to check both sides. In Mendix Cloud, your environment runs in a managed VPC. Contact Mendix support to get the VPC endpoint ID they’re using for S3 access in your region. Then update your S3 bucket policy to whitelist that specific endpoint. Also verify your IAM role has s3:GetObject and s3:ListBucket permissions explicitly for your bucket ARN. The role policy and bucket policy both need to align.

6

Let me provide a comprehensive solution that addresses all three aspects - IAM policy, S3 bucket policy, and VPC endpoint configuration.

IAM Policy Misconfiguration Fix: First, verify your Mendix runtime’s IAM role has this policy attached:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:ListBucket"],
  "Resource": ["arn:aws:s3:::process-logs-prod/*"]
}

S3 Bucket Policy Alignment: Your bucket policy needs to allow the IAM role AND the VPC endpoint. Update it to:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::ACCOUNT:role/MendixRuntimeRole"},
  "Condition": {"StringEquals": {"aws:SourceVpce": "vpce-xxxxx"}}
}

Replace MendixRuntimeRole with your actual role name and vpce-xxxxx with the VPC endpoint ID from Mendix support.

VPC Endpoint Restrictions: Ensure your VPC endpoint has a policy that allows S3 actions. The endpoint policy should not be more restrictive than your bucket policy. If you’re using a custom VPC endpoint policy, verify it includes:

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::process-logs-prod/*"
  }]
}

Critical Steps:

  1. Remove any hardcoded AWS credentials from your Mendix app (constants/environment variables)
  2. Verify the IAM role trust relationship allows sts:AssumeRole from the EC2 service
  3. Test connectivity using AWS CLI from within your Mendix environment if possible
  4. Check CloudTrail logs for the exact IAM principal being used in failed requests
  5. Ensure your S3 bucket and VPC endpoint are in the same AWS region

Common Gotcha: If your bucket policy uses aws:SourceVpc instead of aws:SourceVpce, it won’t work with VPC endpoints. Always use aws:SourceVpce for endpoint-based access control.

After applying these changes, restart your Mendix runtime to ensure the IAM role is properly assumed. The process mining extraction should work within 5-10 minutes of the policy updates propagating through AWS.

7

Thanks for the pointer. I checked our bucket policy and you’re right - there’s a condition requiring aws:SourceVpce. However, I’m not sure how to identify which VPC endpoint our Mendix Cloud runtime is using. Is this something I need to configure in the Mendix Developer Portal, or should I be looking at AWS side?

8

The process mining module should use the runtime’s IAM role automatically through instance metadata. However, there’s a common pitfall: if you have any explicit AWS credentials configured in your Mendix app constants or environment variables, those will take precedence over the IAM role. Check your app for any constants like AWS_ACCESS_KEY_ID or similar - remove them to force IAM role usage. Also ensure IMDSv2 is properly configured if you’re on newer Mendix Cloud infrastructure.