Skip to main content

IAM Policy


An IAM policy is a way to allow or deny users to perform certain actions in a Cubbit project.

You manage access to your Cubbit projects by creating policies and attaching them to IAM identities (users or groups of users).

Every time an IAM user makes a request, Cubbit evaluates the associated policies to allow or deny access to the resource.

IAM policies define permissions for actions regardless of the method you use to operate. For example, if a policy allows the GetUser action, then a user with that policy can get user information from the Cubbit Console or the Cubbit API.

Policy types

Cubbit supports 2 different policy types:

  • Identity-based policies: Attach policies to IAM identities i.e. users or groups of users. Identity-based policies grant permissions to an identity.
  • ACL: Use ACLs to control which users in other projects can access the resource to which the ACL is attached. (please see the dedicated section)

Identity-based policies

Identity-based policies are JSON permissions policy documents that control what actions an identity can perform, on which resources.

policy applied

Policies and the root user

The root user has by default all permissions over all resources on the project. This policy can't be changed or deleted. Moreover, it's impossible to assign any other policies to the root user.

Preset policies

When a project is created, some default policies are generated by default:

  • Owner: only the root user can be the assignee of the policy. This allows him to do any action on eny resource of the project.
  • Admin: this is a super user policy. With this policy assigned, a user has the same power as the owner.
  • Member: this policy allows the user to perform the majority of the action on S3 and IAM. It can't update or delete the project settings and assign policies.
  • ReadOnly: this policy allows the user to read only the entity of a project.

If you have the right permission, you can then create all the policy combinations you desire.

Policy Definition

Policies are stored in Cubbit as JSON documents. When you create a JSON policy, IAM can perform policy validation to help you create an effective policy. IAM identifies JSON syntax errors and the formal applicability of the policy, i.e. if the resource can be the target of the action.

Policy JSON structure

This is how a policy in Cubbit is defined

