Access Control | Tigris Object Storage Documentation

On this page

When you create access keys through the Partner API, two fields control what those keys can do:

user_role controls what your user can do through the management API (listing keys, updating org settings).
buckets_roles controls what S3 operations the access key can perform on specific buckets.

These two fields are independent. They apply at different times and serve different purposes.

Field	Where it applies	What it controls
`user_role`	Partner API calls	Management scope: list all keys vs own keys, org settings
`buckets_roles`	S3 data operations	What the access key can read, write, or manage per bucket

Two Layers of Access Control

POST /access-keys	user_role + buckets_roles
`user_role`	`buckets_roles`
Management Scope	S3 Operations (per bucket)
`Admin`	All keys, org settings, users
`Member`	Own keys only
Default if omitted: `Member`	ReadOnly Get, list, head
	Editor+ put, delete, bucket config
	Admin All ops, bypasses all checks

Organization Role (`user_role`)

The user_role field tells Tigris what privileges this user has in your system. You pass it on provisioning, access key, and org management endpoints.

Value	What it means
`Admin`	Full org access. Can manage all access keys, update org settings, and view all resources.
`Member`	Standard access. Can only manage their own access keys and resources.

The behavioral difference shows up immediately. When you call List Access Keys with user_role: "Admin", the response includes all access keys in the org. With user_role: "Member" (or omitted), you get back only keys owned by that user.

This same scoping applies to other management operations. Admin-only operations include:

Manage all access keys — view, rotate, or delete any key in the org, not just the user's own
Update org settings — change org name, quotas, active status
Invite and manage users — send invitations, update roles, remove members

If you omit user_role, the user is treated as a Member. For most integrations, Member is the right default.

Bucket Roles (`buckets_roles`)

The buckets_roles field is an array of {bucket_name, role} pairs stored on the access key. Three roles are available: ReadOnly, Editor, and Admin. See the RBAC permissions table for exactly which S3 operations each role permits.

Use "*" as the bucket name to grant access to all buckets in the org. An access key with {\"bucket_name\": \"*\", \"role\": \"Admin\"} is treated as a full org admin, bypassing all bucket-level permission checks.

How the Two Fields Interact

user_role and buckets_roles apply at different times. Here's how common partner scenarios map to these fields:

Scenario	`user_role`	`buckets_roles`	Result
Developer uploads	`Member`	`[{