Multi-Tenancy

Multi-tenancy allows multiple isolated workloads, teams, or customers to share a single MinIO AIStor deployment while maintaining data isolation and access control.

The recommended approach uses a single deployment with IAM-based isolation. Each tenant is represented as an IAM user or group with policies that restrict access to specific buckets or prefixes.

This provides:

• Resource efficiency with a single server process
• Centralized management
• Consistent security policies
• Simplified operations and monitoring
• Support for thousands of tenants

Create dedicated buckets for each tenant:

mc mb ALIAS/tenant-alpha
mc mb ALIAS/tenant-beta

Create a policy file for each tenant that restricts access to their bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*"],
      "Resource": [
        "arn:aws:s3:::tenant-alpha",
        "arn:aws:s3:::tenant-alpha/*"
      ]
    }
  ]
}

Apply the policy:

mc admin policy create ALIAS tenant-alpha-policy tenant-alpha-policy.json

mc admin user add ALIAS tenant-alpha-user tenant-alpha-password
mc admin policy attach ALIAS tenant-alpha-policy --user tenant-alpha-user

For applications, create service accounts with scoped access:

mc admin accesskey create ALIAS tenant-alpha-user \
  --name "alpha-app-1" \
  --description "Application 1 for tenant alpha"

Service accounts inherit the parent user’s policy by default, or can have custom policies attached.

Organize tenant users into groups for easier management:

mc admin group add ALIAS tenant-alpha-admins tenant-alpha-user1 tenant-alpha-user2
mc admin policy attach ALIAS tenant-alpha-policy --group tenant-alpha-admins

For large-scale multi-tenancy, integrate with external identity providers:

• OpenID Connect: Keycloak, Okta, Auth0, Azure AD
• LDAP/Active Directory: Map LDAP groups to MinIO AIStor policies

See Identity and Access Management for identity provider configuration.

For scenarios where tenants share buckets but need isolated prefixes:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*"],
      "Resource": ["arn:aws:s3:::shared-bucket/tenant-alpha/*"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::shared-bucket"],
      "Condition": {
        "StringLike": {
          "s3:prefix": ["tenant-alpha/*"]
        }
      }
    }
  ]
}

Track per-tenant storage consumption:

mc stat ALIAS/tenant-alpha

Export usage metrics for billing or capacity planning:

mc admin prometheus metrics ALIAS bucket

Integrate these metrics with your billing or capacity planning systems.

Apply per-bucket rate limiting to ensure fair resource allocation across tenants. See Quality of Service for full configuration details.

mc qos rule add ALIAS/tenant-alpha \
  --api "s3.GetObject" --rate 100 --burst 50 \
  --id "get-limit" --limit rps --priority 1

mc qos rule add ALIAS/tenant-alpha \
  --api "s3.List*" --rate 50 \
  --id "list-limit" --limit concurrency --priority 2

QoS supports both requests-per-second (rps) and concurrent request (concurrency) limits per S3 API operation.

Use bucket-level metrics to monitor per-tenant resource consumption through Prometheus.

1. Naming convention: Use consistent bucket naming such as {tenant-id}-{purpose}.
2. Policy templates: Create reusable policy templates for common access patterns.
3. Audit logging: Enable audit logging to track tenant activity.
4. Encryption: Use per-tenant encryption keys with KMS integration.
5. Backup strategy: Implement per-tenant backup policies using replication.