"id": "a912ec9a-4623-11ed-b878-0242ac120002",
"syntax_version": "2022-10-07", // Version of the document syntax
"name": "Unique Policy Name",
"description": "This is a generic description for the policy",
"statement": [
"effect": "allow", // or "deny"
"action": [
"resource": [


allow or deny as a String value


The action field is a list of strings with the action to allow. Every action starts with the domain service, followed by the separator : and then the action name.

See the dedicated section below for all the possible Actions.

Resource - CRN

List of possible resource names defined in Cubbit. This specifies to which resources the policy will be applied to.

The following are the general formats for CRNs. The specific formats depend on the resource.


  • crn: the static string needed by the validator

  • region: the region of the coordinator deploy

  • service: the service involved (s3, iam, hive,…)

  • tenant-id: the reference id to the tenant of your account (can be omitted)

  • swarm-id: the reference id to the geo-distributed cluster of Cubbit nodes (must be omitted)

  • project-id: the id of the project to which the specified resource belongs. (can be omitted)

  • resource-type: the entity provided by the service (user, group, policy, project, bucket, object)

  • resource-id: the specific id or name of the target resource

In some cases you want to target all the resources of a certain type. In that case, you can specify the wildcard * as resource-id.



At the moment the wildcard is allowed only for the resource-id segment

Another special target is self in the resource_id segment. This allows the policy to be generic and when you assign the policy to a specific user, the self keyword will be replaced with the id of the user. This special case can be used only combined with resource_type of user.


One or more actions are involved in the policy.

The actions must match the target resource in the CRN target. So for example you can't define a policy with iam:CreateGroup on a resource of type bucket

IAM Actions

ActionTarget ResourceDescription
iam:GetProjectprojectGrants permission to retrieve the project's information
iam:ManageProjectprojectGrants permission to update and delete the project
iam:CreateUserprojectGrants permission to create and invite a new IAM user
iam:ListUsersprojectGrants permission to get the list of IAM user of the project
iam:ManageUsersuserGrants permission to delete and update a IAM user
iam:GetUseruserGrants permission to retrieve a IAM user
iam:AttachUserPolicyuserGrants permission to attach a managed policy to the specified IAM user
iam:CreatePolicyVersionpolicyGrants permission to create a new version of the specified managed policy
iam:DeletePolicypolicyGrants permission to delete the specified managed policy and remove it from any IAM entities (users or groups) to which the policy is attached
iam:DetachUserPolicyuserGrants permission to detach a managed policy from the specified IAM user
iam:GetPolicypolicyGrants permission to retrieve information about the specified managed policy, including the policy's default version and the total number of identities to which the policy is attached
iam:ListAttachedUserPoliciesuserGrants permission to list all managed policies that are attached to the specified IAM user
iam:ListEntitiesForPolicypolicyGrants permission to list all IAM identities to which the specified managed policy is attached
iam:ListPoliciespolicyGrants permission to list all managed policies
iam:CreatePolicypolicyGrants permission to create a new managed policy
iam:CreateKeyuserGrants permission to create a new key
iam:ListKeysuserGrants permission to get the list of an user keys
iam:ManageKeyuserGrants permission to delete and update name of a key of an IAM user

To operate over the S3, so in example create buckets, uploads objects, you need to grant at least iam:CreateKey, iam:ManageKey and iam:ListKeys to your users

S3 Actions


Actions with CRN "Target Resource" of type * can be only used with *. No other values are permitted

ActionTarget ResourceDescription
s3:ListBucketbucketGrants permission to list some or all the objects in a Cubbit S3 bucket (up to 1000)
s3:ListBucketVersionsbucketGrants permission to list metadata about all the versions of objects in a Cubbit S3 bucket
s3:PutObjectobjectGrants permission to add an object to a bucket or a specific folder
s3:GetObjectobjectGrants permission to retrieve an object
s3:GetObjectVersionobjectGrants permission to retrieve a specific version of an object
s3:DeleteObjectobjectGrants permission to remove the null version of an object and insert a delete marker, which becomes the current version of the object
s3:DeleteObjectVersionobjectGrants permission to remove a specific version of an object
s3:AbortMultipartUploadobjectGrants permission to abort a multipart upload
s3:ListMultipartUploadPartsobjectGrants permission to list the parts that have been uploaded for a specific multipart upload
s3:GetObjectTaggingobjectGrants permission to return the tag set of an object
s3:GetObjectAclobjectGrants permission to return the access control list (ACL) of an object
s3:GetObjectVersionAclobjectGrants permission to return the access control list (ACL) of a specific object version
s3:PutObjectAclobjectGrants permission to set the access control list (ACL) permissions for new or existing objects in an S3 bucket
s3:PutObjectVersionAclobjectGrants permission to use the acl subresource to set the access control list (ACL) permissions for an object that already exists in a bucket
s3:PutObjectRetentionobjectGrants permission to place an Object Retention configuration on an object
s3:GetObjectRetentionobjectGrants permission to get the object retention
s3:PutObjectLegalHoldobjectGrants permission to apply a Legal Hold configuration to the specified object
s3:GetObjectLegalHoldobjectGrants permission to get the object legal hold config
s3:BypassGovernanceRetentionobjectGrants permission to delete a object protected by object retention
s3:ListAllMyBuckets*Grants permission to list all buckets owned by the authenticated sender of the request
s3:GetBucketVersioningbucketGrants permission to return the versioning state of an Cubbit S3 bucket
s3:GetEncryptionConfigurationbucketGrants permission to return the default encryption configuration an Cubbit S3 bucket
s3:CreateBucket*Grants permission to create a new bucket
s3:DeleteBucketbucketGrants permission to delete the bucket named in the URI
s3:PutBucketVersioningbucketGrants permission to set the versioning state of an existing Cubbit S3 bucket
s3:GetBucketOwnershipControlsbucketGrants permission to retrieve ownership controls on a bucket
s3:GetLifecycleConfigurationbucketGrants permission to return the lifecycle configuration information set on an Cubbit S3 bucket
s3:PutBucketOwnershipControlsbucketGrants permission to add, replace or delete ownership controls on a bucket, This also gives delete capability
s3:PutLifecycleConfigurationbucketGrants permission to create a new lifecycle configuration for the bucket or replace an existing lifecycle configuration.
s3:ListBucketMultipartUploadsbucketGrants permission to list in-progress multipart uploads
s3:GetBucketObjectLockConfigurationbucketGrants permission to get the Object Lock configuration of an Cubbit S3 bucket
s3:PutBucketObjectLockConfigurationbucketGrants permission to get the object lock configuration
s3:GetBucketAclbucketGrants permission to use the acl subresource to return the access control list (ACL) of an Cubbit S3 bucket
s3:PutBucketAclbucketGrants permission to set the permissions on an existing bucket using access control lists (ACLs)
s3:GetBucketLocationbucketGrants permission to get the bucket location
Endpoints and Permissions
A list of our API endpoints and the related policy action needed to perform the operation
GET /v1/projects/{{project_id}}iam:GetProject
PUT /v1/projects/{{project_id}}iam:ManageProject
DELETE /v1/projects/{{project_id}}iam:ManageProject (user must also be root)
POST /v1/usersiam:CreateUser
GET /v1/usersiam:ListUsers
POST /v1/users/inviteiam:CreateUser
GET /v1/user/{{user_id}}iam:GetUser
PATCH /v1/users/{{user_id}}iam:ManageUser
DELETE /v1/users/{{user_id}}iam:ManageUser
GET /v1/users/{{user_id}}/policiesiam:ListAttachedUserPolicies
POST /v1/users/{{user_id}}/policiesiam:ListAttachedUserPolicies
GET /v1/policiesiam:ListPolicies
POST /v1/policiesiam:CreatePolicy
DELETE /v1/policies/{{policy_id}}iam:DeletePolicy
GET /v1/policies/{{policy_id}}iam:GetPolicy
PUT /v1/policies/{{policy_id}}iam:CreatePolicyVersion
GET /v1/policies/{{policy_id}}/usersiam:ListEntitiesForPolicy
POST /v1/policies/{{policy_id}}/usersiam:AttachUserPolicy, iam:DetachUserPolicy, iam:GetPolicy
GET /v1/users/{{user_id}}/policiesiam:ListAttachedUserPolicies
POST /v1/users/{{user_id}}/policiesiam:AttachUserPolicy, iam:DetachUserPolicy, iam:GetPolicy

Other endpoints without policy validation

POST /v1/projectseveryone can create project
GET /v1/projectseveryone can list projects where he have an invitation
POST /v1/projects/{{id}}/joineveryone can join a project where he have an invitation

Those routes are available on KeyVault microservice

POST /api/v2/keys/{{name}} [post]iam:CreateKey
GET /api/v2/keys [get]iam:ListKeys
DELETE /api/v2/keys/{{key_id}} [delete]iam:ManageKey
PATCH /api/v2/keys/{{key_id}} [patch]iam:ManageKey
POST /api/v3/keys/{{name}}?user_id={{user_id}}iam:CreateKey
GET /api/v3/keys?user_id={{user_id}}iam:ListKeys
DELETE /api/v3/keys/{{key_id}}?user_id={{user_id}}iam:ManageKey
PATCH /api/v3/keys/{{key_id}}?user_id={{user_id}}iam:ManageKey

user_id is optional and if omitted the behavior is the same as v2.


The following are the S3 APIs and their corresponding policies required.

APIsPolicyTarget Resource
HeadBucket, ListObjects, ListObjectsV2s3:ListBucketbucket
HeadObject, GetObjects3:GetObject or s3:GetObjectVersionobject
PutObject, UploadPart, CreateMultipartUpload, CompleteMultipartUploads3:PutObjectobject
DeleteObject, DeleteObjectss3:DeleteObject or s3:DeleteObjectVersionobject
CopyObjects3:GetObject/s3:GetObjectVersion on source and s3:PutObject on destinationobject on source and bucket on destination
GetObjectAcls3:GetObjectAcl or s3:GetObjectVersionAclobject
PutObjectAcls3:PutObjectAcl or s3:PutObjectVersionAclobject
PutBucketOwnershipControls, DeleteBucketOwnershipControlss3:PutBucketOwnershipControlsbucket
PutBucketLifecycleConfiguration, DeleteBucketLifecycles3:PutLifecycleConfigurationbucket

ACL combinations

In the following table we want to show the combinations with ACL in some useful case

Root/IAMIAM policyACLEntity owner Result
Root ✅  ❌  ❌  ❌  ✅  ❌  ❌
Root ✅  ❌  ❌  ✅  ❌  ❌  ✅
IAM ❌  ❌  ✅  ❌  ✅  ❌  ❌
IAM ❌  ❌  ✅  ✅  ❌  ❌  ❌
IAM ❌  ✅  ❌  ❌  ✅  ❌  ❌
IAM ❌  ✅  ❌  ✅  ❌  ❌  ❌
IAM ✅  ❌  ❌  ❌  ✅  ❌  ❌
IAM ✅  ❌  ❌  ✅  ❌  ❌  ✅
Root ✅  ❌  ❌  ❌  ✅  ✅  ❌
Root ✅  ❌  ❌  ✅  ❌  ✅  ✅
IAM ❌  ❌  ✅  ❌  ✅  ✅  ❌
IAM ❌  ❌  ✅  ✅  ❌  ✅  ❌
IAM ❌  ✅  ❌  ❌  ✅  ✅  ❌
IAM ❌  ✅  ❌  ✅  ❌  ✅  ❌
IAM ✅  ❌  ❌  ❌  ✅  ✅  ✅
IAM ✅  ❌  ❌  ✅  ❌  ✅  ✅


In this section, we will see some examples of policies to perform some common use cases.


You can always get the CRN of your resource from the Cubbit Console. Each entity has "Copy CRN" context menu item to easily copy it.

Minimum permissions to access the Web Console

This policy gives the bare minimum permissions for a user to sign-in on the Web Console. More in detail, the first section is composed of IAM actions that let a user create and manage its access keys plus the ability to list themselves in the user list. The second section is a single S3 action that is necessary to list all the buckets of the project but without the ability to list the objects inside such buckets.


Basic S3 permissions to read/write objects in a folder

The first section of this policy allows a user to list all the objects and versions of objects inside a specified bucket. It’s possible to extend this policy to multiple buckets by adding a new CRN in the resource field. The second section of the policy is what grants the read, write and delete permissions. In this case, the wildcard * at the end of the CRN means the permissions are valid for the entire bucket but it’s possible to specify a single folder or a single object. Like the previous section, it’s possible to add multiple CRN inside the resource field. Finally, it’s possible to remove or add actions to have more control over the permissions, for example, if only s3:PutObject is left, a user will be able to upload new files without having the ability to download or remove them.